Category: ASM (Automatic Storage Management)

Oracle11gr2 : Como crear diskgroups de distintas formas



En Oracle11gr2 , se pueden generar diskgroups de varias formas, he aquí la explicación :)





Forma 1 : Mediante utilitario ASMCA

Se ejecuta el utilitario asmca





Se carga la pantalla principal del asmca





Se ingresan los datos necesarios para la creación del diskgroups , si fuese necesario , se debe cambiar la ruta donde se descubren los raw devices





Al presionar ACEPTAR comienza a generar el Diskgroup





Y ahora podemos visualizar nuestro diskgroup recientemente generado








Forma 2 : Mediante utilitario ASMCMD

Tenemos que tener las variables de medioambiente apuntadas a nuestro home de Grid Infraestructure

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


by Ligarius
16.03.10. 13:38:44. 606 words, 104 views. Categories: Base de datos, Oracle11gR2, ASM (Automatic Storage Management) , Leave a comment »Send a trackback »

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, 1067 views. Categories: Base de datos, Oracle 10g, ASM (Automatic Storage Management) , 1 comment »Send a trackback »