APEX 4.1 - ORA-20987 lors d'une instruction en tant qu'administrateur

Nous avons rencontré un problème lors de l'appel du package d'Oracle Application Express (APEX) qui s'appelle : "APEX_INSTANCE_ADMIN". L'erreur est la suivante :

ORA-20987: APEX - User  requires ADMIN privilege to perform this operation. - Contact your application administrator.

Cette erreur survient même si le schéma Oracle utilisé à le rôle d'administration d'APEX. 

Ce problème est connu chez Oracle et la version 4.1.1 d'APEX règle cette erreur :

Bug 13553903 : CANNOT USE APEX_INSTANCE_ADMIN WITH USER GRANTED APEX_ADMINISTRATION_ROLE

Voting Disk corrompu et... aucune sauvegarde!

Suite à un "downgrade" du clusterware 11gR2 à la version 10gR2 (10.2.0.4), nous n'avons pas réussi à redémarrer le CRS correctement. Après quelques investigations dans les différents fichiers de trace (.log), j'ai alors remarqué le message suivant dans le fichier "cssd.log"

ERROR:   clssnmvReadFatal: voting device corrupt (0x00000000/0x00000000/0//dev/vd1_sys_1g)

Pour remédier à ce problème, nous avons du recréer le "voting disk" car nous n'avions aucune sauvegarde à notre disposition ni de mirroring... chose à ne pas faire.

Voici les étapes effectuées. Ceci a été effectué sur une plate-forme AIX dont les produits Oracle étaient de la version 10gR2 (10.2.0.4)

• Arrêt complet du clusterware

Dans notre cas, la commande "crsctl stop crs" ne fonctionnait pas alors nous avons désactivé le démarrage automatique (init.crs disable) puis redémarrer chacun des noeuds.

• Ajout d'un nouveau raw device

L'administrateur de système nous a alloué un nouveau disque d'une capacité d'un gigaoctet.

• Afficher le voting disk actuel

#crsctl query css votedisk

Cette commande nous a retourné le nom complet du voting disk (ex. /dev/vd1_sys_1g)

• Ajouter un voting disk en précisant l'emplacement exact

# crsctl add css votedisk [/chemin/nom] -force

Ex. # crsctl add css votedisk /dev/vd1_sys_2g -force

• Détruire le voting disk corrompu en spécifiant le chemin complet

# crsctl delete css votedisk [/chemin/nom] -force

Ex. # crsctl delete css votedisk /dev/vd1_sys_1g -force

• Redémarrer le cluster

# crsctl start crs

• Vérifier le nouveau voting disk

# crsctl query css votedisk

Suite à toutes ces étapes, nous nous sommes empressé de recommander la mise en place d'une sauvegarde du voting disk dans la procédure de sauvegarde existante et, de créer au minimum un second voting disk.

Quels sont les variables d'environnement du processus en cours d'exécution

Lors de la migration d'un cluster Oracle 10gR2, nous avons rencontré un problème avec l'assistant de configuration ASMCA lors de l'étape de migration d'ASM. Après avoir fouillé Internet, certains messages de forum et de blogs nous ont mis sur une possible cause : Des variables d'environnement n'auraient pas été réinitialisées (UNSET) avant l'exécution du programme d'installation.

Pour vérifier si cela était notre cause, nous devions obtenir l'identifiant du processus correspondant au programme d'installation d'Oracle (OUI) qui est démarré lors de l'exécution de "runInstaller" :

ps -elf | grep OraInstall

Ensuite, pour obtenir les variables d'environnement en force lors de son exécution, on doit exécuter l'une de ces commandes dépendamment de la plateforme utilisée en précisant l'identifiant du processus obtenu précédemment :

SOLARIS

pargs -e | grep ORACLE

LINUX
cat /proc//environ

AIX
ps eauwww

Si le résultat de la commande est quelque peu exhaustif, je vous recommande de rediriger le résultat de la commande vers un fichier (ex.: ps eauwww > result.log) puis de l'ouvrir avec un éditeur de texte pour vérifier la présence des variables d'environnement.

Statut inconnu (UNKNOWN) de l'instance ASM sous RAC

Voici une situation vécue avec une instance ASM 10g (10.2.0.4) dans un environnement Oracle Real Application Cluster (RAC) 10gR2 sur la plateforme IBM AIX 64 bits.

Le statut de l'instance ASM est devenu "UNKNOWN" et celles des bases de données hébergées sur le même noeud sont OFFLINE. Que se passe-t-il ?

Afin de comprendre, je me suis dirigé vers les fichiers de trace sous l'ORACLE_HOME d'Oracle ASM situé à l'emplacement suivant puis vérifier le contenu du fichier "ora.noeud01.ASM1.asm.log" :

$ cd /opt/oracle/product/asm10g/log/noeud01/racg
$ vi ora.noeud01.ASM1.asm.log (writing error)

Le fichier de trace contenait l'erreur suivante :

RACG][1] [905406][1][ora.noeud01.ASM1.asm]: CLSR-0006: Error encountered when writing file /opt/oracle/product/crs10g/racg/tmp/ora.noeud01.ASM1.asm.ora

Je me suis alors déplacé vers le répertoire "/opt/oracle/product/crs10g/racg/tmp" pour vérifier les fichiers présents et leurs permissions.

$ cd /opt/oracle/product/crs10g/racg/tmp
$ ls -al

Voyant que tout semblait correct et que rien n'attirait mon attention, j'ai prit la décision de déplacer tous les fichiers de ce répertoire vers un autre répertoire dans le but de laisser Oracle les recréer au besoin :

# mkdir -p /tmp/backup
# mv * /tmp/backup

Suite au déplacement, j'ai redémarré le CRS puis revérifier graduellement le statut de chacune des composantes :

# crsctl stop crs
# crsctl start crs
# crsctl check crs
# crs_stat.sh

Toutes les composantes ont redémarrées correctement. Maintenant, je dois investiguer pour comprendre ce qu'il s'est réellement passé.

Appel de fonction PL/SQL dans un énoncé SQL

J’ai remarqué que plusieurs cas de lenteur ont été soulevés par le fait que des fonctions PL/SQL sont utilisées dans les clauses WHERE des énoncés SQL d'une vue utilisée par une application développé sous Oracle Application Express (APEX).

Par exemple, lorsque la fonction est appelée de cette façon, l’optimiseur d’Oracle l’exécute à toutes les rangées même si les valeurs passées sont toujours les mêmes :

SELECT empl.nom_empl, empl.prn_empl, clien.ide_clien, mand.num_contt
  FROM gma_mand mand, gcl_clien clien, gem_empl empl
 WHERE mand.num_empl_gestn = empl.num_empl
   AND mand.ide_clien      = clien.ide_clien
   AND pkg_securite.verfc_acces (v('USER')) = 1;

Alors, il est recommandé de l’encapsuler dans une requête SQL (scalar subquery) car cette requête sera exécutée qu’une seul fois et ce, peu importe le nombre de rangées retournées :

SELECT empl.nom_empl, empl.prn_empl, clien.ide_clien, mand.num_contt
  FROM gma_mand mand, gcl_clien clien, gem_empl empl
 WHERE mand.num_empl_gestn = empl.num_empl
   AND mand.ide_clien      = clien.ide_clien
   AND (SELECT pkg_securite.verfc_acces (v('USER')) FROM DUAL) = 1;

L’appel à des stored procedure dans des énoncés SQL peut être très couteux en ressource. Dans le cas rencontré avec la vue, l’exécution de la stored procedure était effectuée pour chaque enregistrement retourné. En l’englobant dans un énoncé SQL (select … from dual), Oracle ne l’exécute qu’une seule fois. Un important gain en performance a été constaté dès que le changement a été mis en place.

Modifier l'information réseau contenu dans l'OCR

Si vous obtenez les messages :

PRVG-1513 : Failed to retrieve current selection of public and private network classifications for node
PRVG-11050 : No matching interfaces "" for subnet "" on nodes "racnode1"

Il est fort possible que l'information contenu dans l'OCR ne soit pas correcte. Pour remédier à cela, vous devrez procéder comme suit pour vérifier les interfaces définis dans l'OCR puis de la redéfinir selon votre cas.

voici un exemple :

• Afficher les interfaces présents sur le noeud

$ oifcfg iflist -p -n
en3  10.2.2.0  UNKNOWN  255.255.255.0
en0  10.25.9.0  PRIVATE  255.255.255.0

• Afficher les interfaces définis par la commande "setif"

$ oifcfg getif
en0  10.25.9.0  global  public
en3  10.2.1.0  global  cluster_interconnect

En comparant les adresses IP des interfaces, on remarque qu'un d'elle est incorrecte (10.2.1.0). On doit supprimé cette entrée pour la réinsérer avec la bonne adresse IP (10.2.2.0) :

$ oifcfg delif -global en3

$ oifcfg setif -global en3/10.2.2.0:cluster_interconnect

L'interface de configuration "OIFCFG" permet de définir et de gérer les interfaces réseau. Il permet d'allouer et libérer les interfaces réseaux,d'utiliser des interfaces réseau spécifiques et obtenir des informations de configuration des composant.De plus, vous pouvez utiliser "OIFCFG" sur une instance unique et des environnements impliquant Oracle Clusterware.

Configuration des interfaces de l'interconnect

Lors de la vérification de la configuration d'un cluster existant de la version 10gR2 (runcluvfy.sh) en prévision de le mettre à niveau à la version 11gR2 (11.2.0.3), nous avions reçu le message suivant :

WARNING:
Could not find a suitable set of interfaces for the private interconnect
Checking subnet mask consistency...
Subnet mask consistency check passed for subnet "10.2.190.0".
PRVG-11055 : Interfaces configured with subnet number "192.168.2.0" have multiple subnets masks
PRVG-11056 : subnet masks "255.255.255.0" are configured with subnet number "192.168.2.0" on nodes "qaora05t"
PRVG-11056 : subnet masks "255.255.255.224" are configured with subnet number "192.168.2.0" on nodes "qaora06t"
Subnet mask consistency check failed.

Result: Node connectivity check failed

Nous avons dû modifier le "netmask" au niveau du serveur "srvbd02" pour qu'il soit identique sur les 2  noeuds (serveurs) du cluster, voici les étapes réalisées :

$oifcfg iflist -p -n
en2  10.2.190.0  PRIVATE  255.255.255.0
en4  192.168.2.0  PRIVATE  255.255.255.0

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xfffffe00 broadcast 192.168.2.31
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Le "netmask" qui est égale à "0xffffffe0" doit être modifié pour être "0xffffff00" :

#chdev -l en4 -a netaddr=192.168.2.14 -a netmask=0xffffff00

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xffffff00 broadcast 192.168.2.255
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Suite à ce changement, le « cluster verify » à passer sans erreur.


Ce cluster était sur une plateforme IBM AIX 5.3 64bits.

Un merci tout spécial à mon collègue Nabil Ben Tekaya. Grâce à ses yeux de lynx, il a remarqué la différence au niveau des masques réseau.