Início / dba / Perguntas / 213317
Accepted
Jack Douglas
Asked: 2018-07-27 07:34:02 +0800 CST

O que é uma encarnação órfã?

  • 772

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 OBSOLETE…

Vejo nos documentos do Oracle que V$DATABASE_INCARNATIONinclui 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?

oracle recovery

2 respostas

  1. Best Answer

    A seguir está 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 forma 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 para um ponto no tempo (1)

    Em algum lugar um pouco depois das 13:00 (13:00) alguém decide que o banco de dados deve ser restaurado para 12:00 (12:00 meio-dia). O DBA aciona vários comandos do RMAN para restaurar o banco de dados para esse ponto no tempo 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 de log de arquivo 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 fará roll forward de todas as transações concluídas para o Point in Time e reverterá todas as transações inacabadas 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, o banco de dados 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 isso acontece quando você executa o seguinte comando para abrir o banco de dados:

    ALTER DATABASE OPEN RESETLOGS;

    Você pode executar o seguinte script em 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 com RESETLOGSe o banco de dados criou uma nova encarnação.

    Restaurando o banco de dados para um ponto no tempo (2)

    Vamos novamente assumir que o banco de dados continua em execução após a primeira ação de restauração/recuperação e um pouco depois das 15:00 (15:00) alguém decide que precisa de uma nova restauração/recuperação de volta para a hora completa às 15:00 (15:00) do mesmo dia.

    O RMAN restaurará os arquivos, recuperará o banco de dados e acionará um ALTER DATABASE OPEN RESETLOGSpara colocar o banco de dados online novamente. O INCARNATION# será agora 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 assim:

    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 um ponto no tempo (3)

    Vamos novamente assumir que o banco de dados continua em execução após a segunda ação de restauração/recuperação e um 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 acionará um ALTER DATABASE OPEN RESETLOGSpara colocar o banco de dados online novamente. O INCARNATION# 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 assim:

    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? Temos um órfão!

    Encarnações órfãs...

    Se você olhar para o gráfico, estamos atualmente 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, você pode ver que iríamos da encarnação 4 volte para a encarnação 2 e depois volte para a 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 para 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 para esse ponto no tempo, como faria com outra restauração/recuperação de um banco de dados.

    O que o ORPHANstatus lhe 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.

    ...Resultar em Backups Obsoletos

    Agora, olhando para os backups de banco de dados em relação à encarnação órfã, o RMAN determina que os backups da encarnação órfã são OBSOLETOS. Mas essa é uma história para uma sessão de perguntas e respostas diferente...

    • 8

  2. RC_DATABASE_INCARNATION

    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
    • 7

relate perguntas