Oracle y yo

ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service

Para poder resolver ese inconveniente debemos llevar a cabo los siguientes pasos

Seteamos nuestro ambiente para la instancia ASM

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=+ASM

export PATH=$PATH:/u01/app/oracle/product/11.2.0/grid/bin

Y procedemos a levantar la instancia ASM

[oracle@oracle11g ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 05:37:25 2010

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

SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service
SQL>

¿Cómo solucionamos este inconveniente?

Pues he acá la explicación

El demonio del Cluster Synchronization Service (cssd daemon) no queda online después del reboteo y como la instancia ASM , necesita ese demonio, pues por eso ASM no levanta

La forma de chequearlo

[oracle@oracle11g ~]$ crsctl check cssd
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon

[oracle@oracle11g ~]$ crsctl check has
CRS-4638: Oracle High Availability Services is online

[oracle@oracle11g ~]$ ps -fea | grep d.bin
oracle 6208 1 0 Apr15 ? 00:02:37 /u01/app/oracle/product/11.2.0/grid/bin/ohasd.bin reboot

Y efectivamente vemos que el servicio está abajo ... aunque el servicio ohasd este online

¿Cuál es la causa de este inconveniente?

Pues a partir de Oracle11gr2 los demonios cssd y diskmon no son levantados vía el oratab, ahora estos demonios son levantados por el HAS (High Availability Service) y registrados en un OCR local como un recurso más.

Para analizar esto, procedemos a ir al HOME de la instalación del Grid Infraestructure, que en el fondo es el HOME que soporta el ASM

Y analizamos los recursos existentes

[oracle@oracle11g ~]$ cd $ORACLE_HOME
[oracle@oracle11g grid]$ pwd
/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g grid]$ cd bin
[oracle@oracle11g bin]$ ./crsctl status resource -t

--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE

Como vemos , ambos demonios , inscritos como recursos se encuentran OFFLINE

Para ver el origen del problema, analizamos los recursos con su configuración en detalle

Nota : Solamente vamos a mostrar los recursos que tienen problemas (CSSD y DISKMON)

[oracle@oracle11g bin]$ ./crsctl status resource -p

NAME=ora.cssd
TYPE=ora.cssd.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/cssdagent%CRS_EXE_SUFFIX%
AGENT_HB_INTERVAL=0
AGENT_HB_MISCOUNT=10
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=30
CLEAN_ARGS=abort
CSSD_PATH=%CRS_HOME%/bin/ocssd%CRS_EXE_SUFFIX%
CSS_USER=oracle
DEGREE=1
DESCRIPTION="Resource type for CSSD"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
OMON_INITRATE=1000
OMON_POLLRATE=500
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
PROCD_TIMEOUT=1000
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=600
START_DEPENDENCIES=weak(concurrent:ora.diskmon)
START_TIMEOUT=600
STOP_DEPENDENCIES=hard(shutdown:ora.diskmon)
STOP_TIMEOUT=900
UPTIME_THRESHOLD=1m
VMON_INITLIMIT=16
VMON_INITRATE=500
VMON_POLLRATE=500

NAME=ora.diskmon
TYPE=ora.diskmon.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/orarootagent%CRS_EXE_SUFFIX%
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=20
CHECK_TIMEOUT=10
DEGREE=1
DESCRIPTION="Resource type for Diskmon"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
RESTART_ATTEMPTS=10
SCRIPT_TIMEOUT=60
START_DEPENDENCIES=weak(concurrent:ora.cssd)pullup:always(ora.cssd)
START_TIMEOUT=60
STOP_TIMEOUT=60
UPTIME_THRESHOLD=5s
USR_ORA_ENV=ORACLE_USER=oracle
VERSION=11.2.0.1.0

La propiedad AUTO_START esta seteada como NEVER o como 2 , para los demonios CDDS y DISKMON, esto implica que estos recursos no serán levantados nunca en un reincio por el HAS, y si el Cluster Synchronization Service no puede levantar, implica que la instancia ASM no puede partir.

Para solucionar el problema se debe configurar el AUTO_START para esos demonios (diskmon y cssd)

[oracle@oracle11g bin]$ ./crsctl modify resource "ora.cssd" -attr "AUTO_START=1"
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$ ./crsctl modify resource "ora.diskmon" -attr "AUTO_START=1"
[oracle@oracle11g bin]$

Una vez ejecutados esos comandos, procedemos a analizar nuevamente la configuración de los recursos

NAME=ora.cssd
TYPE=ora.cssd.type
AUTO_START=1

NAME=ora.diskmon
TYPE=ora.diskmon.type
AUTO_START=1

Verificamos los recursos y su estado actual

[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE
[oracle@oracle11g bin]$

Como podemos apreciar, ahora se encuentran con un TARGET ONLINE, lo que implica que se reiniciarán con un reboteo..

Pero se aprecia que el STATE es OFFLINE, eso implica que no están arriba los recursos, procedemos a levantarlos

[oracle@oracle11g bin]$ ./crs_start -all
Intentando iniciar `ora.cssd` en el miembro `oracle11g`
Intentando parar `ora.diskmon` en el miembro `oracle11g`
La parada de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.diskmon` en el miembro `oracle11g`
El inicio de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
El inicio de `ora.cssd` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.asm` en el miembro `oracle11g`
El inicio de `ora.asm` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.DATA.dg` en el miembro `oracle11g`
El inicio de `ora.DATA.dg` en el miembro `oracle11g` se ha realizado correctamente.

Y los volvemos a verificar

[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE oracle11g
ora.asm
ONLINE ONLINE oracle11g Started
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE ONLINE oracle11g
ora.diskmon
1 ONLINE ONLINE oracle11g

Ahora procedemos a levantar nuestra instancia ASM

Vale la pena recordar, que la instancia ASM ya no se levanta con el rol SYSDBA, existe uno nuevo llamado SYSASM , si nos conectamos con SYSDBA, aparecerá un error de privilegios

[oracle@oracle11g bin]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 06:05:11 2010

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

SQL> conn / as sysdba
Connected.
SQL> startup
ORA-01031: insufficient privileges
SQL>

Nos conectamos con el rol indicado y procedemos a subir la instancia ASM

SQL> conn / as sysasm
Connected.
SQL> startup
ASM instance started

Total System Global Area 284565504 bytes
Fixed Size 1336036 bytes
Variable Size 258063644 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted

PROBLEMA RESUELTO!!

Referencia

Nota : AFTER NODE REBOOT CSSD IS NOT STARTED IN 11gR2 Non-RAC [ID 947520.1]

[oracle@oracle11g bin]$ pwd
/u01/app/oracle/product/11.2.0/grid/bin
[oracle@oracle11g bin]$ echo $ORACLE_HOME
/u01/app/oracle/product/11.2.0/grid

Llamamos al utilitario asmcmd

[oracle@oracle11g bin]$
[oracle@oracle11g bin]$ asmcmd

ASMCMD>

Generamos un archivo con tags para XML con los cuales generaremos el diskgroup, este archivo contiene lo siguiente

Para visualizar el archivo CLICK ACÁ

Procedemos a ejecutar ese archivo xml , mediante el comando mkgrp dentro del utilitario asmcmd

ASMCMD> mkgrp '/home/oracle/disk.xml'

Una vez creado el DiskGroup verificamos su metadata

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 500 440 0 440 0 N DATA/

ASMCMD>

Forma 3 : Mediante utilitario SqlPlus

Validamos las variables de medio ambiente

[oracle@oracle11g ~]$ env | grep ORACLE
ORACLE_SID=+ASM
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g ~]$

Nos conectamos a SQL*Plus

[oracle@oracle11g ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Sat Mar 13 23:31:36 2010

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

SQL> conn / as sysasm
Connected.

Y generamos un DiskGroup

SQL> r
1* create diskgroup data external redundancy disk '/dev/raw/raw1','/dev/raw/raw2','/dev/raw/raw3','/dev/raw/raw4','/dev/raw/raw5'

Diskgroup created.

SQL> r
1* select group_number , name , state , total_mb from v$asm_diskgroup

GROUP_NUMBER NAME STATE TOTAL_MB
------------ ------------------------------ ----------- ----------
1 DATA MOUNTED 500

Nota : Nos tenemos que conectar con el nuevo rol de asm llamado sysasm , pues conectados como SYSDBA nos dará un error de privilegios

SQL> create diskgroup data external redundancy disk '/dev/raw/raw1','/dev/raw/raw2','/dev/raw/raw3','/dev/raw/raw4','/dev/raw/raw5';
create diskgroup data external redundancy disk '/dev/raw/raw1','/dev/raw/raw2','/dev/raw/raw3','/dev/raw/raw4','/dev/raw/raw5'
*

ERROR at line 1:
ORA-15260: permission denied on ASM disk group

Forma 4 : Mediante utilitario ASMCA

También se puede generar un diskgroup en formato silent, no es muy recomendado, pero sepan que existe.

Verificamos las variable de medio ambiente

[oracle@oracle11g bin]$ env | grep ORACLE
ORACLE_SID=+ASM
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g bin]$

Ejecutamos el comando asmca -silent

[oracle@oracle11g bin]$ asmca -silent -createDiskGroup -diskgroupname DATA -redundancy external -compatible.asm '11.2.0.0.0' -compatible.rdbms '11.2.0.0.0' -disk '/dev/raw/raw5'
-disk '/dev/raw/raw1' -disk '/dev/raw/raw2' -disk '/dev/raw/raw3' -disk '/dev/raw/raw4'

El grupo de discos DATA se ha creado correctamente.

Realizamos la validación del nuevo DiskGroup generado

[oracle@oracle11g bin]$ asmcmd

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 500 440 0 440 0 N DATA/

ASMCMD>

ASMCMD> quit
[oracle@oracle11g bin]$

Referencias :
Utilitario ASMCMD
Utilitario ASMCA



Espero les sirva.

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