El siguiente es un breve gráfico 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 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 al punto en el tiempo (1)
Un poco después de las 13:00 (1pm) alguien decide que la base de datos debe ser restaurada a las 12:00 (12 del mediodía). El DBA activa varios comandos RMAN para restaurar la base de datos a ese punto en el tiempo o hace clic en una interfaz gráfica de usuario 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 avanzará todas las transacciones finalizadas al punto en el tiempo y revertirá todas las transacciones no terminadas 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. Esto 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 de la ruta que contiene la encarnación 1 a la ruta con la encarnación 2, porque hemos abierto la base de datos con RESETLOGSy la base de datos ha creado una nueva encarnación.
Restauración de la base de datos al punto en el tiempo (2)
Supongamos de nuevo que la base de datos continúa ejecutándose después de la primera acción de restauración / recuperación y un poco después de las 15:00 (3pm) alguien decide que necesita volver a restablecer / restaurar a la hora completa a las 15:00 (3pm) el mismo día.
RMAN restaurará los archivos, recuperará la base de datos y se activará ALTER DATABASE OPEN RESETLOGSpara que la base de datos vuelva a estar en línea. El INCARNATION # ahora se establecerá 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 utilizando 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 al punto en el tiempo (3)
Supongamos nuevamente que la base de datos continúa ejecutándose después de la segunda acción de restauración / recuperación y un poco después de las 17:00 (5pm) alguien decide que debe haber una nueva restauración / recuperación de nuevo a las 14:00 (2pm) el mismo día.
RMAN restaurará los archivos, recuperará la base de datos y se activará ALTER DATABASE OPEN RESETLOGSpara que la base de datos vuelva a estar en línea. El INCARNATION # ahora se establecerá 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 utilizando 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 el cuadrado a las 18:00 (6pm) 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 copia de seguridad a la encarnación 2 y luego 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? ¿Es la Encarnación 3 mala o rancia o qué da?
Responder
No, la encarnación 3 no es mala, solo queda huérfana.
En una escala más grande 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. Activaría 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 otra restauración / recuperación de una base de datos.
Lo que el ORPHANestado 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, bien RMAN determina que las copias de seguridad de la encarnación huérfana son OBSOLETAS. Pero esa es una historia para un Q & A diferente ...