« Oracle11gr1 : DUPLICATE ACTIVE DATABASE de RMANOracle 11gr2 : Claúsula PREPROCESSOR para tablas externas »

Problema de la vida real : No se puede montar un Diskgroup en una instancia ASM



Estando en un cliente, realice una "inocua" |-| , bajada de servicios de Cluster y rebooteo de máquina

Baje la base de datos

$srvctl stop database -d


ervicios completos del Clusterware

$crs_stop -all


Para posteriormente , reiniciar los nodos

#reboot


Cuando volvieron los servicios a la máquina y levanto el Clusterware, me encuentro con este panorama

[oracle@dtv-ora-02 ~]$ crs_stat -t
Name Type Target State Host

------------------------------------------------------------
ora....SM1.asm application ONLINE ONLINE dtv-ora-01
ora....01.lsnr application ONLINE ONLINE dtv-ora-01
ora....-01.gsd application ONLINE ONLINE dtv-ora-01
ora....-01.ons application ONLINE ONLINE dtv-ora-01
ora....-01.vip application ONLINE ONLINE dtv-ora-01
ora....SM2.asm application ONLINE ONLINE dtv-ora-02
ora....02.lsnr application ONLINE ONLINE dtv-ora-02
ora....-02.gsd application ONLINE ONLINE dtv-ora-02
ora....-02.ons application ONLINE ONLINE dtv-ora-02
ora....-02.vip application ONLINE ONLINE dtv-ora-02
ora.ibs.db application ONLINE OFFLINE
ora....s1.inst application ONLINE OFFLINE
ora....s2.inst application ONLINE OFFLINE

Mmmm , malo muy malo.. no levanta mi base de datos , pensé que era problema del ASM , pero este se encontraba arriba (eso creí en un instante)

Procedí a levantar la base de datos a mano, tampoco levantaba pues no estaba el Diskgroup DATA, ingrese a ASM y monte el Diskgroup y apareció este error..

SQL> alter diskgroup DATA mount;
alter diskgroup DATA mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "3" is missing

SQL>

:( , el tema se estaba complicando, pero siempre esta Metalink, Soporte Oracle y claro , mucha lectura, por eso he aquí la solución al inconveniente y claro las validaciones que se llevaron a cabo, que todos debiesen tener en cuenta cuando se trabaje con ASM ;)

Catálogo de validaciones

a) Verificar las particiones físicas en cada uno de los nodos, debiesen estar todas y no presentar GAPs

$more /proc/partitions

b) Si estamos usando ASMLib, obtener un listado de los discos involucrados y consultarlos contra ASMLib

Una forma automática

#for i in `cd /dev/oracleasm/disks;ls *`;
do
/etc/init.d/oracleasm querydisk $i 2>/dev/null
done

Una forma manual

$ su - root
Password:
# cd /etc/init.d/
# ./oracleasm listdisks
VOL1
VOL2
VOL3
VOL4
# ./oracleasm querydisk VOL1
Disk "VOL1" is a valid ASM disk
# ./oracleasm querydisk VOL2
Disk "VOL2" is a valid ASM disk
# ./oracleasm querydisk VOL3
Disk "VOL3" is a valid ASM disk
# ./oracleasm querydisk VOL4
Disk "VOL4" is a valid ASM disk
# ./oracleasm scandisks
Scanning the system for Oracle ASMLib disks: [ OK ]
#

c) Verificar las particiones desde ambos nodos

#fdisk -l

d) Verificar en ambos nodos como fueron configurados los Raw Devices

# cat /etc/sysconfig/rawdevices
/dev/raw/raw1 /dev/sdc1
/dev/raw/raw2 /dev/sde1
/dev/raw/raw3 /dev/sdg1
/dev/raw/raw4 /dev/sdi1
/dev/raw/raw5 /dev/sdk1
/dev/raw/raw6 /dev/sdm1
/dev/raw/raw7 /dev/sdo1
/dev/raw/raw8 /dev/sdq1
/dev/raw/raw9 /dev/sds1
[root@dtv-ora-01 etc]#

e) Validar los privilegios y owner, sobre los Raw Devices generados, debiese tener acceso total el usuario Oracle, y claro... ser dueño de ellos
En ambos nodos , se debiese visualizar algo así
In node1

# ls -ltr /dev/raw/raw*
crwxrwxrwx 1 oracle oinstall 162, 1 Sep 11 16:46 /dev/raw/raw1
crwxrwxrwx 1 oracle oinstall 162, 2 Sep 11 16:46 /dev/raw/raw2
crwxrwxrwx 1 oracle oinstall 162, 3 Sep 11 16:46 /dev/raw/raw3
crwxrwxrwx 1 oracle oinstall 162, 4 Sep 11 16:46 /dev/raw/raw4
crwxrwxrwx 1 oracle oinstall 162, 5 Sep 11 16:46 /dev/raw/raw5
crwxrwxrwx 1 oracle oinstall 162, 7 Sep 11 16:46 /dev/raw/raw7
crwxrwxrwx 1 oracle oinstall 162, 6 Sep 11 16:46 /dev/raw/raw6
crwxrwxrwx 1 oracle oinstall 162, 8 Sep 11 16:46 /dev/raw/raw8
crwxrwxrwx 1 oracle oinstall 162, 9 Sep 11 16:46 /dev/raw/raw9

No con tantos privilegios, basta un 660

f)Obtener información formateada de mis instancias ASM y sobre sus diskgroups, para ello se siguió la nota
Note.470211.1 How To Gather/Backup ASM Metadata In A Formatted Manner

Lo anterior entrega el estado de los ASM Disk del Diskgroup

Primer dato a tener en cuenta ¿Por qué aparece el disco como PROVISIONED, siendo que forma parte del DiskGroup? ¿Se perdió la cabecera del archivo?

Ya tenemos la metadata, donde el HEADER_STATUS del ASM Disk indica que esta PROVISIONED, para cercionarnos, vemos la información de la cabecera del archivo raw, para así compararlo con la Metadata.

g)Obtención de información de la cabecera del Raw devices con el utilitario kfed (Utilitario interno de Oracle)

Para versiones 10.2.0.X hacía arriba, se debe ejecutar lo siguiente :

Cambiar de directorio donde se encuentra el kfed

cd $ORACLE_HOME/rdbms/lib


Generar el ejecutable kfed

$make -f ins_rdbms.mk ikfed (Ojo!!!, se escribe ikfed)


Verificar que se haya generado el kfed

$ls -ltr $ORACLE_HOME/bin/kfed


Finalmente , procedemos a leer la cabecera del Raw Devices

$ORACLE_HOME/bin/kfed read /dev/raw/raw6


Y eso , nos proporciona una salida similar a esta

[oracle@bin]$ kfed read /dev/raw/raw6
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2147483651 ; 0x008: TYPE=0x8 NUMB=0x3
kfbh.check: 2004180404 ; 0x00c: 0x77755db4
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISKVOL4 ; 0x000: length=12
kfdhdb.driver.reserved[0]: 877416278 ; 0x008: 0x344c4f56
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum: 3 ; 0x024: 0x0003
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATA_0003 ; 0x028: length=9
kfdhdb.grpname: DATA ; 0x048: length=4

kfdhdb.fgname: DATA_0003 ; 0x068: length=9
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32924622 ; 0x0a8: HOUR=0xe DAYS=0x1e MNTH=0x8 YEAR=0x7d9
kfdhdb.crestmp.lo: 987539456 ; 0x0ac: USEC=0x0 MSEC=0x32a SECS=0x2d MINS=0xe
kfdhdb.mntstmp.hi: 32924626 ; 0x0b0: HOUR=0x12 DAYS=0x1e MNTH=0x8 YEAR=0x7d9
kfdhdb.mntstmp.lo: 2526926848 ; 0x0b4: USEC=0x0 MSEC=0x376 SECS=0x29 MINS=0x25
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 51199 ; 0x0c4: 0x0000c7ff
kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 0 ; 0x0d4: 0x00000000
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32924622 ; 0x0e4: HOUR=0xe DAYS=0x1e MNTH=0x8 YEAR=0x7d9
kfdhdb.grpstmp.lo: 987471872 ; 0x0e8: USEC=0x0 MSEC=0x2e8 SECS=0x2d MINS=0xe
kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0x00000000
kfdhdb.ub4spare[2]: 0 ; 0x0f4: 0x00000000
kfdhdb.ub4spare[3]: 0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[4]: 0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[5]: 0 ; 0x100: 0x00000000
kfdhdb.ub4spare[6]: 0 ; 0x104: 0x00000000
kfdhdb.ub4spare[7]: 0 ; 0x108: 0x00000000
kfdhdb.ub4spare[8]: 0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[9]: 0 ; 0x110: 0x00000000
kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000
kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000
kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000
kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000
kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000
kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000
kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000
kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000
kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000
kfdhdb.ub4spare[22]: 0 ; 0x144: 0x00000000
kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000
kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000
kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000
kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000
kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000
kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000
kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000
kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000
kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000
kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000
kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000
kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000
kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000
kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000
kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000
kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000
kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000






Problema
La base de datos no parte ya que la instancia ASM no puede montar uno de sus diskgroup, justamente el diskgroup que contiene el archivo de inicialización para la base de datos.

El problema radica en que la Metadata de ASM me indica que el disco esta como PROVISIONED, o sea, es candidato a formar parte de cualquier diskgroup , es como un disco nuevo, pero al volcar la cabecera del raw devices, nos damos cuenta que ya pertenece a un DiskGroup.

Solución
Hay que sacar la información de la cabecera del Raw Devices como texto, y este texto ingresarlo nuevamente al Raw Devices, para que recalcule la cabecera y con ello reescriba en el diccionario de datos de ASM.

Implementación
1) Generar un respaldo de la cabecera del Raw Devices que se muestra como PROVISIONED

$ dd if=/dev/raw/raw6 of=/tmp/raw6.dd bs=1M count=20


2) Hacer un vaciado de la cabecera del Raw Devices, pero en texto

$kfed read /dev/raw/raw6 text=raw6.txt


3) Tomar el archivo de texto y devolverlo al Raw Devices , parece un paso tonto y sin sentido, pero al realizarlo, se recalculan muchas cosas ;)

$kfed merge /dev/raw/raw6 text=raw6.txt


4) Y si ahora se visualiza el V$ASM_DISK.HEADER_STATUS de ese Disk ASM, aparecerá como MEMBER, lo que indica que si está reconocido como miembro de un DiskGroup

sql> select path,header_status from v$asm_disk;

¿Y ahora? , pues sólo queda levantar la instancia ASM, levantar la base de datos y quedar como REY...

Espero les sirva ....

by Ligarius
17.09.09. 08:17:02. 1702 words, 6729 views. Categories: Base de datos, Oracle 10g, ASM (Automatic Storage Management) ,