A seguir, um pequeno gráfico que usarei para explicar quando os órfãos são criados nas encarnações de um banco de dados. É uma variação do gráfico que usei para explicar as encarnações na minha resposta à pergunta. Alguém pode me explicar o conceito "encarnação" no banco de dados Oracle de uma maneira fácil de entender?
Espero que você aproveite a viagem.
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
Restaurando o banco de dados no momento certo (1)
Em algum lugar, depois das 13:00 (13:00), alguém decide que o banco de dados deve ser restaurado para 12:00 (12:00 no meio-dia). O DBA aciona vários comandos do RMAN para restaurar o banco de dados nesse momento ou clica em uma GUI fantástica para iniciar uma restauração / recuperação de um fornecedor de terceiros.
O RMAN recupera o backup COMPLETO do banco de dados e todos os backups do Log de Arquivamento do disco / fita e os restaura no disco. Na fase de recuperação, o RMAN verificará se todas as informações relevantes estão disponíveis e encaminhará todas as transações concluídas para o Point in Time e reverterá todas as transações não concluídas para o Point in Time, para garantir que o banco de dados esteja em um estado consistente.
Antes que o banco de dados possa ser aberto ao público em geral, ele deve garantir que todos os backups futuros não entrem em conflito com os backups anteriores. É quando uma nova encarnação deve ser criada e acontece quando você executa o seguinte comando para abrir o banco de dados:
ALTER DATABASE OPEN RESETLOGS;
Você pode executar o seguinte script na sua instância para recuperar uma visão hierárquica de suas encarnações (atuais):
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;
A encarnação atual do banco de dados será semelhante 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 o gráfico, podemos ver que passamos do caminho que contém a encarnação 1 para o caminho com a encarnação 2, porque abrimos o banco de dados RESETLOGS
e o banco de dados criou uma nova encarnação.
Restaurando o banco de dados no momento certo (2)
Vamos supor novamente que o banco de dados continua em execução após a primeira ação de restauração / recuperação e, pouco depois das 15:00 (15:00), alguém decide que precisa iniciar uma nova restauração / recuperação de volta à hora inteira às 15:00 (15:00) do mesmo dia.
O RMAN restaurará os arquivos, recuperará o banco de dados e ativará um ALTER DATABASE OPEN RESETLOGS
para colocar o banco de dados novamente online. O número de encargos agora será definido como 3 e o primeiro backup às 16:00 conterá as informações:
INCARNATION# 3
SCN# 500
Time......... 16:00
Se consultarmos as encarnações no banco de dados usando o script acima, obteremos algo como isto:
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
Restaurando o banco de dados para apontar no tempo (3)
Vamos supor novamente que o banco de dados continua em execução após a segunda ação de restauração / recuperação e, pouco depois das 17:00 (17:00), alguém decide que precisa haver uma nova restauração / recuperação de volta às 14:00 (14:00) do mesmo dia.
O RMAN restaurará os arquivos, recuperará o banco de dados e ativará um ALTER DATABASE OPEN RESETLOGS
para colocar o banco de dados novamente online. O número de encarnação será agora definido como 4 e o primeiro backup às 18:00 conterá as informações:
INCARNATION# 4
SCN# 400
Time......... 18:00
Se consultarmos as encarnações no banco de dados usando o script acima, obteremos algo como isto:
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
O que aconteceu? Nós temos um órfão!
Encarnações Órfãs ...
Se você olhar para o gráfico, atualmente estamos na praça às 18:00 (18:00) com a Encarnação 4 e o SCN 400. Agora, se você seguir essa linha de volta ao início, poderá ver que passaríamos da encarnação 4 faça backup na encarnação 2 e depois na encarnação 1, que é quando o banco de dados foi criado.
Isso também corresponde à saída (simplificada) dos meus scripts.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
Então, o que aconteceu com a encarnação 3? A Encarnação 3 é ruim ou obsoleta ou o que dá?
Responda
Não, a encarnação 3 não é ruim, é apenas órfã.
Em uma escala maior, com mais tempo entre backups e restaurações, você ainda pode restaurar / recuperar o banco de dados em um ponto no tempo na linhagem da encarnação 3. Você acionaria o seguinte comando:
RESET DATABASE TO INCARNATION 3;
... e, em seguida, restaure / recupere o banco de dados nesse momento, como você restauraria / recuperaria um banco de dados.
O que o ORPHAN
status diz é que a encarnação 3 não está mais relacionada ao estado atual do banco de dados com a encarnação atual 4. A encarnação órfã 3 não é mais necessária para restaurar / recuperar o banco de dados ao longo da linha do tempo atual.
... Resultado em backups obsoletos
Agora, observando os backups do banco de dados em relação à encarnação órfã, o RMAN determina que os backups da encarnação órfã são OBSOLETE. Mas essa é uma história para perguntas e respostas diferentes ...