El caso curioso del datafile que “pertenecía” a dos Bases de Datos

04 Dec El caso curioso del datafile que “pertenecía” a dos Bases de Datos

En primer lugar quiero empezar diciendo que tengo una idea de cómo sucedió esto, pero no he sido capaz de recrear esta situación, ya que esto me fue heredado, de igual manera tuve la suerte de que el tablespace que tenía el problema era un tablespace DUMMY por lo que no causó un problema.

Ahora si a la descripción del problema, lo que pasa es que tengo una Base de Datos fuente con una ubicación de los datafiles en + DATA1/SOURCE, pero en algún momento alguien añadió una segunda ubicación para la realizar algunas pruebas en un tablespace TEST1 en +DATA2/TEST, esta base de datos fuente se duplicó a través de RMAN hacia 2 bases de datos, llameseles  a ellas DUP1 y DUP2. En el comando duplicate de RMAN , se uso el parámetro DB_FILE_NAME_CONVERT para cambiar la ubicación de los datafiles de la base de datos de origen hacia DUP1 o DUP2, pero en este parámetro solo se puso para la ubicacion de +DATA1/SOURCE y no para +DATA2/TEST .

Lo que se puso en el comando RMAN fue lo siguiente:

DB_FILE_NAME_CONVERT '+DATA1/SOURCE','DATA1/DUP1'

Como debería de haber sido:

DB_FILE_NAME_CONVERT '+DATA1/SOURCE','+DATA1/DUP1','+DATA2/TEST','+DATA1/DUP1'

Y porque el diskgroup y directorio de + DATA2/TEST existen donde DUP1 y DUP2 residiría, no causo ningún problema cuando se corrió el comando DUPLICATE, y esto es algo que todavía es  desconocido para mí, el duplicado termino con éxito para ambas bases de datos y no surgió ningún problema al abrirlas con resetlogs, como lo hace el comando.

Como probablemente ya saben, cuando se emite el comando DUPLICATE, la DBID es implicitamente cambiada, y lo que hace esto es que actualiza el controlfile con el dbid nuevo y también las cabeceras de los datafiles, de esa manera es como sabrá que estos XX datafiles pertenecen a la base de datos NN.

Una vez que ambas bases de datos estaban arriba y corriendo, corri un respaldo de las bases de datos, DUP1 termino exitosamente, el respaldo de DUP2 falló con el siguiente error :

RMAN-06169: could not read file header for datafile 148 error reason 9
RMAN-06056: could not access datafile 148

Una de las primeras cosas que hice fue correr un VALIDATE DATABASE, y me mostraba el mismo error:

RMAN> VALIDATE DATABASE;
Starting validate at 29-NOV-12using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=145 instance=DUP21 device type=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: SID=164 instance=DUP21 device type=DISK RMAN-06169: could not read file header for datafile 148 error reason 9RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of validate command at 11/29/2012 01:40:41RMAN-06056: could not access datafile 148

Lo siguiente que hice fue ver a donde pertenecía el datafile 148 y de igual manera el DBID de  DUP2, ya que el error de la cabecera me llevó a buscar por ahi

DUP21 >select DBID,open_mode from v$database;
 
      DBID OPEN_MODE
---------- ------------------------------------------------------------
2211912429 READ WRITE
 
DUP21 >select file_name from dba_data_files where TABLESPACE_NAME='TEST1';
 
FILE_NAME
--------------------------------------------------------------------------------
+DATA2/test/test01.dbf
 
 
DUP21 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE

Debido al error 06169 RMAN  me decía que no podía leer la cabecera del datafile, hice un volcado de la esta.

DUP21 >oradebug setmypid

Statement processed.

DUP21 >oradebug unlimit

Statement processed.

DUP21 >oradebug dump file_hdrs 3

Statement processed.

DUP21 >oradebug tracefile_name

Y en efecto vi que el DBID de test01.dbf pertenecía a DUP1, que había sido la primera de las dos bases de datos duplicadas

V10 STYLE FILE HEADER:
        Compatibility Vsn = 186646528=0xb200000
        Db ID=4005607769=0xeec0b959, Db Name='DUP1'

Así que, para nada mas estar seguro , fui a DUP1 a verificar, y sí, era el mismo que el DBID del volcado de la cabecera , y de igual manera el tablespace TEST1 estaba en línea, así como en DUP2

DUP11 >select DBID,open_mode from v$database;
 
      DBID OPEN_MODE
---------- ------------------------------------------------------------
4005607769 READ WRITE

DUP11 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE
 
DUP11 >select file_name from dba_data_files where TABLESPACE_NAME='TEST1';
 
FILE_NAME
--------------------------------------------------------------------------------
+DATA2/test/test01.dbf

DUP11 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE

Porque ese tablespace en particular era de ninguna utilidad para la aplicación, simplemente lo tire.

DUP21 >ALTER TABLESPACE TEST1 OFFLINE IMMEDIATE;

Tablespace altered.

DUP21 >DROP TABLESPACE TEST1;

Tablespace dropped.

Lo que te puedes llevar de esta entrada

Tengo que decir que esto es con un OH en 11.2.0.3 con un GI  en 11.2.0.3 en RHEL 5 x86_64, lo que te diria es que cada vez que haces un duplicado y utilizas el DB_FILE_NAME_CONVERT, asegúrate de que todos los lugares están cubiertos. Pero lo realmente me intriga es la forma en que DUP2 fue capaz de abrirse con resetlogs sin que esto fuera un problema, voy a tratar de recrear esto y actualizar este post, siempre y cuando lo logre hacer.