Incapable d'émettre un droit malgré la clause "With Grant Option"

Après avoir octroyer le droit d'exécution sur le package UTL_HTTP à un schéma particulier avec la clause "With Grant Option", ce dernier n'a pas été en mesure d'émettre à son tour, ce même droit à un autre schéma malgré la présence de la clause. Lors de l'émission du privilège, l'erreur "ORA-01031 INSUFFICIENT PRIVILEGES" est soulevé. Ce qui ne fait aucun sens.

Après quelques recherches, j'ai alors remarqué que ce comportement est un bug répertorié chez Oracle et il a été observé sur la version 11.2.0.3 de la base de données. (Bug 13036331 : ORA-01031 INSUFFICIENT PRIVILEGES WHEN GRANTING EXECUTE ON DBMS PACKAGES)

Étrangement, mais heureusement, il y a une solution de contournement. Dans mon cas, il a suffit d'effectuer un "Alter system flush shared_pool;" puis d'émettre à nouveau le privilège initial qui comportait la clause "With Grant Option" et ensuite, d'octroyer de nouveau le privilège à l'autre schéma dont il était impossible de faire. Cette fois-ci, ça l'a réussi.

Erreur de connexion à la base de données sous Microsoft Windows

La majeure partie du temps, je travaille sur les plate-formes Unix et Linux et, dernièrement, j'ai eu à installer et configurer une nouvelle base de données sous Oracle Fail Safe sous Microsoft Windows.

L'installation s'est très bien déroulé. Lorsque rendu à l'étape d'ajouter la base de données au groupe de ressources du cluster, nous avions rencontré des erreurs qui mentionnaient qu'il était incapable de se connecter à la base de données. Afin de diagnostiquer le problème, j'ai alors démarré un invite de commandes puis démarré SQL*Plus. J'étais aucunement capable de me connecter à celle-ci, que se soit avec "/ as sysdba" ou avec une chaîne de connexion.

Avec "/ as sysdba", j'obtenais l'erreur "ORA-12560:TNS:protocol adapter error" tandis que lorsque je mentionnais une chaîne de connexion définie dans le "tnsnames.ora", je recevais l'erreur "ORA-12518 Tns: Listener could not hand off client connection".

Après avoir vérifié le statut du "listener", la configuration dans les fichiers listener.ora, tnsnames.ora, sqlnet.ora, etc.. j'ai alors pensé que, dans le merveilleux monde de Windows, il y a des services pour la base de données Oracle... En ouvrant le gestionnaire de services, j'ai remarqué aussitôt que le service "OracleInstanceORCL" n'était pas démarré. Je l'ai tout simplement démarré puis j'ai été en mesure de me connecter avec SQL*Plus des deux façons mentionnées précédemment.

L'envergure du problème n'est pas toujours proportionnel aux efforts déployés à le résoudre.

De grands changements à l'architecture d'Oracle Database

Oracle a annoncé au cours de l'événement Oracle Open World 2012 qu’il se lançait plus que jamais vers le « cloud computing » et, que la prochaine version de la base de données, en l’occurrence 12c sera « multi-tenant ». 

Pour bien comprendre la signification de « multi-tenant », il faut savoir que le mot anglais « tenant » signifie « locataire » en français et que « tenancy » signifie « location ». Dans le monde des technologies de l’information, le «  Multitenancy »  est un principe architectural où une seule instance du logiciel est utilisée pour exécuter un service pour plusieurs clients. Vous ne serez pas surpris de savoir que le principe « Multitenancy » est considéré comme l'un des attributs essentiels de l'informatique en nuage (cloud computing).

Lors des quatre dernières années, Oracle a révisé l’architecture logicielle pour permettre la gestion d’une multitude de bases de données (plusieurs locataires) à partir d’une seule installation tout en contrôlant de façon distincte les ressources matérielles telle que la mémoire, les processus, la sécurité,  et bien d’autres aspects forts utiles dans un environnement partagé de type « cloud ». Ce n’est pas par hasard que la future version portera dorénavant un « c » pour « cloud » au lieu d’un « g ».

Sachez que ce principe n'est pas universellement accepté et soutenue dans l'industrie du logiciel, ce qui peut être une source de différenciation parmi les diverses solutions offertes. Il faut s’attendre que chacun des fournisseurs tireront sur leur bout de couverture pour s’approprier les mérites de ce principe et se vanteront que leur solution est la meilleure.

Il a aussi été mentionné qu’une nouvelle fonctionnalité permettra à la base de données Oracle 12c de surveiller à quelle fréquence les données sont accédées et par quelles types d’opérations (SELECT / INSERT / UPDATE / DELETE). En obtenant ces informations, on peut facilement imaginer qu’elles permettront d’identifier les données qui sont rarement consultées et qu’elles pourraient être archivées. 

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é.