Récemment, une erreur m’est apparue lors de la création d’une base RAC en version 11.2.0.2. Beaucoup de DBAs ont pu constater que les premiers 5% suivant la finalisation de l’assistant de la création des disques sont « critiques ».
Problèmes d’emplacements, problèmes d’options, tous ces problèmes sont détectés dans les premiers 3 à 5 pourcents.
Il y a quelques jours, j’ai eu une erreur alors que DBCA affiché 0% :
CRS-2566: User 'oracle' does not have sufficient permissions to operate on resource 'ora.XXX_data.dg', which is part of the dependency specification.
Etonnant, étant donné le process immuable que j’ai utilisé… Comme un célèbre joueur de football dans les vestiaires avant un match, je commence toujours par la jambe gauche puis la droite et bois une gorgée d’eau.
Mon process est toujours le même :
- Demander 4 LUNs à l’équipe stockage
- Créer les partitions pour que les données soient alignées
- Tagguer les disques comme étant des ASM Disks
- Créer 4 disques groupes séparés (Control files, données, undo et redo)
- Lancer DBCA
- Suivre l’assistant
- Valider
Hélas, il semble que ce jour-là, la routine se soit brisée.
Après enquête, il s’avère que, pour une raison qui m’échappe encore, les droits sur un fichier aient changée.
Si l’on reprend la théorie, lors de la création d’un ASM Disk Group (que ce soit par OEM ou par ASMCA), l’outil fait appel au binaire « oracle » du dossier $GI_HOME/bin.
Après vérification sur l’environnement Hors-prod où je travaillais, voici les droits du dossier :
[ ~]$ ll /u01/app/oracle/product/11.2.0/grid/bin/oracle
-rwsr-s--x 1 grid asmadmin 203974257 Jan 8 2013 /u01/app/oracle/product/11.2.0/grid/bin/oracle
Tout semble comme avant. Par acquis de conscience, j’ai effectué la même commande sur mon serveur de production :
[ ~]$ ll /u01/app/oracle/product/11.2.0/grid/bin/oracle
-rwsr-s--x 1 grid oinstall 203974257 Jan 8 2013 /u01/app/oracle/product/11.2.0/grid/bin/oracle
En voici le coupable… le binaire Oracle a changé de groupe.
Très bien (façon de parler…), il me suffit de changer le groupe sur ma pré-prod pour le remettre dans le groupe oinstall.
[ ~]$ chown grid:oinstall /u01/app/oracle/product/11.20/grid/bin/oracle
[ ~]$ ll /u01/app/oracle/product/11.2.0/grid/bin/oracle
-rwxr-x--x 1 grid oinstall 203974257 Jan 8 2013 /u01/app/oracle/product/11.2.0/grid/bin/oracle
Oups… le sticky bit n’est plus là… remettons-le :
[ ~]$ chmod ug+s /u01/app/oracle/product/11.2.0/grid/bin/oracle [ ~]$ ll /u01/app/oracle/product/11.2.0/grid/bin/oracle -rwsr-s--x 1 grid oinstall 203974257 Jan 8 2013 /u01/app/oracle/product/11.2.0/grid/bin/oracle
Voila,
nous sommes maintenant dans les conditions initiales !
Recréons le disk group puis relançons la création de la base.
CRS-2566: User 'oracle' does not have sufficient permissions to operate on resource 'ora.XXX_data.dg', which is part of the dependency specification.
Très bien… Ah non. Le problème de disque persiste.
Après quelques recherches dans la documentation et sur metalink, je me souviens d’une commande du clusterware permettant de vérifier les droits d’une ressource :
[root@mon_serveur ~]# crsctl stat res ora.XXX_data.dg –p
[…]
ACL=owner:grid:rwx,pgrp:asmadmin:rwx,other::r--
[…]
Et voici le coupable !
2 solutions :
En environnement de production : changer les attributs du disk group !
Voici la commande magique :
[root@mon_serveur ~]# . oraenv ORACLE_SID = [root] ? +ASM1 The Oracle base has been set to /u01/app/oracle/grid [root@mon_serveur ~]# crsctl modify resource ora.XXX_data.dg -attr "ACL='owner:grid:rwx,pgrp:oinstall:rwx,other::r--'"
En environnement non-critique : redémarrer la couche clusterware pour que le changement de droits précédents soit bien pris en compte !
Après une nouvelle tentative, le disk group est bien accessible par l’utilisateur Oracle et la base de données termine son installation.
