Fix: Recuperar VG dañado por Oracle ASM |

Morpheus: The pill you took is part of a trace program. It’s designed to disrupt your input/output carrier signal so we can pinpoint your location.
Neo: What does that mean?
Cypher: It means fasten your seat belt Dorothy, ’cause Kansas is going bye-bye…

Cypher a Neo en The Matrix

La principal función del SysAdmin, es mantener el correcto funcionamiento del sistema, el cual, puede proporcionar diversos servicios; dentro de los cuales, uno de los de mayor importancia es alojar una base de datos.

Dentro de la industria, es estándar tener una base de datos robusta, generalmente en clúster, para ofrecer alta disponibilidad.

Uno de los productos más utilizados es Oracle Database, el cuál posee una característica muy reciente que es la de administrar sus propios dispositivos: Automatic Storage Management (ASM). Con lo que la tarea de administrar los dispositivos asignados, se relega al DBA; que trae con ello, ciertas ventajas al permitirle a la base (y a su DBA) administrar sus recursos más eficientemente.

Sin embargo, esto puedo puede traer consigo que puedan existir errores al momento de seleccionar los dispositivos que administre ASM; ya que , si no se realiza el analísis correspondiente, el dispositivo puede estar siendo utilizado por el Sistema Operativo.

En este post veremos como solucionar este incidente.

Conforme lo dice la documentación de Oracle: La instancia de ASM asegura que cualquier disco que se incluye en un grupo de discos es direccionable y utilizable. Esto requiere la lectura del primer bloque del disco para determinar si ya pertenece a un grupo de discos. Si no, un header se escribe. Lo que quiere decir que cuando se selecciona un disco para ser administrado por ASM, se formatea el primer bloque del disco.

Síntoma: El DBA comenta que el respaldo de archives había marcado error de I/O, por lo que solicita que revise el filesystem donde se aloja dicho respaldo.

Analísis: Primeramente, verificamos que en el messages que no exista algun mensaje de error, en cuanto a filesystems se refiere:

[root@ragnarok ~]# grep EXT3-fs /var/log/messages
Nov 29 10:44:59 ragnarok kernel: EXT3-fs error (device dm-4) in ext3_prepare_write: Journal has aborted
Nov 29 10:44:59 ragnarok kernel: EXT3-fs error (device dm-4): ext3_journal_start_sb: Detected aborted journal
Nov 29 15:27:29 ragnarok kernel: EXT3-fs warning (device dm-4): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
Nov 29 15:27:29 ragnarok kernel: EXT3-fs warning (device dm-4): ext3_clear_journal_err: Marking fs in need of filesystem check.
Nov 29 15:27:29 ragnarok kernel: EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
[root@ragnarok ~]#

En este caso se observa que si existe un error en el I/O. Al revisar los physical volumes, obtenemos:

[root@ragnarok ~]# pvs
Found duplicate PV JcqJMgIsgOv0NzQdVaWDt4tTLZh5Z7X0: using /dev/emcpowerq not /dev/sdaw
Couldn't find device with uuid 'JcqJMgIsgOv0NzQdVaWDt4tTLZh5Z7X0'.
Couldn't find all physical volumes for volume group DB-BKP.
Found duplicate PV Lze5padj4Yg5d2Gyz79O59V5mnX2fd92: using /dev/sdah not /dev/sdb
Couldn't find device with uuid 'Lze5padj4Yg5d2Gyz79O59V5mnX2fd92'.
Couldn't find all physical volumes for volume group DB-BKP.
...
Found duplicate PV N7fxUKWNG0xRYsekL9qLdoQ2joQeYpJT: using /dev/emcpowerp not /dev/sdau
Couldn't find device with uuid 'N7fxUKWNG0xRYsekL9qLdoQ2joQeYpJT'.
Couldn't find all physical volumes for volume group DB-BKP.
PV VG Fmt Attr PSize PFree
/dev/sda4 VG1 lvm2 a- 518.16G 60.00M
Couldn't find all physical volumes for volume group DB-BKP.
[root@ragnarok ~]#

Al revisar el log de sudo, se encuentra que antes de la fecha del mensaje de error de I/O se agregó un disco a ASM:

[root@ragnarok ~]# tail -10 /var/log/sudo.log
..
Nov 28 20:18:15 2012 : oracle : TTY=pts/1 ; PWD=/home/oracle ; USER=root ;
COMMAND=/usr/sbin/oracleasm listdisks
Nov 28 20:29:37 2012 : oracle : TTY=pts/1 ; PWD=/home/oracle ; USER=root ;
COMMAND=/usr/sbin/oracleasm createdisk DB_DATA10 /dev/emcpowero1
[root@ragnarok ~]#

De un respaldo de la configuración [1a Ley del SysAdmin], identificamos el dispositivo dañado:

[root@ragnarok ~]# pvs /dev/emcpowero
Found duplicate PV CeoH1PxI0l755BYenmzcveeTd9Axrccv: using /dev/emcpowero not /dev/sdm
Found duplicate PV CeoH1PxI0l755BYenmzcveeTd9Axrccv: using /dev/sdav not /dev/emcpowero

PV VG Fmt Attr PSize PFree
/dev/sdav1 DB-BKP lvm2 a- 344.23G 21.47G
[root@ragnarok ~]#

Diagnóstico: Erróneamente, el disco /dev/sdav [/dev/emcpowero] fue asignado a ASM, y éste, escribió en el primer sector del mismo, corrompiendo el logical volume, así como el filesystem.

Solución: Debido a la magnitud de la falla, la solución consta de varios pasos:

1. Desasignar el disco de ASM

Este paso debe ser con el apoyo del DBA, ya que nos tiene que indicar cuando ASM ya soltó por completo el dispositivo. Para esto se ejecuta el comando:

[root@ragnarok ~]# oracleasm deletedisk DB_DATA10
[root@ragnarok ~]# oracleasm scandisk

Esto se puede comprobar en el log de la base de datos, el cual, generalmente, se encuentra en:

[root@ragnarok ~]# grep DB_DATA10 /u01/app/oracle/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log
NOTE: Assigning number (2,4) to disk (ORCL:DB_DATA10)
NOTE: cache opening disk 4 of grp 2: DB_DATA10 label:DB_DATA10
SQL> alter diskgroup DB_DBPRD_DATA_GROUP1 drop disk 'DB_DATA10'
SUCCESS: alter diskgroup DB_DBPRD_DATA_GROUP1 drop disk 'DB_DATA10'
SUCCESS: grp 2 disk DB_DATA10 emptied
NOTE: erasing header on grp 2 disk DB_DATA10
NOTE: process 5737 initiating offline of disk 4.2526578120 (DB_DATA10) with mask 0x7e in group 2
WARNING: Disk DB_DATA10 in mode 0x7f is now being offlined
NOTE: cache closing disk 4 of grp 2: DB_DATA10
[root@ragnarok ~]#

2. Restaurar los physical volumes

Una vez que ASM ha dejado de manejar el dispositivo, iniciamos con la recuperación de los physical volumes. Conforme la documentación de CentOS ó la de Novell, buscamos el último archivo de configuración de LVM:

[root@ragnarok ~]# ls -ltr /etc/lvm/archive
Y de éste obtenemos los UIDs de los dispositivos del volume group:

[root@ragnarok ~]# more /etc/lvm/archive/DB-BKP_00006.vg
# Generated by LVM2: Fri Nov 23 16:17:39 2012

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'lvextend -L+50G /dev/DB-BKP/y01LV'"

creation_host = "ragnarok" # Linux ragnarok 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64
creation_time = 1353709059 # Fri Nov 23 16:17:39 2012

DB-Y01 {
id = "H4SRBU-6KqV-Ktwk-rhpF-FzhS-aXWg-biiAOJ"
seqno = 6
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "PlNTa2-i0Tk-TZUZ-cpLV-0BlU-lPYl-OXSmcO"
device = "/dev/emcpowerw1" # Hint only

status = ["ALLOCATABLE"]
dev_size = 721917952 # 344.237 Gigabytes
pe_start = 384
pe_count = 88124 # 344.234 Gigabytes
}

pv1 {
id = "fRO1Tk-E2YN-Q8ul-vDcQ-j67o-9FsL-SsaSYM"
device = "/dev/emcpowerx1" # Hint only

--More--(15%)

Con este dato recuperamos, uno por uno, los physical volumes:

[root@ragnarok ~]# pvcreate --uuid "PlNTa2-i0Tk-TZUZ-cpLV-0BlU-lPYl-OXSmcO" --restorefile /etc/lvm/archive/DB-BKP_00006.vg /dev/emcpowerw1
[root@ragnarok ~]# pvcreate --uuid "fRO1Tk-E2YN-Q8ul-vDcQ-j67o-9FsL-SsaSYM" --restorefile /etc/lvm/archive/DB-BKP_00006.vg /dev/emcpowerx1
..
[root@ragnarok ~]# pvcreate --uuid "fRrEQs-Wjcx-VFqn-0wbu-Fj2B-bhdV-CXP6Dn" --restorefile /etc/lvm/archive/DB-BKP_00006.vg /dev/sdav1

3. Restaurar el volume group

Con los physical volumes restaurados, recuperamos el volume group:

[root@ragnarok ~]# vgcfgrestore DB-BKP
[root@ragnarok ~]# vgchange -a y
[root@ragnarok ~]# vgscan
[root@ragnarok ~]# vgs

Con el volume group restaurado, podríamos montar el filesystem, sin embargo, recordemos que ASM escribió en el primer sector del disco, por lo que es necesario regenerar el logical volume.

4. Regenerar el logical volume

Para regenerar el logical volume, primero, removemos el volume group y después los physical volumes

[root@ragnarok ~]# vgremove DB-BKP
[root@ragnarok ~]# pvremove /dev/emcpowerw1
..
[root@ragnarok ~]# pvremove /dev/emcpowero1

Con los physical volumes removidos de LVM, podemos, para regenerar un logical volume más limpio, eliminar las particiones que tienen los dispositivos, para que sean agregados al volume group sin partición:

[root@ragnarok ~]# fdisk -l /dev/emcpowerp

Disk /dev/emcpowerp: 369.6 GB, 369623040000 bytes
255 heads, 63 sectors/track, 44937 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x7a7cdf06

Device Boot Start End Blocks Id System
/dev/emcpowero1 1 44937 360956421 83 Linux
[root@ragnarok ~]# fdisk /dev/emcpowerp

The number of cylinders for this disk is set to 44937.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): d
Selected partition 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@ragnarok ~]#

Una vez eliminada la partición, creamos nuevamente los physical volumes:

[root@ragnarok ~]# pvcreate /dev/emcpowerp
No physical volume label read from /dev/emcpowerp
Physical volume "/dev/emcpowerp" successfully created
[root@ragnarok ~]#

Y con todos los physical volumes creados, crear de nuevo el volume group:

[root@ragnarok ~]# vgcreate DB-BKP /dev/emcpowerp /dev/emcpowerw /dev/emcpowerx /dev/emcpowery /dev/emcpowerz /dev/sdan /dev/sdap /dev/sdaq /dev/sdar /dev/sdas /dev/sdav /dev/sdn
Volume group "DB-BKP" successfully created
[root@ragnarok ~]#

Creamos el logical volume:

[root@ragnarok ~]# lvcreate -L+4.01T -n y01 DB-BKP
Logical Volume "y01" successfully created
[root@ragnarok ~]#

5. Montar el filesystem y dejarlo disponible para su uso

Con el logical volume recreado desde cero, le damos formato y lo montamos para que pueda ser utilizado:

[root@ragnarok ~]# mkfs.ext3 /dev/DB-BKP/y01
[root@ragnarok ~]# mount /dev/DB-BKP/y01 /y01
[root@ragnarok ~]# chown -R oracle:oinstall /y01
[root@ragnarok ~]# df -h /y01
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/DB--BKP-y01
4.0T 195M 4.0T 1% /y01
[root@ragnarok ~]#

Por último, verificamos que no exista error en la salida del scan del volume group:

[root@ragnarok ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/emcpowerp DB-BKP lvm2 a- 344.23G 0
/dev/emcpowerw DB-BKP lvm2 a- 344.23G 0
/dev/emcpowerx DB-BKP lvm2 a- 344.23G 0
/dev/emcpowery DB-BKP lvm2 a- 344.23G 0
/dev/emcpowerz DB-BKP lvm2 a- 344.23G 0
/dev/sdan DB-BKP lvm2 a- 344.23G 0
/dev/sdap DB-BKP lvm2 a- 344.23G 0
/dev/sdaq DB-BKP lvm2 a- 344.23G 0
/dev/sdar DB-BKP lvm2 a- 344.23G 0
/dev/sdas DB-BKP lvm2 a- 344.23G 0
/dev/sdav DB-BKP lvm2 a- 344.23G 0
/dev/sdn DB-BKP lvm2 a- 344.23G 24.57G
[root@ragnarok ~]#

Y que ASM no tome discos que no le corresponden:

[root@ragnarok ~]# blkid
/dev/sdo1: LABEL="DB_DATA09" TYPE="oracleasm"
/dev/sdp1: LABEL="DB_DATA06" TYPE="oracleasm"
/dev/sdq1: LABEL="DB_DATA08" TYPE="oracleasm"
/dev/sdr1: LABEL="DB_DATA05" TYPE="oracleasm"
/dev/sds1: LABEL="DB_DATA04" TYPE="oracleasm"
/dev/sdt1: LABEL="DB_DATA07" TYPE="oracleasm"
/dev/sdu1: LABEL="DB_ARCH02" TYPE="oracleasm"
/dev/sdv1: LABEL="DB_DATA03" TYPE="oracleasm"
/dev/sdw1: LABEL="DB_ARCH01" TYPE="oracleasm"
/dev/sdx1: LABEL="DB_DATA01" TYPE="oracleasm"
/dev/sdy1: LABEL="DB_DATA02" TYPE="oracleasm"
/dev/sdaa1: LABEL="DB_VOTE01" TYPE="oracleasm"
/dev/sdab1: LABEL="DB_VOTE02" TYPE="oracleasm"
/dev/sdad1: LABEL="DB_ARCH03" TYPE="oracleasm"
/dev/sdax1: LABEL="DB_DATA09" TYPE="oracleasm"
/dev/sday1: LABEL="DB_DATA06" TYPE="oracleasm"
/dev/sdaz1: LABEL="DB_DATA08" TYPE="oracleasm"
/dev/sdbd1: LABEL="DB_DATA07" TYPE="oracleasm"
/dev/emcpowern1: LABEL="DB_DATA09" TYPE="oracleasm"
/dev/emcpowerk1: LABEL="DB_DATA06" TYPE="oracleasm"
/dev/emcpowerm1: LABEL="DB_DATA08" TYPE="oracleasm"
/dev/emcpowerj1: LABEL="DB_DATA05" TYPE="oracleasm"
/dev/emcpoweri1: LABEL="DB_DATA04" TYPE="oracleasm"
/dev/emcpowerl1: LABEL="DB_DATA07" TYPE="oracleasm"
/dev/emcpowere1: LABEL="DB_ARCH02" TYPE="oracleasm"
/dev/emcpowerh1: LABEL="DB_DATA03" TYPE="oracleasm"
/dev/emcpowerc1: LABEL="DB_ARCH01" TYPE="oracleasm"
/dev/emcpowerf1: LABEL="DB_DATA01" TYPE="oracleasm"
/dev/emcpowerg1: LABEL="DB_DATA02" TYPE="oracleasm"
/dev/emcpowera1: LABEL="DB_VOTE01" TYPE="oracleasm"
/dev/emcpowerb1: LABEL="DB_VOTE02" TYPE="oracleasm"
/dev/sdac1: LABEL="DB_VOTE03" TYPE="oracleasm"
/dev/sdbb1: LABEL="DB_DATA05" TYPE="oracleasm"
/dev/sdbe1: LABEL="DB_ARCH02" TYPE="oracleasm"
/dev/sdbf1: LABEL="DB_DATA03" TYPE="oracleasm"
/dev/sdbg1: LABEL="DB_ARCH01" TYPE="oracleasm"
/dev/emcpowerac1: LABEL="DB_ARCH03" TYPE="oracleasm"
/dev/emcpowerab1: LABEL="DB_VOTE03" TYPE="oracleasm"
/dev/sdbc1: LABEL="DB_DATA04" TYPE="oracleasm"
/dev/sdbh1: LABEL="DB_DATA01" TYPE="oracleasm"
/dev/sdbi1: LABEL="DB_DATA02" TYPE="oracleasm"
/dev/sdbk1: LABEL="DB_VOTE01" TYPE="oracleasm"
/dev/sdbl1: LABEL="DB_VOTE02" TYPE="oracleasm"
/dev/sdbm1: LABEL="DB_VOTE03" TYPE="oracleasm"
/dev/sdbn1: LABEL="DB_ARCH03" TYPE="oracleasm"
[root@ragnarok ~]#

Espero les sirva.

2 Responses to Fix: Recuperar VG dañado por Oracle ASM

Hector Lara says:

December 4, 2012 at 3:10 pm

Gracias Pedro por el material, que sirvió para este Post. Ja ja ja, mi tio siempre decia que hay que temerle mas a una persona con demasiada iniciativa.

- dark_axl says:
  
  December 4, 2012 at 3:18 pm
  
  Cualquier semejanza con la realidad, es omitida a propósito…

Fix: Recuperar VG dañado por Oracle ASM

1. Desasignar el disco de ASM

2. Restaurar los physical volumes

3. Restaurar el volume group

4. Regenerar el logical volume

5. Montar el filesystem y dejarlo disponible para su uso

Like this:

Related

2 Responses to Fix: Recuperar VG dañado por Oracle ASM

Leave a Reply Cancel reply

about me

dark_axl

Social Media

@dark_axl

@rootzilopochtli

Facebook Page

5 Top Posts

Obtenga Fedora!

@rootzilopochtli

@dark_axl

Facebook Page

Suscríbete por correo

Fix: Recuperar VG dañado por Oracle ASM

1. Desasignar el disco de ASM

2. Restaurar los physical volumes

3. Restaurar el volume group

4. Regenerar el logical volume

5. Montar el filesystem y dejarlo disponible para su uso

Share this:

Like this:

Related

2 Responses to Fix: Recuperar VG dañado por Oracle ASM

Leave a Reply Cancel reply

about me

dark_axl

Social Media

@dark_axl

@rootzilopochtli

Facebook Page

5 Top Posts

Obtenga Fedora!

@rootzilopochtli

@dark_axl

Facebook Page

Suscríbete por correo