Início / dba / Perguntas / 159894
Accepted
Jason Krs
Asked: 2017-01-04 15:33:04 +0800 CST

Por que a recuperação de cache ORACLE cria blocos não confirmados durante a recuperação da instância?

  • 772

O seguinte é um trecho de um livro ORACLE

Durante a recuperação do cache, o Oracle reproduz as transações dos arquivos redo log online desde o último ponto de verificação. Durante essa operação de avanço, as alterações confirmadas e não confirmadas são aplicadas aos arquivos de dados. No final da operação rollforward, os arquivos de dados terão alterações confirmadas, alterações não confirmadas que foram gravadas nos arquivos de dados para liberar espaço no cache do buffer e alterações não confirmadas aplicadas pela operação rollforward . O banco de dados pode ser aberto assim que a recuperação do cache for concluída.

A frase em negrito acima é a que eu não entendo. Como um arquivo de redo log pode gerar dados não confirmados, já que todas as suas informações são registradas após o COMMIT?

Além disso, diz

Na fase de recuperação da transação da recuperação da instância, o Oracle aplica blocos de desfazer para reverter alterações não confirmadas em blocos de dados que foram gravados antes da falha da instância ou feitos pela operação de avanço durante a recuperação do cache .

Eu entendo que se os blocos sujos foram gravados no disco sem um COMMIT anterior (se possível), durante a recuperação da transação, os blocos de desfazer podem ser usados ​​para revertê-los. MAS como os blocos de desfazer podem ser usados ​​para reverter alterações não confirmadas (o que são essas alterações de qualquer maneira ...) introduzidas pela repetição de logs de refazer durante a recuperação do cache?

Hmmm, não entendo, pois o redo log online, que deve conter apenas informações confirmadas, cria informações não confirmadas durante a recuperação da instância.

oracle recovery

1 respostas

  1. Best Answer

    Como um arquivo de redo log pode gerar dados não confirmados, já que todas as suas informações são registradas após o COMMIT?

    LGWRprocesso libera redo logs do cache de buffer de redo log para arquivos de redo log on-line quando-

    1. Um commit de fogo do usuário explicitamente.
    2. Um terço do espaço no buffer de redo log é preenchido.
    3. Três segundos se passaram desde a última descarga refeita.
    4. DBWnprocesso grava buffer sujo no disco.

    Todos esses gatilhos refazem o flush, o que pode incluir transações não confirmadas.

    MAS como os blocos de desfazer podem ser usados ​​para reverter alterações não confirmadas (o que são essas alterações, afinal ...) introduzidas pela repetição de logs de redo durante a recuperação do cache?

    Deixe-me dar um exemplo, suponha que você tenha um bloco de dados que contém uma linha com uma única coluna com valor 5. Você simplesmente tenta atualizá-lo usando update tbl set col1=6. Durante este processo, undo é gerado para reproduzir seu valor original que é 5e redo é gerado para responder a transação, significa reproduzir o último valor que é 6.

    Em seguida, se esta transação não for confirmada e, infelizmente, a instância travar, durante a próxima inicialização, o Oracle (especificamente SMONo processo) pega os blocos que precisam ser recuperados no cache do buffer e reaplica as alterações usando redo logs e se alguém tentar ler o linha que você modificou antes, o Oracle simplesmente reverteu o bloco de dados contendo a linha para seu valor original que é 5 usando desfazer.

    Atualização: O trecho do log de alerta a seguir foi extraído deste blog .

    ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
read 80458 KB redo, 1721 data blocks need recovery
Started redo application at
Thread 1: logseq 490, block 52626
Recovery of Online Redo Log: Thread 1 Group 1 Seq 490 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo01.log
Recovery of Online Redo Log: Thread 1 Group 2 Seq 491 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo02.log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 492 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo03.log
Completed redo application of 15.26MB
Completed crash recovery at
Thread 1: logseq 492, block 31015, scn 6082434
1721 data blocks read, 1721 data blocks written, 80458 redo k-bytes read
Sun Jan 09 00:50:27 2011

    Isso mostra claramente que o número do bloco 1721precisa ser recuperado. E para fazer isso, o bloco é carregado na memória (buffer cache) e o redo é aplicado. O bloco é gravado de volta no arquivo de dados após a recuperação.

    Isso também é explicado em (Capítulo 9 Refazer e Desfazer, Como Refazer e Desfazer Funcionam Juntos, Página ) Livro Expert Oracle Architecture Terceira Edição de Thomas Kyte.

    De ASKTOM

    Olá Tom,

    1. Para fazer a recuperação de falha, o banco de dados precisa de blocos de dados (recuperação necessária) para ser trazido para o SGA. Posso saber qual processo os trará?.

    Obrigado

    Acompanhamento

    smon irá lê-los e aplicar redo a eles durante a fase de recuperação.

    Recuperação de instância/falha

    • 4

relate perguntas