As encarnações são explicadas em uma resposta a outra pergunta neste site. A resposta menciona encarnações 'órfãs':
… Existem outros fatores que resultam em encarnações ORPHANED e backups obsoletos…
Vejo nos documentos do Oracle que V$DATABASE_INCARNATIONincluem uma STATUScoluna que pode ter valores de ORPHAN, CURRENTou PARENT, que devem estar relacionados.
O que são encarnações 'órfãs' e quais etapas resultariam em uma linha com STATUS= ORPHANin V$DATABASE_INCARNATION?
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 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 -> 2Usando 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 RESETLOGSe o banco de dados criou uma nova encarnação.
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 RESETLOGSpara 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:00Se 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 -> 3Vamos 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 RESETLOGSpara 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:00Se 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 -> 4O que aconteceu? Nós temos um órfão!
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 -> 4Então, o que aconteceu com a encarnação 3? A Encarnação 3 é ruim ou obsoleta ou o que dá?
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 ORPHANstatus 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.
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 ...
ORPHAN se esta é uma encarnação não atual que não é um ancestral direto da encarnação atual.
Passos para reproduzir:
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