Estou estudando um pouco de DBA e me deparei com falha/recuperação de instância.
Digamos que o usuário A faça DML e o usuário B também faça DML.
Neste ponto, acredito que seja seguro assumir que o cache de buffer de banco de dados contém blocos de tabela alterados e segmentos de desfazer, e também que o buffer de log contém informações de redo para o novo valor de blocos de tabela e o novo valor de segmentos de desfazer.
Caso 1: Nenhum usuário emite uma
COMMITe nenhuma gravação no disco por DBWn e falha de instância. Resultado: DB não corrompido. É como se o DML deles nunca tivesse ocorrido.Caso 2: Somente o usuário A emite um arquivo
COMMIT. As alterações não confirmadas do usuário B são gravadas no disco e a instância falha. O LGWR terá escrito dados suficientes no redo log , especialmente os segmentos de undo do usuário B , para que a fase de rollback da recuperação torne o banco de dados consistente novamenteCaso 3: Nenhum usuário emite a,
COMMITmas seus blocos de tabela alterados são antigos o suficiente para fazer o DBWn gravá-los em disco. Então BOOM! A instância falha. Como seráSMONrealizado o rollback para limpar blocos sujos de arquivos de dados aqui? Especialmente porque não há valores de segmento de desfazer para eles no log de refazer aqui.
Um bloco sujo só pode ser gravado em disco se todas as alterações até o momento da modificação desse bloco já tiverem sido gravadas nos redo logs . O Guia de Conceitos de Banco de Dados Oracle 12g2 diz
Portanto, após a recuperação de um banco de dados, ele contém todas as modificações até um determinado momento e nenhuma modificação que foi feita após esse período. Se uma transação foi confirmada, os redo logs contêm a modificação de sua transação e, portanto, suas modificações foram gravadas nos arquivos de dados durante a recuperação. As transações que não foram confirmadas ou apenas modificaram as estruturas de memória (buffer cache) e todas as modificações foram perdidas por causa do travamento, ou fizeram algumas modificações no arquivo, mas as informações de desfazer também foram gravadas nos arquivos que contêm o desfazer segmentos e essas informações de desfazer serão usadas para desfazer as alterações desta transação.
caso 3: Se um bloco sujo de um arquivo de dados for escrito de volta no disco, todas as alterações feitas antes da modificação desse bloco já estarão nos redo logs e, portanto, as informações de desfazer já estarão nos redo logs
caso 1: Se nenhum usuário emitir um commit, isso não significa que as alterações foram gravadas no arquivo de dados ou no redo log. Mas se algo foi gravado no disco, pode ser desfeito conforme descrito acima.
caso 2: alterações não confirmadas não devem ser gravadas em disco. É garantido apenas que as alterações confirmadas sejam gravadas no disco.