How to : Oracle ASM & Multipath : Ajout d’un disque SAN à un diskgroup sur Unix

Pour compléter l’article « How to : Oracle ASM – Ajout d’un disque SAN à un diskgroup sur Windows » , voici son homologue pour les environnements Unix. Ici, la méthode finale sous ASM reste quasi identique, il s’agit donc ici de d’indiquer comment repérer les devices MPATH pour les ajouter sous ASM.

En synthèse des opérations, on s’assure que le nouveau disque SAN soit bien visible depuis multiplath. Ensuite, une fois que le bon disque a été identifié parmi la liste ci dessus, on peut passer à la création des partitions.

Petit moyen simple, pour savoir si les disques « MPATH » sont utilisés ou non, on peut (si on est en gestion disques LVM) lancer la commande suivante :

pvdisplay |grep mpath

Cela permet d’isoler par déduction le disque SAN qui n’est pas encore utilisé par ORACLEASM.

Exemple de cas : J’ai déjà 2 disques SAN rattachés à mon serveur, et on m’en a ajouté un autre dont j’ignore la taille :

[root@SRV1 ~]# multipath -ll
mpathe (36005076802818c85780000000000004d) dm-2 IBM,2145
size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 0:0:3:0 sdd 8:48 active ready running
| |- 1:0:1:0 sdn 8:208 active ready running
| |- 0:0:1:0 sdb 8:16 active ready running
| `- 1:0:2:0 sdt 65:48 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
 |- 0:0:2:0 sdc 8:32 active ready running
 |- 1:0:0:0 sdm 8:192 active ready running
 |- 0:0:0:0 sda 8:0 active ready running
 `- 1:0:3:0 sdu 65:64 active ready running
mpathg (3600507640081009790000000000000fd) dm-4 IBM,2145
size=100G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 0:0:4:1 sdf 8:80 active ready running
| |- 1:0:4:1 sdw 65:96 active ready running
| |- 0:0:5:1 sdh 8:112 active ready running
| `- 1:0:5:1 sdy 65:128 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
 |- 0:0:7:1 sdl 8:176 active ready running
 |- 1:0:6:1 sdaa 65:160 active ready running
 |- 0:0:6:1 sdj 8:144 active ready running
 `- 1:0:7:1 sdac 65:192 active ready running
mpathf (3600507640081009790000000000000a0) dm-3 IBM,2145
size=200G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 0:0:4:0 sde 8:64 active ready running
| |- 1:0:4:0 sdv 65:80 active ready running
| |- 0:0:5:0 sdg 8:96 active ready running
| `- 1:0:5:0 sdx 65:112 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
 |- 0:0:6:0 sdi 8:128 active ready running
 |- 1:0:6:0 sdz 65:144 active ready running
 |- 0:0:7:0 sdk 8:160 active ready running
 `- 1:0:7:0 sdab 65:176 active ready running

Dans cette liste de 3 disques SAN, il me faut donc découvrir lequel n’est pas encore utilisé :

[root@SRV1 ~]# pvdisplay |grep mpathf
 PV Name /dev/mapper/mpathfp1
[root@SRV1 ~]# pvdisplay |grep mpathe
 PV Name /dev/mapper/mpathe
[root@SRV1 ~]# pvdisplay |grep mpathg
[root@SRV1 ~]#
[root@SRV1 ~]#

Hop j’ai un candidat, le MPATHG car les autres semblent dispose de partitions, et sont alloués à des VG :

[root@SRV1 ~]# pvdisplay |grep mpath
 PV Name /dev/mapper/mpathfp1
 PV Name /dev/mapper/mpathe
[root@SRV1 ~]# pvdisplay /dev/mapper/mpathfp1
 --- Physical volume ---
 PV Name /dev/mapper/mpathfp1
 VG Name datavg-san
 PV Size 200,00 GiB / not usable 1,34 MiB
 Allocatable yes
 PE Size 4,00 MiB
 Total PE 51199
 Free PE 15103
 Allocated PE 36096
 PV UUID 8k1Cgo-sf4E-tttd-ubFs-lvSJ-KukX-fdZdUR

[root@SRV1 ~]# pvdisplay /dev/mapper/mpathe
 --- Physical volume ---
 PV Name /dev/mapper/mpathe
 VG Name oraexport
 PV Size 60,00 GiB / not usable 4,00 MiB
 Allocatable yes
 PE Size 4,00 MiB
 Total PE 15359
 Free PE 511
 Allocated PE 14848
 PV UUID AGzG9E-Ew3P-oDmq-LSLr-rKbI-2ZCz-JzkYdO

Je suis donc sur que le device MPATHG est LE disque à prendre. Je créée donc mon disque ASM avec OracleASM, en vue de l’ajouter à mon groupe ASM existant :

[root@SRV1 ~]# oracleasm listdisks
VOL1
VOL2
[root@SRV1 ~]# oracleasm createdisk VOL3 /dev/mapper/mpathg
Writing disk header: done
Instantiating disk: done
[root@SRV1 ~]# oracleasm listdisks
VOL1
VOL2
VOL3

Mon disque étant ajouté et formaté ASM, je peux maintenant passer coté Oracle pour augmenter l’espace disque de mon groupe asm « DATA »

J’identifie déjà si mon disque ajouté est bien candidat « PROVISIONED » à être ajouté au groupe DATA :

SQL> col path for a40
SQL> set lines 200
SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;

MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
------- ------------ ------- -------- ---------- ---------- ------------------------------ ---------------------------------------- -------------------------------
CLOSED PROVISIONED ONLINE NORMAL 0 0 ORCL:VOL3 VOL3
CACHED MEMBER ONLINE NORMAL 139486 27206 VOL1 ORCL:VOL1 VOL1
CACHED MEMBER ONLINE NORMAL 139486 27216 VOL2 ORCL:VOL2 VOL2

C’est donc bien le cas, mon VOL3 est visible et prêt a être utilisé. Voyons également la notion de rebalance, car quand je vais ajouter mon disque il va y avoir une auto répartition des datas réalisés par ASM, et en fonction de la taille du disque ajouté il convient de faire quelques réglages, pour éviter que ca prenne un temps fou.

SQL> sho parameter asm_power_limit

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
asm_power_limit integer 1

La configuration est DEFAULT, ie les opérations ne vont pas « trop » solliciter les ressources machines / SAN (CPU / IO) pour ne pas impacter les performances, dans le cas où par exemple cette opération serait lancée en pleine journée.

Je le passe cependant à 4 pour que le REBALANCE soit plus rapide, la machine étant critique et le moindre risque est à éviter ..

SQL> alter diskgroup DATA add disk 'ORCL:VOL3' rebalance power 4;
alter diskgroup DATA add disk 'ORCL:VOL3' rebalance power 4;
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15038: disk '' mismatch on 'Sector Size' with target disk group [512] [4096]

Ah dommage … Le problème vient que la taille des secteurs de ma partition MPATHG est en 512 bytes au lieu de 4096. Dans cette situation je ne peux pas ajouter de disque de la sorte à mon diskgroup qui lui a été créée sur une base de taille de secteur de 4k.

[]<>/root[]:fdisk -l /dev/mapper/mpathg |grep "Sector"
Sector size (logical/physical): 512 bytes / 512 bytes

Il s’agit ici d’une particularité liée à la baie SAN, qui ne permet pas de forcer la taille de secteur.

Ne pouvant supprimer le groupe DATA pour le refaire avec le nouveau disque, je dois passer par la création d’un second diskgroup, qui servira pour les nouvelles databases. Attention, il ne sera pas possible d’agrandir (par exemple) un tablespace existant (sur le groupe de disque avec un sector size à 4096) sur ce nouveau groupe de disque. il faut en effet que la sector Size soit la même.

SQL> create diskgroup DATA2 external redundancy disk 'ORCL:VOL3' ;

Diskgroup created.


SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;

MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
------- ------------ ------- -------- ---------- ---------- ------------------------------ ---------------------------------------- -------------------------------
CACHED MEMBER ONLINE NORMAL 139486 30029 VOL1 ORCL:VOL1 VOL1
CACHED MEMBER ONLINE NORMAL 139486 30030 VOL2 ORCL:VOL2 VOL2
CACHED MEMBER ONLINE NORMAL 102400 102350 VOL3 ORCL:VOL3 VOL3


SQL> select NAME,SECTOR_SIZE,BLOCK_SIZE,ALLOCATION_UNIT_SIZE,STATE,TOTAL_MB,FREE_MB ,DATABASE_COMPATIBILITY,COMPATIBILITY from v$asm_diskgroup;

NAME SECTOR_SIZE BLOCK_SIZE ALLOCATION_UNIT_SIZE STATE TOTAL_MB FREE_MB DATABASE_C COMPATIBILITY
------------------------------ ----------- ---------- -------------------- ----------- ---------- ---------- ---------- ------------------------------------------------------------
DATA 4096 4096 1048576 MOUNTED 278972 59894 10.2.0.0.0 11.2.0.0.0
DATA2 512 4096 1048576 MOUNTED 102400 102350 10.1.0.0.0 10.1.0.0.0

Mais l’objectif est atteint, celui de voir comment intégrer un disque SAN géré par multipath à ASM 😉

Tips : Oracle RAC 11GR2 : DELETE NODE

Dans cet article nous allons voir comment retirer un NOEUD d’un Cluster Oracle RAC en release 11GR2.

Dans mon contexte technique, je suis sur un cluster Oracle à 2 Nodes, en Oracle linux 6, avec un node KO suite à un problème Hardware. Je vais donc retirer le node en question, en vue de le réintégrer par la suite une fois le problème corrigé.

Première étape, vérifier les serveurs qui sont connectés au RAC, et l’état du Cluster :

[]<>/root[]:/oracle/product/11.2.0/grid/bin/olsnodes -t
rac1 Pinned
rac2 Unpinned

[]<>/root[]:/oracle/product/11.2.0/grid/bin/crsctl status res -t

--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS Local Resources
--------------------------------------------------------------------------------
ora.DATADG.dg ONLINE ONLINE rac1
ora.LISTENER.lsnr ONLINE ONLINE rac1
ora.OCR.dg ONLINE ONLINE rac1
ora.asm ONLINE ONLINE rac1 Started
ora.gsd OFFLINE OFFLINE rac1
ora.net1.network ONLINE ONLINE rac1
ora.ons ONLINE ONLINE rac1
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE rac1
ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE rac1
ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE rac1
ora.cvu 1 ONLINE ONLINE rac1
ora.oc4j 1 ONLINE ONLINE rac1
ora.rac1.vip 1 ONLINE ONLINE rac1
ora.rac2.vip 1 ONLINE INTERMEDIATE rac1 FAILED OVER
ora.scan1.vip 1 ONLINE ONLINE rac1
ora.scan2.vip 1 ONLINE ONLINE rac1
ora.scan3.vip 1 ONLINE ONLINE rac1

Dans cet exemple, le second node est DOWN, les ressources cluster sont donc basculées sur le noeud principal nommé dans cet exemple « RAC1 ».

Note : Le serveur RAC2 n’étant pas connecté au cluster (Unpinned), il n’est pas nécessaire de lancer la commande « unpin », mais si cela avait été le cas (RAC2 en « Pinned« ), il aurait fallu faire :

[]<>/root[]:/oracle/product/11.2.0/grid/bin/crsctl unpin css -n rac2

On passe donc directement par la suppression du NODE RAC2 :

[]<>/root[]:/oracle/product/11.2.0/grid/bin/crsctl delete node -n rac2
 CRS-4661: Node rac2 successfully deleted.

On met à jour ensuite l’inventaire sur le noeud qui reste disponible (RAC1), cette fois avec le compte unix qui a installé le GRID (dans mon cas « oracle ») :

[rac1]<oracle>/home/oracle[+ASM1]:cd $GRID_HOME/
[rac1]<oracle>/oracle/product/11.2.0/grid[+ASM1]:cd oui/bin
[rac1]<oracle>/oracle/product/11.2.0/grid/oui/bin[+ASM1]:./runInstaller 
-updateNodeList ORACLE_HOME=$ORACLE_HOME "CLUSTER_NODES={rac1}" 
CRS=TRUE -local

 Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB. Actual 15999 MB Passed
 The inventory pointer is located at /etc/oraInst.loc
 The inventory is located at /oracle/oraInventory
 'UpdateNodeList' was successful.

Une petite vérification :

[rac1]<oracle>/oracle/product/11.2.0/grid/oui/bin[+ASM1]:cluvfy stage -post 
nodedel -n rac2 -verbose

Performing post-checks for node removal

Checking CRS integrity...

Clusterware version consistency passed
 The Oracle Clusterware is healthy on node "rac1"

CRS integrity check passed
 Result:
 Node removal check passed

Post-check for node removal was successful.

Et enfin l’état des ressources cluster :

[rac1]<oracle>/oracle/product/11.2.0/grid/oui/bin[+ASM1]:crsctl stat res -t
 --------------------------------------------------------------------------------
 NAME TARGET STATE SERVER STATE_DETAILS
 --------------------------------------------------------------------------------
 Local Resources
 --------------------------------------------------------------------------------
 ora.DATADG.dg
 ONLINE ONLINE rac1
 ora.LISTENER.lsnr
 ONLINE ONLINE rac1
 ora.OCR.dg
 ONLINE ONLINE rac1
 ora.asm
 ONLINE ONLINE rac1 Started
 ora.gsd
 OFFLINE OFFLINE rac1
 ora.net1.network
 ONLINE ONLINE rac1
 ora.ons
 ONLINE ONLINE rac1
 --------------------------------------------------------------------------------
 Cluster Resources
 --------------------------------------------------------------------------------
 ora.LISTENER_SCAN1.lsnr
 1 ONLINE ONLINE rac1
 ora.LISTENER_SCAN2.lsnr
 1 ONLINE ONLINE rac1
 ora.LISTENER_SCAN3.lsnr
 1 ONLINE ONLINE rac1
 ora.cvu
 1 ONLINE ONLINE rac1
 ora.oc4j
 1 ONLINE ONLINE rac1
 ora.rac1.vip
 1 ONLINE ONLINE rac1
 ora.rac2.vip
 1 ONLINE INTERMEDIATE rac1 FAILED OVER
 ora.scan1.vip
 1 ONLINE ONLINE rac1
 ora.scan2.vip
 1 ONLINE ONLINE rac1
 ora.scan3.vip
 1 ONLINE ONLINE rac1

=> Il me reste la VIP du second node, je dois donc la supprimer :

[]<>/root[]:/oracle/product/11.2.0/grid/bin/crsctl delete resource ora.rac2.vip -f
[]<>/root[]:/oracle/product/11.2.0/grid/bin/crsctl stat res -t
 --------------------------------------------------------------------------------
 NAME TARGET STATE SERVER STATE_DETAILS
 --------------------------------------------------------------------------------
 Local Resources
 --------------------------------------------------------------------------------
 ora.DATADG.dg
 ONLINE ONLINE rac1
 ora.LISTENER.lsnr
 ONLINE ONLINE rac1
 ora.OCR.dg
 ONLINE ONLINE rac1
 ora.asm
 ONLINE ONLINE rac1 Started
 ora.gsd
 OFFLINE OFFLINE rac1
 ora.net1.network
 ONLINE ONLINE rac1
 ora.ons
 ONLINE ONLINE rac1
 --------------------------------------------------------------------------------
 Cluster Resources
 --------------------------------------------------------------------------------
 ora.LISTENER_SCAN1.lsnr
 1 ONLINE ONLINE rac1
 ora.LISTENER_SCAN2.lsnr
 1 ONLINE ONLINE rac1
 ora.LISTENER_SCAN3.lsnr
 1 ONLINE ONLINE rac1
 ora.cvu
 1 ONLINE ONLINE rac1
 ora.oc4j
 1 ONLINE ONLINE rac1
 ora.rac1.vip
 1 ONLINE ONLINE rac1
 ora.scan1.vip
 1 ONLINE ONLINE rac1
 ora.scan2.vip
 1 ONLINE ONLINE rac1
 ora.scan3.vip
 1 ONLINE ONLINE rac1

Le tour est joué, il ne reste maintenant qu’à ajouter le second node au Cluster une fois qu’il sera de nouveau UP, ce qui fera l’objet d’un futur article 😉

Micka

How to : Oracle ASM – Ajout d’un disque SAN à un diskgroup sur Windows

Comme premier article de l’année, je me suis lancé dans un petit tuto pour montrer au mieux comment ajouter un nouvel espace de stockage SAN à un diskgroup ASM sur un environnement RAC 11G windows (à partir de 2008). Rien de bien complexe, mais cela reste des opérations courantes qui méritent d’avoir leur petit tuto 😉

Pour ce qui est du contexte technique, j’ai donc un cluster Oracle (sur machine physique) à deux noeuds, en 11.2.0.3 (Grid + RDBMS), sur un windows 2008R2.

L’objectif est d’ajouter un espace de stockage SAN de 250Go à mon diskgroup « DATA » utilisé par ASM, sans provoquer d’incident ou d’indisponibilité.

Attention :

Il faut s’assurer que le zoning soit bien réalisé depuis le SAN sur les 2 noeuds, sans accès EXCLUSIF, si si cela peu arriver …

=> Pour la petite note, l’accès « exclusif » se caractérise par le fait de réaliser des opérations sur un nouveau disque depuis un nœud du RAC, qui ne seraient pas propagées sur le ou les autres nœuds.

Tout d’abord, dès que l’espace SAN a été mappé sur les 2 serveurs, il faut s’assurer de la visibilité du disque depuis l’utilitaire DISKPART.

L’utilisation de cet utilitaire est préconisé par Oracle pour gérer les disques qui seront affectés à ASM, il faut en effet éviter d’utiliser le GUI « diskmgmt.msc » pour éviter des problèmes de FREEZE (que j’ai d’ailleurs rencontré quelques fois), qui feraient que le simple ajout -d’un disque devient une opération complexe pour ne pas dire d’autres mots.

On lance donc DISKPART depuis une commande dos sur l’un des noeuds du RAC, et on affiche l’ensemble des disques identifiés par le System pour ensuite s’occuper du nouvel espace ajouté.

Nota : il se peut que le nouveau disque ne soit pas visible sur les noeuds du cluster. Pas de panique, un RESCAN permet de rafraîchir le gestionnaire de disques Windows

1

Dans cette liste, on visualise 2 disques Offline qui sont à ajouter. Nous allons ajouter le disque 5 de 250Go à notre groupe de disque ASM « DATA ».

-> Toujours à travers DISKPART, on sélectionne le disque et débutons la création de 2 partitions en passant tout d’abord le disque ONLINE (la mise ONLINE du disque doit être réalisé sur l’ensemble des noeuds du RAC).

Note : Pour les stockages windows ASM, il faut avoir un disque ayant une partition ETENDUE puis LOGIQUE (soit à la taille globale du disque, ou non)

2

On créée la partition ETENDUE :

3

Ah … dommage . Le volume est en READ ONLY il est donc impossible de créer quoique ce soit dessus.

L’origine de ce problème est connu de Microsoft (KB), et fait référence à de nouvelles stratégies de groupes windows relatif à la gestion des disques SAN. En 2008 et 2008R2 les stratégies de groupes SAN attribuent le mode READ ONLY à tout nouveaux disques partagés SAN (mode VDS_SP_OFFLINE_SHARED) , alors que dans les versions plus récentes, le mode READ WRITE (VDS_SP_ONLINE) est le mode par défaut.

Les différentes stratégie de groupes SAN :

VDS_SP_ONLINE: All newly discovered disks are brought online and made read-write.
VDS_SP_OFFLINE_SHARED: All newly discovered disks that do not reside on a shared bus are brought online and made read-write.
VDS_SP_OFFLINE: All newly discovered disks remain offline and read-only.

Le contournement proposé est donc de modifier les attributs du disque, pour le forcer à être en READ WRITE via la commande « ATTRIBUTE DISK CLEAR READONLY« 

Qu’à cela ne tienne, passons le disque 5 en READ WRITE , et continuons la création de nos partitions.

5

=> Attention : Ceci est à faire sur l’ensemble des noeuds du cluster RAC.

Pour la création des deux partitions, il faut suivre les commandes ci dessous sauf pour la partition logique, dans le cas où une limite d’espace disque serait à fixer (ce qui n’est pas mon cas)

Création de la partition étendue :

CREATE PARTITITON EXTENDED

Création de la partition logique en utilisant tout l’espace disque de la partition étendue :

CREATE PARTITION LOGICAL 

Ou si une taille doit être spécifiée (exemple pour 10Go, la SIZE étant spécifiée en MB)

CREATE PARTITION LOGICAL SIZE=10000

Ce qui donne dans mon cas :

6

=> Après cette étape il faut s’assurer que les partitions soient BIEN VISIBLES des autres noeuds du cluster. Dans mon cas je vérifie sur mon second node toujours via DiskPart, après avoir fait en revanche un petit RESCAN pour rafraîchir le gestionnaire de disque.

7

Histoire d’être sur (car normalement depuis windows 2008 c’est du par défaut), on lance une commande « AUTOMOUNT ENABLE » pour être sur que le disque sera monté au prochain reboot.

23

Maintenant que cette étape est faite, il faut vérifier un point certes peu impactant mais qui peut être gênant pour oracle,  windows et les applications :

A chaque découverte de nouvelles partitions, Windows attribue AUTOMATIQUEMENT une nouvelle lettre de lecteur. En soi, pour des partitions classiques (primary) ce n’est pas bien grave, mais pour les partitions étendues (que va utiliser ASM) cela peut poser problème.

=> Il faut donc veiller à RETIRER la LETTRE qui a du être automatiquement ajoutée sur le second noeud (en effet, le nœud d’où a été créée la partition n’a quand à lui pas cette lettre d’automatiquement associée)

Après avoir cliqué droit sur la partition, puis sélectionné « Change drive letter and path » :

20

=> on remove !

21

On dit YES bien sur ..

22

Hop, plus de lettre, c’est tout bon, je peux maintenant passer à la partie Oracle, et plus particulièrement ASM, pour agrandir mon DISKGROUP existant avec cette nouvelle partition LOGIQUE précédemment créée.

La première action est, sous windows (et oui car pas besoin sous Unix) est de labelliser cette partition, pour être ensuite CANDIDATE sous ASM.

Pour cela, il faut lancer l’utilitaire ASMTOOL (disponible dans le répertoire d’installation du GRID CONTROL) soit en mode graphique ou en ligne de commande. Etant sous windows je ne vais pas me compliquer la vie, j’utilise la méthode graphique via ASMTOOLG :

8

On continue (NEXT) et on arrive sur la liste des partitions visibles par le system, et celles qui sont candidates à être formatées « ASM » :

9

La partition 1 du Disk5, qui est CANDIDATE, est bien celle qui a été précédemment créée.

Note :

Je garde le même PREFIX pour la labellisation ASM « DATA » puisque je vais procéder à une augmentation du diskgroup de ce même nom. Ceci étant j’aurais pu mettre « DATA2″ ou « TOTO », cela n’aurait pas empêché l’opération d’agrandissement, il s’agit plus de normes et conventions, autant les respecter alors 😉

Je sélectionne donc ma partition 1 du disk5, et lance la « labellisation » du disk en format ASM :

10

1112

 

Je peux enfin passer sous ASM pour agrandir mon diskgroup !

Mais faisons au préalable un petit état des lieux, pour avoir un état avant et après, et également identifier le disque ASM qui sera à ajouter.

13

14

J’ai donc bien d’identifié par ASM mon disque en statut PROVISIONED et non utilisé, qui peut être ajouté au diskgroup DATA, auquel cas je lance ma commande :

15

Tout juste une fois cette commande lancée, nous pouvons interroger les opérations de REBALANCE en cours sur le diskgroup DATA :

16

Tiens mais qu’est ce le REBALANCE au fait ?

->  A chaque ajout de disque (un ou plusieurs) au sein d’un même diskgroup, il y a des opérations de redistribution des données qui sont automatiquement réalisées par ASM, l’objectif étant que les données soient réparties au mieux à travers tous les disques qui composent le diskgroup.

Les opérations de REBALANCE se découpent en 3 phases :

1. Analyse des données à répartir : « PLANNING »
2. Ré-allocation des EXTENTS des fichiers de données : « File extents relocation »
3. Compactage : « Disk compacting »

Par défaut, le niveau de REBALANCE est fixé à 1 via le paramètre ASM_POWER_LIMIT

17

Ce qui signifie que les opérations ne vont pas « trop » solliciter les ressources machines / SAN (CPU / IO) pour ne pas impacter les performances, dans le cas où par exemple cette opération serait lancée en pleine journée.

Mais l’impact de laisser tel quel ce paramètre à sa valeur par défaut peut être majeur, puisque autant sur une base de 100G, répartir les données sur l’ensemble des disques va prendre un temps probablement acceptable, dans lequel peu de risques peuvent survenir, mais autant sur une base de quelques To, cela ne va pas être la même limonade…

Si l’opération met plusieurs heures à se réaliser, les facteurs risquent augmentent (risques de pannes disques, machines, coupure lien SAN, reboot et j’en passe) ce qui peut provoquer un doux bazar au sein des données stockées par ASM.

Il est donc important de vérifier le temps que va mettre ASM à effectuer ses opérations de réorganisation, pour adapter au mieux et éviter ainsi un certain nombres de risques.

La gestion de la REBALANCE est dynamique, nous pouvons augmenter ou diminuer ASM_POWER_LIMIT, via une commande du type « alter diskgroup MYDISK rebalance power 3;« , voyons donc ce que cela donne pour moi :

18

On voit que le temps estimé ne descend pas, c’est plutôt le contraire (et c’est normal car c’est la première phase de « Planning« ). Nous allons donc passer au niveau rebalance 4 :

19

Tout de suite, en montant le niveau de rebalance à 4, on divise par deux le temps nécessaire à la réorganisation des données.

24

Nous avons donc maintenant notre diskgroup DATA pleinement opérationnel avec ces 250 nouveaux Go !

Enjoy !

Micka

 

How To : Modifier le nom du SCAN d’un cluster oracle RAC 11g

L’objectif de cet article est de donner une méthode simple permettant de modifier le nom du SCAN d’un cluster oracle RAC à 2 nodes.

Contexte technique :

– RAC 2 Node
– 3 SCAN_LISTENER
– Scan actuel : clustoriginal.mydomain.fr
– Futur Scan : clustnewscan.mydomain.fr

Le premier réflexe est d’identifier les IPs associées au SCAN, et donc indirectement du DNS qui permet la redirection depuis les serveurs applicatifs.

[NODE1]/home/oracle[]:export ORACLE_SID=/oracle/product/11.2.0/grid ; export PATH=$PATH:$ORACLE_HOME/bin
[NODE1]/home/oracle[]:srvctl config scan
SCAN name: clustoriginal.mydomain.fr, Network: 1/192.168.1.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /clustoriginal.mydomain.fr/192.168.1.12
SCAN VIP name: scan2, IP: /clustoriginal.mydomain.fr/192.168.1.11
SCAN VIP name: scan3, IP: /clustoriginal.mydomain.fr/192.168.1.10

[NODE1]/home/oracle[]:nslookup clustoriginal.mydomain.fr
Server: 192.168.50.10
Address: 192.168.50.10#53

Name: clustoriginal.mydomain.fr
Address: 192.168.1.10
Name: clustoriginal.mydomain.fr
Address: 192.168.1.11
Name: clustoriginal.mydomain.fr
Address: 192.168.1.12

On vérifie maintenant que le futur scan (ou plutôt le DNS de ce futur scan) pointe bien vers les mêmes IPs :

[NODE1]/home/oracle[]:nslookup clustnewscan.mydomain.fr
Server: 192.168.50.10
Address: 192.168.50.10#53

Name: clustnewscan.mydomain.fr
Address: 192.168.1.12
Name: clustnewscan.mydomain.fr
Address: 192.168.1.10
Name: clustnewscan.mydomain.fr
Address: 192.168.1.11

Ok, nous pouvons donc réaliser la modification, en débutant tout d’abord par l’arrêt des 3 listener_scan, et ensuite du scan :

[NODE1]/home/oracle[]:srvctl stop scan_listener
[NODE1]/home/oracle[]:srvctl stop scan

[NODE1]/home/oracle[]:srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is not running
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is not running
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is not running

[NODE1]/home/oracle[]:srvctl status scan
SCAN VIP scan1 is enabled
SCAN VIP scan1 is not running
SCAN VIP scan2 is enabled
SCAN VIP scan2 is not running
SCAN VIP scan3 is enabled
SCAN VIP scan3 is not running

On modifie le scan, mais pour ce faire il faut être en super user (root). En effet cette modification ce fait coté CRS, car elle agit sur des processus server lancé par root (crsd) :

[]/root[]:export ORACLE_HOME=/oracle/product/11.2.0/grid
[]/root[]:$ORACLE_HOME/bin/srvctl modify scan -n clustnewscan.mydomain.fr

Ensuite, on revient sur le compte système du Grid (dans mon exemple « oracle ») pour relancer le scan, et ensuite les scan_listener (on pourrait le faire en root, mais par convenance je reviens sur le compte propriétaire) :

[NODE1]/home/oracle[]:srvctl start scan
[NODE1]/home/oracle[]:srvctl start scan_listener

Quelques vérifications, pour être sur que la modification soit bien effective :

[NODE1]/home/oracle[]:srvctl config scan
SCAN name: clustnewscan.mydomain.fr, Network: 1/192.168.1.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /clustnewscan.mydomain.fr/192.168.1.11
SCAN VIP name: scan2, IP: /clustnewscan.mydomain.fr/192.168.1.12
SCAN VIP name: scan3, IP: /clustnewscan.mydomain.fr/192.168.1.10

OK. Comme dernier test, on peut se connecter à distance sur la base via ce nouveau SCAN / DNS, soit en easy connect ou via tnsnames. Dans mon cas je passe par le tnsnames, pour me rapprocher d’un existant en production :

NEW_SCAN_ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = clustnewscan.mydomain.fr)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 20)
(DELAY = 1)
)
)
)

C:\Users\Mickael>tnsping NEW_SCAN_ORCL

TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 12-SEPT.-2016 10:34:08

Copyright (c) 1997, 2014, Oracle. All rights reserved.

Fichiers de parametres utilises :
C:\Oracle\product\12.1.0\client_1\network\admin\sqlnet.ora

Adaptateur TNSNAMES utilisé pour la rÚsolution de l'alias
Tentative de contact de (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = clustnewscan.mydomain.fr)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ORCL) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 20) (DELAY = 1))))
OK (90 msec)

C:\Users\Mickael>sqlplus system@NEW_SCAN_ORCL

SQL*Plus: Release 12.1.0.2.0 Production on Lun. Sept. 12 10:34:26 2016

Copyright (c) 1982, 2014, Oracle. All rights reserved.

Entrez le mot de passe :

ConnectÚ Ó :
Oracle Database 11g Release 11.2.0.3.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options

SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME HOST_NAME
----------- ------------------
ORCL1 NODE1

OK ! Mais il ne faut pas oublier de configurer le remote_listener de chaque instance Oracle en activité, en passant par la modification du tnsnames.ora sur chaque nodes.

SQL> alter system set remote_listener="clustnewscan:1521" scope=both sid='*';
System altered.

Enfin, ne pas oublier de modifier les outils de monitoring du cluster (s’il y en a) pour tenir compte de cette modification 😉

Cette méthode reste simple, elle peut se compliquer quelque peu si en plus nous sommes dans un cas où les IP des VIPs devraient être modifiées, auquel cas il faudrait jouer avec oifcfg.. Cela fera l’objet d’un futur article !

Micka

HOW TO : Oracle RAC : Déplacement OCR – Voting – ASM SPFILE sur New DISKGROUP ASM

Lors d’une installation de Oracle RAC 11GR2, il y a la partie ASM où l’on doit configurer le DISKGROUP qui sera créée en vue de stocker différents éléments nécessaires au fonctionnement du cluster, à savoir la registry (OCR), le voting et le spfile de l’instance ASM.

Dans la configuration de cette partie j’ai laissé le nom du diskgroup ASM à sa valeur par défaut : DATA, alors que j’ai utilisé un disk ASM labellisé « OCR »

[oracle@rac1 ~]$ oracleasm listdisks
OCR
[oracle@rac1 ~]$ oracleasm querydisk -v -d OCR
Disk "OCR" is a valid ASM disk on device [8,21]
[oracle@rac1 ~]$ ls -l /dev/oracleasm/disks/OCR
brw-rw---- 1 oracle dba 8, 21 Jun 16 19:26 /dev/oracleasm/disks/OCR

Sauf qu’au final j’aime quand c’est clair, je vais donc l’appeler OCR pour y stocker ma registry et mon voting, pour correspondre ainsi au label OracleASM.
L’idée est donc de déplacer tout cela dans un second diskgroup ASM, pour ensuite renommer le diskgroup DATA en OCR.

Tout d’abord, quelques vérifications de base, histoire de savoir ce que nous avons :

Informations sur le VOTING :

[root@RAC2 export]# /oracle/product/11.2.0/grid/bin/crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 924d1d9d1d124fd8bf9f457431a42ea4 (/dev/oracleasm/disks/OCR) [DATA]

Informations sur la Registry du Cluster « OCR » :

[root@RAC2 export]# /oracle/product/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2668
Available space (kbytes) : 259452
ID : 1827476825
Device/File Name : +DATA
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

Informations sur le device ASM utilisé :

ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 5130 4734 0 4734 0 Y DATA/

ASMCMD> lsdsk
Path
/dev/oracleasm/disks/OCR

En résumé j’ai donc là un seul Diskgroup ASM utilisé, nommé « DATA » qui correspond au disk ASM labellisé « OCR », qui héberge actuellement la Registry du cluster, ainsi que le Voting. Ma première étape sera donc de créer un second diskgroup ASM afin de pouvoir par la suite déplacer l’OCR et le VOTING.

SQL> select group_number,name from v$asm_diskgroup;

GROUP_NUMBER NAME
------------ ------------------------------
1 DATA
SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;

MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
------- ------------ ------- -------- ---------- ---------- ------------------------------ -------------------------------------------------- -------------------------------
CLOSED PROVISIONED ONLINE NORMAL 0 0 /dev/oracleasm/disks/DATA
CACHED MEMBER ONLINE NORMAL 5130 4734 DATA_0000 /dev/oracleasm/disks/OCR

Mon disque OracleASM labellisé « DATA » est bien disponible, je l’utilise pour créer un diskgroup ASM que je nomme « DATADG », en EXTERNAL REDUNDANCY

SQL> create diskgroup DATADG external redundancy disk '/dev/oracleasm/disks/DATA';
Diskgroup created.

SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;
MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
------- ------------ ------- -------- ---------- ---------- ------------------------------ -------------------------------------------------- -------------------------------
CACHED MEMBER ONLINE NORMAL 455663 455609 DATADG_0000 /dev/oracleasm/disks/DATA
CACHED MEMBER ONLINE NORMAL 5130 4734 DATA_0000 /dev/oracleasm/disks/OCR

ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 5130 4734 0 4734 0 Y DATA/
MOUNTED EXTERN N 512 4096 1048576 455663 455609 0 455609 0 N DATADG/
ASMCMD> lsdsk
Path
/dev/oracleasm/disks/DATA
/dev/oracleasm/disks/OCR

[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.DATADG.dg
NAME=ora.DATADG.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , OFFLINE
STATE=ONLINE on RAC1, OFFLINE

On identifie que sur le second node, mon nouveau diskgroup n’est pas vu :

SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;

MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
------- ------------ ------- -------- ---------- ---------- ------------------------------ -------------------------------------------------- -------------------------------
CLOSED MEMBER ONLINE NORMAL 0 0 /dev/oracleasm/disks/DATA
CACHED MEMBER ONLINE NORMAL 5130 4734 DATA_0000 /dev/oracleasm/disks/OCR

SQL> exit

[RAC2]/home/oracle[+ASM2]:crsctl stat res ora.DATADG.ora
CRS-2613: Could not find resource 'ora.DATADG.ora'.

Normal, un petit coup de start depuis notre noeud « principal » :

[RAC1]/home/oracle[+ASM1]: crsctl start res ora.DATADG.dg -n RAC2
CRS-2672: Attempting to start 'ora.DATADG.dg' on 'RAC2'
CRS-2676: Start of 'ora.DATADG.dg' on 'RAC2' succeeded

[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.DATADG.dg
NAME=ora.DATADG.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , ONLINE
STATE=ONLINE on RAC1, ONLINE on RAC2

Good, donc seconde étape, déplacer l’OCR, et pour cela on va ajouter un second emplacement qui sera +DATADG :

[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/ocrconfig -add +DATADG
PROT-30: The Oracle Cluster Registry location to be added is not usable
PROC-8: Cannot perform cluster registry operation because one of the parameters is invalid.
ORA-15056: additional error message
ORA-17502: ksfdcre:4 Failed to create file +DATADG.255.1
ORA-15221: ASM operation requires compatible.asm of 11.1.0.0.0 or higher
ORA-06512: at line 4

Oups, j’ai du creer le ASM DISKGROUP en compatible.asm 10.1 !

SQL> select name,ALLOCATION_UNIT_SIZE,STATE,COMPATIBILITY from v$asm_diskgroup ;
NAME ALLOCATION_UNIT_SIZE STATE COMPATIBILITY
------------------------------ -------------------- ----------- ------------------------------------------------------------
DATADG 1048576 MOUNTED 10.1.0.0.0
DATA 1048576 MOUNTED 11.2.0.0.0

Et oui, je suis tombé en plein dans le piege ! En RAC 11G, tous les nouveaux diskgroup ASM sont crées par défaut avec la compatibilité ASM en 10.1, ce qui n’a rien de gênant en soi, sauf pour y stocker notre OCR et Voting (oui, on ne peux stocker ça quand dans un diskgroup avec une compatibilité au minima 11.1.0, puisqu’il s’agit d’un Cluster 11G) !

Modifions donc cela :

SQL> alter diskgroup DATADG SET ATTRIBUTE 'compatible.asm' = '11.2.0.0.0';
Diskgroup altered.

SQL> select name,ALLOCATION_UNIT_SIZE,STATE,COMPATIBILITY from v$asm_diskgroup ;
NAME ALLOCATION_UNIT_SIZE STATE COMPATIBILITY
------------------------------ -------------------- ----------- ------------------------------------------------------------
DATADG 1048576 MOUNTED 11.2.0.0.0
DATA 1048576 MOUNTED 11.2.0.0.0

Relançons maintenant la commande précédente pour ajouter un emplacement à mon OCR :

[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2684
Available space (kbytes) : 259436
ID : 1827476825
Device/File Name : +DATA
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/ocrconfig -add +DATADG
[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2684
Available space (kbytes) : 259436
ID : 1827476825
Device/File Name : +DATA
Device/File integrity check succeeded
Device/File Name : +DATADG
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

Impeccable, maintenant supprimons l’ancien emplacement, de sorte à ce que l’OCR ne soit uniquement stocké que dans le disk DATADG :

[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/ocrconfig -delete +DATA
[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2684
Available space (kbytes) : 259436
ID : 1827476825
Device/File Name : +DATADG
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

Ok, passons maintenant au Voting :

SQL> select adg.name, ad.disk_number, ad.header_status, ad.mode_status,
ad.path, ad.voting_file
from v$asm_diskgroup adg, v$asm_disk ad
where ad.voting_file='Y'
and adg.group_number = ad.group_number
order by ad.disk_number;

NAME DISK_NUMBER HEADER_STATU MODE_ST PATH V
------------------------------ ----------- ------------ ------- ---------------------------------------- -
DATA 0 MEMBER ONLINE /dev/oracleasm/disks/OCR Y

[RAC1]/home/oracle[+ASM1]:crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 924d1d9d1d124fd8bf9f457431a42ea4 (/dev/oracleasm/disks/OCR) [DATA]
Located 1 voting disk(s).

Je vais directement déplacer, via la commande REPLACE, le voting :

[RAC1]/home/oracle[+ASM1]:crsctl replace votedisk +DATADG
Successful addition of voting disk aef4e6b7c55b4f3cbf11e09d5c3143f8.
Successful deletion of voting disk 924d1d9d1d124fd8bf9f457431a42ea4.
Successfully replaced voting disk group with +DATADG.
CRS-4266: Voting file(s) successfully replaced

[RAC1]/home/oracle[+ASM1]:crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE aef4e6b7c55b4f3cbf11e09d5c3143f8 (/dev/oracleasm/disks/DATA) [DATADG]
Located 1 voting disk(s).

Parfait, on vérifie cependant sur ASM :

[RAC1]/home/oracle[+ASM1]:sqlplus / as sysasm
SQL> select adg.name, ad.disk_number, ad.header_status, ad.mode_status,
ad.path, ad.voting_file
from v$asm_diskgroup adg, v$asm_disk ad
where ad.voting_file='Y'
and adg.group_number = ad.group_number
order by ad.disk_number; 2 3 4 5 6

NAME DISK_NUMBER HEADER_STATU MODE_ST PATH V
------------------------------ ----------- ------------ ------- -------------------------------------------------- -
DATADG 0 MEMBER ONLINE /dev/oracleasm/disks/DATA Y

On tient le bon bout, il ne reste maintenant qu’à s’occuper des 2 instances ASM car son spfile est également stocké dans le diskgroup DATA.

SQL> sho parameter pfile;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string +DATA/clust2/asmparameterfile/registry.253.914670117

SQL> create pfile='/tmp/asminit.ora' from spfile;
File created.

SQL> create spfile='+DATADG' from pfile='/tmp/asminit.ora';
File created.

A ce stade, les instance ASM utilisent toujours le SPFILE qui est sur le diskgroup DATA, il faut donc faire un A/R d’ASM pour que les instances utilisent le nouveau spfile.
On peut cependant s’assurer que le spfile qui sera utilisé est bien celui dans +DATADG :


[RAC1]/oracle/product/11.2.0/grid/dbs[+ASM1]:asmcmd spget
+DATADG/clustdatacly2/asmparameterfile/registry.253.914689389

On fait donc un A/R d’ASM, et on vérifie que le Spfile est bien au bon endroit


[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/crsctl stop crs

[root@RAC1 database]# /oracle/product/11.2.0/grid/bin/crsctl start crs

Une fois le cluster de nouveau UP, une petite vérification :

SQL> sho parameter pfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string +DATADG/clustdatacly2/asmparameterfile/registry.253.914689389

Ok, on peut désormais démonter le diskgroup DATA, en vue de le renommer :

SQL> alter diskgroup data dismount ;
Diskgroup altered.

[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.DATA.dg
NAME=ora.DATA.dg
TYPE=ora.diskgroup.type
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE

Go pour renommer le diskgroup :

[RAC1]/home/oracle[+ASM1]:renamedg dgname=DATA newdgname=OCR asm_diskstring='/dev/oracleasm/disks/*' verbose=true
NOTE: No asm libraries found in the system

Parsing parameters..

Parameters in effect:

Old DG name : DATA
New DG name : OCR
Phases :
Phase 1
Phase 2
Discovery str : /dev/oracleasm/disks/*
Clean : TRUE
Raw only : TRUE
renamedg operation: dgname=DATA newdgname=OCR asm_diskstring=/dev/oracleasm/disks/* verbose=true
Executing phase 1
Discovering the group
Performing discovery with string:/dev/oracleasm/disks/*
Identified disk UFS:/dev/oracleasm/disks/OCR with disk number:0 and timestamp (33036811 117883904)
Checking for hearbeat...
Re-discovering the group
Performing discovery with string:/dev/oracleasm/disks/*
Identified disk UFS:/dev/oracleasm/disks/OCR with disk number:0 and timestamp (33036811 117883904)
Checking if the diskgroup is mounted or used by CSS
Checking disk number:0
Generating configuration file..
Completed phase 1
Executing phase 2
Looking for /dev/oracleasm/disks/OCR
Modifying the header
Completed phase 2
Terminating kgfd context 0x7ff8759030a0

Impeccable, on monte le diskgroup :

[RAC1]/home/oracle[+ASM1]:sqlplus / as sysasm

SQL> alter diskgroup OCR mount;
Diskgroup altered.

[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.OCR.dg
NAME=ora.OCR.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , OFFLINE
STATE=ONLINE on RAC1, OFFLINE

[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.DATA.dg
NAME=ora.DATA.dg
TYPE=ora.diskgroup.type
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE

Ici, on visualise d’une part que le diskgroup OCR n’est pas monté sur le second node, et qu’il reste l’ancien Diskgroup DATA visible du CRS.

Pour que le diskgroup OCR soit monté sur le second node, soit on démarre la ressource cluster, soit on fait un MOUNT du diskgroup depuis l’instance ASM du second noeud.

Pour cette fois, j’aime bien les commabdes donc je passe par ASM :

[RAC2]/home/oracle[+ASM2]:sqlplus / as sysasm

SQL> alter diskgroup OCR mount ;
Diskgroup altered.

[RAC2]/home/oracle[+ASM2]:crsctl stat res ora.OCR.dg
NAME=ora.OCR.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , ONLINE
STATE=ONLINE on RAC1, ONLINE on RAC2

On supprime maintenant l’ancienne ressource cluster du diskgroup DATA :

[RAC1]/home/oracle[+ASM1]:crsctl delete res ora.DATA.dg
[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.DATA.dg
CRS-2613: Could not find resource 'ora.DATA.dg'.

on vérifie sur le second noeud, histoire d’être sur :


[RAC2]/home/oracle[+ASM2]:crsctl stat res ora.DATA.dg
CRS-2613: Could not find resource 'ora.DATA.dg'.

Une vérification coté ASM :

SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;

MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
——- ———— ——- ——– ———- ———- —————————— ————————————————– ——————————-
CACHED MEMBER ONLINE NORMAL 455663 455263 DATADG_0000 /dev/oracleasm/disks/DATA
CACHED MEMBER ONLINE NORMAL 5130 4766 DATA_0000 /dev/oracleasm/disks/OCR

Ok nous avons donc maintenant des diskgroup ASM quasi cohérent, en effet, il me manque le renommage du disk asm « DATA_0000 » qui doit se nommer « OCR_0000« .

Mais là, pour le renommer, il n’y a pas trente six solutions que j’ai pu identifier :
– Soit on migre en RAC ASM 12c car depuis cette relase, ASM offre la possibilité de renommer directement les disks d’un Diskgroup « alter diskgroup DATADG rename disk OLD to NEW » ou encore «  alter diskgroup DATADG rename disks all« ,
– Soit on casse le DISKGROUP, et on le refait correctement (ce qui sous entend qu’une partie de ce que j’ai fait jusque la serait alors inutile, quoique intéressante cependant..)

Etant joueur et dans un contexte de test, je refait le diskgroup.

Démontage du diskgroup OCR sur les 2 nodes :

SQL> alter diskgroup OCR dismount ;
Diskgroup altered.

Ensuite :

SQL> drop diskgroup OCR force including contents;
Diskgroup dropped.

On vire la ressource cluster :

[RAC2]/home/oracle[+ASM2]:crsctl stat res ora.OCR.dg
NAME=ora.OCR.dg
TYPE=ora.diskgroup.type
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE

[RAC2]/home/oracle[+ASM2]:crsctl delete res ora.OCR.dg

On passe à la création du diskgroup, avec directement la compatibilité ASM en 11.2 histoire d’éviter les surprises quand je vais rebasculer mes fichiers.

SQL> create diskgroup OCR external redundancy disk '/dev/oracleasm/disks/OCR' attribute 'compatible.asm'='11.2.0.0.0';
Diskgroup created.

SQL> SELECT MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,TOTAL_MB,FREE_MB,NAME,PATH,LABEL FROM V$ASM_DISK;

MOUNT_S HEADER_STATU MODE_ST STATE TOTAL_MB FREE_MB NAME PATH LABEL
------- ------------ ------- -------- ---------- ---------- ------------------------------ -------------------------------------------------- -------------------------------
CACHED MEMBER ONLINE NORMAL 455663 455263 DATADG_0000 /dev/oracleasm/disks/DATA
CACHED MEMBER ONLINE NORMAL 5130 5078 OCR_0000 /dev/oracleasm/disks/OCR

[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.OCR.dg
NAME=ora.OCR.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , OFFLINE
STATE=ONLINE on RAC1, OFFLINE

On monte le diskgroup sur le second noeud, ou bien on démarre la ressource cluster qui lui est liée. Pour cette seconde fois, je fait un start de la ressource :

[RAC1]/home/oracle[+ASM1]:crsctl start res ora.OCR.dg -n RAC2
CRS-2672: Attempting to start 'ora.OCR.dg' on 'RAC2'
CRS-2676: Start of 'ora.OCR.dg' on 'RAC2' succeeded
[RAC1]/home/oracle[+ASM1]:crsctl stat res ora.OCR.dg
NAME=ora.OCR.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , ONLINE
STATE=ONLINE on RAC1, ONLINE on RAC2

Et voila, il ne me reste plus qu’a remettre l’OCR, le voting et enfin le spfile ASM dans ce nouveau diskgroup OCR , afin que cela soit indépendant du groupe de disque DATADG, qui lui hébergera de la Database.

Enjoy !

Micka