Hola usuario de nuestra página, hallamos la solución a tu pregunta, continúa leyendo y la obtendrás un poco más abajo.
Solución:
A continuación se muestra un gráfico breve que utilizaré para explicar cuándo se crean huérfanos en las encarnaciones de una base de datos. Es una variación del gráfico que utilicé para explicar las encarnaciones en mi respuesta a la pregunta ¿Alguien puede explicarme el concepto de “encarnación” en la base de datos de Oracle de una manera fácil de entender?
Espero que disfruten el viaje.
restore db +-----+ +-----+ +-----+
recover db | 2>3 | --> | 3 | --> | 3 | --> ...
resetlogs +-----+ +-----+ +-----+ ^
^ Incarn 3 3 | 3
/ SCN # 500 600 | 700
/ |
/ |
restore db +-----+ +-----+ +-----+ |
recover db | 1>2 | -------> | 2 | --> | 2 | --> ... |
resetlogs +-----+ +-----+ +-----+ ^ |
^ Incarn. 2 2 | 2 |
/ SCN # 300 400 | 500 |
/ | |
/ + --------------------+ |
+-----+ +-----+ +-----+ | +-----+ | +-----+
--> | 1 | --> | 1 | --> | 1 | --> ... | +-> | 2>4 | --> | 4 |
+-----+ +-----+ +-----+ ^ | restore db +-----+ | +-----+
Incarn. 1 1 1 | 1 2 | recover db | 4
SCN # 100 200 300 | 400 400 | resetlogs | 400
| | |
Backup 11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00 ----- 18:00
| | |
Restore/ (1) (2) (3)
Recovery
Restauración de la base de datos a un punto en el tiempo (1)
Un poco después de las 13:00 (1:00 p. M.), Alguien decide que la base de datos debe restaurarse a las 12:00 (12:00 del mediodía). El DBA activa un montón de comandos RMAN para restaurar la base de datos a ese punto en el tiempo o hace clic en una GUI fantástica para iniciar una restauración / recuperación de un proveedor externo.
RMAN recupera la copia de seguridad COMPLETA de la base de datos y todas las copias de seguridad del registro de archivo del disco / cinta y las restaura en el disco. En la fase de recuperación, RMAN verificará que toda la información relevante esté disponible y reenviará todas las transacciones finalizadas al Punto en el tiempo y revertirá todas las transacciones sin terminar al Punto en el tiempo, para garantizar que la base de datos esté en un estado consistente.
Antes de que la base de datos se pueda abrir al público en general, la base de datos debe asegurarse de que todas las copias de seguridad futuras no entren en conflicto con las copias de seguridad anteriores. Aquí es cuando se debe crear una nueva encarnación y sucede cuando ejecuta el siguiente comando para abrir la base de datos:
ALTER DATABASE OPEN RESETLOGS;
Puede ejecutar el siguiente script en su instancia para recuperar una vista jerárquica de sus encarnaciones (actuales):
set pages 50 --- repeat header every 50 records
set lines 230 --- set lines(ize) length to 230
column path format a40 --- set column path to alpha-numeric 40
alter sessiosn set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
--- set date format of date columns to something more detailed
select
INCARNATION#,
PRIOR_INCARNATION#,
RESETLOGS_CHANGE#,
RESETLOGS_TIME,
STATUS,
SYS_CONNECT_BY_PATH(INCARNATION#, ' -> ') Path
FROM v$database_incarnation
WHERE LEVEL >=1 START WITH INCARNATION# = '1'
CONNECT BY PRIOR INCARNATION# = PRIOR_INCARNATION#
ORDER BY LEVEL, Path, RESETLOGS_TIME;
La encarnación actual de la base de datos será similar a esta:
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-27 13:20:00 CURRENT -> 1 -> 2
Usando el gráfico podemos ver que nos hemos movido del camino que contiene la encarnación 1 al camino con la encarnación 2, porque hemos abierto la base de datos con RESETLOGS y la base de datos ha creado una nueva encarnación.
Restauración de la base de datos a un momento determinado (2)
Supongamos nuevamente que la base de datos sigue ejecutándose después de la primera acción de restauración / recuperación y poco después de las 15:00 (3 p.m.) alguien decide que es necesario realizar una nueva restauración / recuperación a la hora completa a las 15:00 (3 p.m.) del mismo día.
RMAN restaurará los archivos, recuperará la base de datos y activará un ALTER DATABASE OPEN RESETLOGS para volver a poner la base de datos en línea. El # DE ENCARNACIÓN se establecerá ahora en 3 y la primera copia de seguridad a las 16:00 contendrá la información:
INCARNATION# 3
SCN# 500
Time......... 16:00
Si consultamos las encarnaciones en la base de datos usando el script anterior, obtendremos algo como esto:
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-27 13:20:00 PARENT -> 1 -> 2
3 2 400 2018-07-27 15:20:00 CURRENT -> 1 -> 2 -> 3
Restauración de la base de datos a un momento determinado (3)
Supongamos nuevamente que la base de datos sigue ejecutándose después de la segunda acción de restauración / recuperación y poco después de las 17:00 (5 p.m.) alguien decide que es necesario realizar una nueva restauración / recuperación a las 14:00 (2 p.m.) del mismo día.
RMAN restaurará los archivos, recuperará la base de datos y activará un ALTER DATABASE OPEN RESETLOGS para volver a poner la base de datos en línea. El # DE ENCARNACIÓN se establecerá ahora en 4 y la primera copia de seguridad a las 18:00 contendrá la información:
INCARNATION# 4
SCN# 400
Time......... 18:00
Si consultamos las encarnaciones en la base de datos usando el script anterior, obtendremos algo como esto:
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-16 13:20:00 PARENT -> 1 -> 2
3 2 400 2018-07-17 15:20:00 ORPHAN -> 1 -> 2 -> 3
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
¿Lo que ha sucedido? ¡Tenemos un huérfano!
Encarnaciones huérfanas …
Si miras el gráfico, actualmente estamos parados en la plaza a las 18:00 (6:00 pm) con la Encarnación 4 y el SCN 400. Ahora si sigues esa línea de regreso al principio, puedes ver que pasaríamos de la encarnación. 4 retrocede hasta la encarnación 2 y luego vuelve a la encarnación 1, que es cuando se creó la base de datos.
Esto también corresponde a la salida (simplificada) de mis scripts.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
Entonces, ¿qué pasó con la Encarnación 3? ¿La Encarnación 3 es mala o rancia o qué pasa?
Respuesta
No, la Encarnación 3 no es mala, solo está huérfana.
En una escala mayor con más tiempo entre copias de seguridad y restauraciones, aún podría restaurar / recuperar la base de datos a un punto en el tiempo en el linaje de la encarnación 3. Debería activar el siguiente comando:
RESET DATABASE TO INCARNATION 3;
… y luego restaurar / recuperar la base de datos a ese punto en el tiempo como lo haría con cualquier otra restauración / recuperación de una base de datos.
Que ORPHAN el estado le dice, es que la encarnación 3 ya no está relacionada con el estado actual de la base de datos con la encarnación actual 4. La encarnación huérfana 3 ya no es necesaria para restaurar / recuperar la base de datos a lo largo de la línea de tiempo actual.
… Resultado en copias de seguridad obsoletas
Ahora, mirando las copias de seguridad de la base de datos en relación con la encarnación huérfana, RMAN determina que las copias de seguridad de la encarnación huérfana son OBSOLETAS. Pero esa es una historia para una sesión de preguntas y respuestas diferente …
RC_DATABASE_INCARNATION
HUÉRFANO si se trata de una encarnación no actual que no es un antepasado directo de la encarnación actual.
Pasos para reproducir:
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 CURRENT
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3393014
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 CURRENT
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3393975
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393200;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 PARENT
4 CURRENT
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 ORPHAN
4 ORPHAN
5 CURRENT
Reseñas y calificaciones del post
Si te sientes estimulado, eres capaz de dejar una sección acerca de qué te ha impresionado de este enunciado.