El estado no documentado “M” de un respaldo en RMAN

El estado no documentado “M” de un respaldo en RMAN

No es raro que Oracle le haga falta detalles a su documentación , y esto es sólo otro caso de esta enfermedad.

Tenemos una base de datos en la que tenemos dos copias del mismo backup set, uno lo tenemos en el FRA, la otra en un disco externo, que de vez en cuando la copia se elimina de este segundo disco. Pero, ¿qué sucede después de hacer un crosscheck y una de las 2 copias  no se encuentra? El del FRA está disponible y el que está en el disco externo ha expirado, como vas a ver esto cuando hagas un LIST en RMAN?

En cuanto a la documentación de 11.2 para el comando LIST, sólo dice que el estado de un respaldo puede estar AVAILABLE, UNAVAILABLE, o EXPIRED, pero como puedes ver a continuación, este no es el caso de nuestra base de datos 🙂

RMAN> list backup summary;

using target database control file instead of recovery catalog

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1986 B F A DISK 17-APR-13 1 2 NO *
1987 B F M DISK 17-APR-13 1 2 NO *
1988 B F A DISK 17-APR-13 1 2 NO *
1989 B F A DISK 19-APR-13 1 1 NO TAG000661
1990 B A A DISK 19-APR-13 1 1 YES BUP_ARCH_FRA

La primera vez que vi esto, se me hizo curioso en cuanto a lo que significa el sentido del status M (y es al día de hoy  que todavía no sé el significado exacto, pero tengo mis suposiciones). Si hago un trace de mi comando LIST BACKUP SUMMARY, puedo ver exactamente lo que yo sabía que estaba ocurriendo:

pythian@oracleenespanol.local /home/pythian/working/antunez
pythian $ rman target / debug trace rman.trc
Recovery Manager: Release 11.2.0.3.0 - Production on Fri Apr 19 16:02:56 2013

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

RMAN-06005: connected to target database: TESTDB (DBID=1834739652)

RMAN> list backup summary;

Este es un pequeño resultado del trace que hice :

DBGMISC: 339 BS (datafile) key=1987 recid=1987 stamp=812962808 setstamp=812962807 setcount=2021
DBGMISC: level=1 level_i=-1 piececount=1 keepopts=0, site_key=0 [16:03:27.544]
DBGMISC: site_key=0 [16:03:27.544]
DBGMISC: chid=NIL parm=NIL [16:03:27.544]
DBGMISC: flags= [16:03:27.544]
DBGMISC: valid backup set list is [16:03:27.544]
DBGMISC: 1 VBS copy#=1 tag=BACKUP_CONTROLFILE_FRA deviceType=DISK status=A
DBGMISC: 1 BPIECEX key=3502 recid=3502 stamp=812962808
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=+FRA/test/backupset/2013_04_17/ncnnf0_backup_controlfile_fra_0.297.812962809
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: 2 VBS copy#=2 tag=BACKUP_OF_BACKUPSET deviceType=DISK status=X
DBGMISC: 1 BPIECEX key=3538 recid=3538 stamp=813024283
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=/backupdisk/TEST_bck/db_bckset_backup_TEST2_04-18-2013_v5o79kvn_1_2.rman
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: restore target list is [16:03:27.545]
DBGMISC: 1 ACT type=full fromSCN=0 toSCN=307822519 fno=0
DBGMISC: CURCF

Como puedes ver arriba, una copia ha expirado y la otra está disponible, también cuando el resultado del comando LIST tiene un asterisco “*”,  se debe a que cada copia tiene un TAG diferente,  para la etiqueta del backupset con clave 1987.

Ambas conductas son perfectamente normales, pero no vas a encontrar esto en cualquier lugar de la documentación de Oracle, por lo que la próxima vez que veas esto en tu comando LIST, conocerás el significado exacto de este estado. ¿Has visto esto antes en tus listados de RMAN?

P.D. Para mí significa Múltiple o Mixta.

Rene Antunez
[email protected]
No Comments

Sorry, the comment form is closed at this time.