© marcelo bezerra de alcântarabanco de dados ii - transação - 1 disciplina banco de dados ii...
TRANSCRIPT
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 1
Disciplina Disciplina Banco de Dados IIBanco de Dados II
Recuperação de falhaRecuperação de falha
Msc, Marcelo Bezerra de Alcântara
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 2
ObjetivosObjetivos
1. Compreender os tipos de falhas;
1. Compreender a necessidade do uso do subsistema de reabilitação;
1. Definir as técnicas utilizadas para a reabilitação.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 3
BibliografiaBibliografia
1. ELMASRI, Ramez; NAVATHE, Shamkant B, Sistemas de banco de dados. 4. ed. Pearson Brasil, 2005.
1. Capítulo 19
2. KORTH, Henry F.; SILBERSCHATZ, Abraham Sistemas de banco de dados. 3. ed, São Paulo: Makron Books, 1999.
1. Capítulo 13
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 4
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 5
Recuperação de FalhasRecuperação de Falhas
• Garantia de atomicidade e durabilidade de Transações– requer um SGBD tolerante a falhas
• Tolerância a falhas em BDs– capacidade de conduzir o BD a um estado
passado consistente, após a ocorrência de uma falha que o deixou em um estado inconsistente
– baseia-se em redundância de dados– não é um mecanismo 100% seguro– responsabilidade do subsistema de recovery do
SGBD
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 6
Subsistema de Subsistema de RecoveryRecovery
• Controles– durante o funcionamento normal do SGBD
• manter informações sobre o que foi atualizado no BD pelas transações
• realizar cópias periódicas do BD
– após a ocorrência de uma falha• executar ações para retornar o BD a um estado consistente• ações básicas
– UNDO: desfazer uma atualização no BD
– REDO: refazer uma atualização no BD
• Considerações sobre o seu projeto– tipos de falhas a tratar– técnica de recovery a aplicar
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 7
Ações Básicas de Ações Básicas de RecoveryRecovery• Transaction UNDO
– uma transação não concluiu suas operações– as modificações realizadas por esta transação no BD são desfeitas
• Global UNDO– uma ou mais transações não concluíram as suas operações– as modificações realizadas por todas estas transações no BD são
desfeitas
• Partial REDO– na ocorrência de uma falha, algumas transações podem ter
concluído suas operações (committed), mas suas ações podem não ter se refletido no BD
– as modificações realizadas por estas transações são refeitas no BD
• Global REDO– no caso de um comprometimento do BD, todas as transações
committed no BD são perdidas– as modificações realizadas por todas estas transações no BD são
refeitas
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 8
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 9
Tipos de FalhasTipos de Falhas
• Falha de Transação– uma transação ativa termina de forma anormal– causas
• violação de RI, lógica da transação mal definida, deadlock, cancelamento pelo usuário, ...
– não compromete a memória principal e a memória secundária (disco, em geral)
– falha com maior probabilidade de ocorrência – seu tempo de recuperação é pequeno
• ação: Transaction UNDO
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 10
Tipos de FalhasTipos de Falhas
• Falha de sistema– o SGBD encerra a sua execução de forma
anormal– causas
• interrupção de energia, falha no SO, erro interno no SW do SGBD, falha de HW, ...
– compromete a memória principal e não compromete o disco
– falha com probabilidade média de ocorrência – seu tempo de recuperação é médio
• ações: Global UNDO e Partial REDO
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 11
Tipos de FalhasTipos de Falhas
• Falha de meio de armazenamento– o BD torna-se total ou parcialmente inacessível– causas
• setores corrompidos no disco, falha no cabeçote de leitura/gravação, ...
– não compromete a memória principal e compromete o disco
– falha com menor probabilidade de ocorrência – seu tempo de recuperação é grande
• ação: Global REDO
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 12
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 13
Estruturas de armazenamentoEstruturas de armazenamento
• Armazenamento volátil– Seu conteúdo não sobrevive a uma falha do
sistema– Memória, buffer em memória
• Armazenamento não volátil– Seu conteúdo sobrevive a uma falha do
sistema.– Discos, fitas, memória flash.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 14
Estruturas de armazenamentoEstruturas de armazenamento
• Armazenamento estável– Forma mítica de armazenamento que
sobrevive a qualquer situação– Pode-se obter aproximações, mantendo
múltiplas cópias em mídias não voláteis, armazenadas em diferentes locais.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 15
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 16
Acesso a dadosAcesso a dados
• Blocos físicos são aqueles blocos existentes no disco
• Blocos de buffer são blocos alocados temporariamente em memória– O buffer do sistema operacional é controlado
pelo SGBD, através de chamadas de baixo nível.
– Ou, é desativado, sendo implementado pelo SGBD.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 17
Acesso a dadosAcesso a dados
• Movimentos de blocos entre discos e memória são iniciados a partir de duas operações:– input(B) transfere um bloco físico B para
memória.– output(B) transfere um bloco de buffer B para
o disco, substituindo o bloco físico apropriado.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 18
Acesso a dadosAcesso a dados
• Cada transação possui sua área de memória• Transações transferem itens de dados entre sua
área de memória e o buffer utilizando as seguintes operações:– Read(X) atribui o valor do dado X para uma variável
local x.– Write(X) atribui o valor de uma variável local x para um
dado X, localizado em um bloco de buffer– Ambas operações podem necessitar a realização de um
input(BX) antes da atribuição, se o bloco B onde X está localizado não estiver no buffer.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 19
Acesso a dadosAcesso a dados
• Transações– Realizam read(X) quando acessam X pela primeira
vez– Todos acessos subsequentes são realizados a sua
cópia local.– Após o último acesso, transações podem executar
write(X).
• output(BX) não é realizado necessariamente após write(X). O SGBD pode realizar o output no momento que julgar mais adequado.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 20
Acesso a dadosAcesso a dados
x
Y A
B
x1
y1
BufferBuffer Block A
Buffer Block B
input(A)
output(B)
read(X)write(Y)
Disco
Memória de T1
Memória de T2
Memória
x2
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 21
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 22
Técnicas de recuperaçãoTécnicas de recuperação
• Técnicas de recuperação são técnicas que garantem a consistência, atomicidade e durabilidade de transações, mesmo com a ocorrência de falhas.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 23
• Possuem duas partes:
1. Ações realizadas durante o funcionamento normal do SGBD para coletar informações suficientes que permitam recuperar falhas
1. Ações realizadas após a falha para recuperar a base de dados a um estado consistente, garantindo o isolamento e durabilidade das transações.
Técnicas de recuperaçãoTécnicas de recuperação
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 24
Técnicas de Técnicas de RecoveryRecovery
• Baseadas em Log– modificação imediata do BD
• técnica UNDO/REDO• técnica UNDO/NO-REDO
– modificação postergada do BD• técnica NO-UNDO/REDO
– recuperação de meio de armazenamento• técnica ARCHIVE/DUMP/REDO
• Baseadas em Shadow Pages• técnica NO-UNDO/NO-REDO
recuperação de falhas de transação e de sistema
recuperação de falhas de transação e de sistema
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 25
Técnicas Baseadas em Técnicas Baseadas em LogLog• Técnicas mais comuns de recovery• Utilizam um arquivo de Log (ou Journal)
– registra seqüencialmente as atualizações feitas por transações no BD
• é consultado em caso de falhas para a realização de UNDO e/ou REDO de transações
– mantido em uma ou mais cópias em memória secundária (disco, fita, ...)
– tipos de log• log de UNDO
– mantém apenas o valor antigo do dado (before image)
• log de REDO– mantém apenas o valor atualizado do dado (after image)
• log de UNDO/REDO (mais comum)– mantém os valores antigo e atualizado do dado
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 26
Tipos de Registro no Tipos de Registro no LogLog• Supõe-se que toda transação possui um
identificador único gerado pelo SGBD
• Para fins de recuperação de falhas, operações read não precisam ser gravadas– úteis apenas para outros fins (auditoria, estatísticas, ...)
• Principais tipos de registro– início de transação: <start Tx>
– commit de transação: <commit Tx>
– atualização: <write Tx,X,beforeImage,afterImage>
não é necessário em log REDO
não é necessário em log UNDO
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 27
Exemplo de Exemplo de LogLog
read(A)read(D)write(D)
T1
read(B)write(B)read(D)write(D)
T2
read(C)write(B)read(A)write(A)
T3
<start T3><write T3,B,15,12><start T2><write T2,B,12,18><start T1><write T1,D,20,25><commit T1><write T2,D,25,26><write T3,A,10,19><commit T3><commit T2>...
Log
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 28
Tipos de Registro no Tipos de Registro no LogLog
• Forma alternativa de representar atualizações– considera a operação DML feita no BD
• insert: <write Tx,X,INSERT,afterImage>
• update: <write Tx,X,UPDATE,beforeImage,afterImage>
• delete: <write Tx,X,DELETE,beforeImage>
• A indicação do tipo de operação facilita o entendimento do que deve ser UNDO ou REDO no BD
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 29
Gerenciamento de Gerenciamento de BufferBuffer
• Buffer– conjunto de blocos da memória principal
• considera-se bloco e página conceitos sinônimos
• O SGBD é responsável pela gerência de alguns buffers– buffers para dados, para processamento de
transações e para o Log– ele assume o controle desses buffers, ao invés
do SO, requisitando apenas serviços de leitura/escrita de blocos ao SO
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 30
Gerenciamento de Gerenciamento de BufferBuffer
buffers de memória
. . .
controle
do SGBD
proc. detransações
dados(cache)
Log
backup(s)do BD
backup(s)do Log
Log
BDread / write
archive
write
read (UNDO / REDO)
archive
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 31
Gerenciamento de Gerenciamento de BufferBuffer
• Técnicas de recovery devem sincronizar os buffers de log e de dados– princípio básico
• um bloco atualizado na cache só pode ser gravado no BD após o histórico dos dados atualizados neste bloco ter sido gravado no Log em disco
– Write-Ahead-Log (WAL)
– uma transação Tx só pode passar para o estado efetivada (committed) após todas as suas atualizações terem sido gravadas no BD segundo o princípio WAL
• O SGBD aplica técnicas de gerenciamento de buffer– estas técnicas influenciam as técnicas de recovery
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 32
Técnicas de Gerência de Técnicas de Gerência de BufferBuffer
• NOT-STEAL– um bloco na cache utilizado por uma transação Tx não
pode ser gravado antes do commit de Tx
• bloco possui um bit de status indicando se foi (1) ou não (0) modificado
• vantagem: processo de recovery mais simples - evita dados de transações inacabadas sendo gravadas no BD
• STEAL– um bloco na cache utilizado por uma transação Tx pode
ser gravado antes do commit de Tx
• necessário se algum dado é requisitado do BD por outra transação e não há blocos disponíveis na cache
• o bloco “vítima” é escolhido através de alguma técnica de SO– LRU, FIFO, ...
• vantagem: não há necessidade de manter blocos bloqueados por transações
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 33
Técnicas de Gerência de Técnicas de Gerência de BufferBuffer
• FORCE– os blocos que mantêm dados atualizados por uma
transação Tx são imediatamente gravados no BD quando Tx alcança o commit
• deve-se saber quais os blocos que Tx atualizou dados
– vantagem: garante a durabilidade de Tx o mais cedo possível - permite o REDO de Tx em caso de falha
• NOT-FORCE– os blocos que mantêm dados atualizados por Tx não são
imediatamente gravados no BD quando Tx alcança o commit
– vantagem: blocos atualizados podem permanecer na cache e serem utilizados por outras transações, após o commit de Tx (reduz custo de acesso a disco)
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 34
Modificação postergadaModificação postergada
• No algoritmo de modificação postergada, os registros de log são imediatamente gravados, mas as operações de write na base de dados são postergadas para o final da transação.
• Não é necessário armazenar os valores antigos quando houver atualização de dados.
• Quando a última operação é executada, a transação passa a Efetivada– Grava-se no log <commit TID>– Os registros de alterações são lidos no log e
executados na base de dados
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 35
Modificação postergadaModificação postergada
• Durante uma recuperação, uma transação deve ser refeita se, e somente se, estiver gravado no log <start TID> e <commit TID>.– Refazer a transação grava os novos valores na base
de dados
• Nunca é necessário desfazer uma transação na base de dados.
• Falhas podem ocorrer durante– Enquanto as modificações da transação são
executadas– Durante uma recuperação
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 36
Modificação postergadaModificação postergada
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A - 50 C:- C- 100
write (A) write (C)
read (B)
B:- B + 50
write (B)
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 37
Modificação postergadaModificação postergada
(a): nenhum redo é necessário
(b): redo(T0), pois existe um <commit T0>
(c): redo(T0) seguido de redo(T1), pois existe <commit T0> e <commit T1>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 38
Modificação imediataModificação imediata
• No algoritmo de modificação imediata, é possível que transações não encerradas tenham suas alterações realizadas na base de dados.– Registros de log devem ser gravados antes de
alterar a base de dados, não necessariamente de forma imediata.
– Os registros de log devem armazenar os valores antigos.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 39
Modificação imediataModificação imediata
– A gravação dos blocos atualizados pode ocorrer a qualquer momento, antes ou depois do final da transação.
– A ordem em que os blocos são gravados pelo SGBD pode ser diferente da ordem realizada pela aplicação.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 40
Modificação imediataModificação imediata
• A recuperação baseia-se em duas operações:– Undo(T), que retorna aos valores anteriores ao
início da transação e Redo(T), que grava os valores ao final da transação.
• As operações devem ser idempotentes– Mesmo que uma operação seja realizada
diversas vezes, o resultado final permanece idêntico.
• Necessário para o caso de falhas durante a recuperação
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 41
Modificação imediataModificação imediata
• Recuperação– Uma transação é desfeita (undo) se o log
contém um registro de start e não contem registro de commit.
– Uma transação é refeita se o log contem contém registro de start e commit.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 42
Modificação imediataModificação imediata
(a): desfazer a transação T0.
(b): refazer T0 e desfazer T1.
(c): refazer T0 e T1.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 43
ExercícioExercício
• Considere as transações abaixa e responda que operações devem ser tomadas pelo sistema de recuperação de falhas, tendo como base a técnica de modificação postergada. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 44
RespostaResposta
Realizar a operação de REDO de T1
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 45
ExercícioExercício
• Considere as transações abaixa e responda que operações devem ser tomadas pelo sistema de recuperação de falhas, tendo como base a técnica de modificação imediata. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 46
RespostaResposta
Realizar a operação de REDO de T1 e UNDO de T0
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 47
ExercícioExercício
• Considere as transações abaixa e responda que valores devem estar no banco de dados (A, B e C), tendo como base a técnica de modificação imediata. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 48
RespostaResposta
A = Não pode saberB = Não pode saberC = Não pode saber
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 49
ExercícioExercício
• Considere as transações abaixa e responda que valores devem estar no banco de dados (A, B e C), tendo como base na técnica de modificação postergada. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 50
RespostaResposta
A = 50B = 50C = Não pode saber
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 51
CheckpointsCheckpoints
• Problemas na recuperação– Arquivos grandes de log tornam a
recuperação muito lenta.– Transações que já tenham gravado seus
valores na base de dados são desnecessariamente refeitas
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 52
CheckpointsCheckpoints
• Checkpoints– Grava todos os registros de log em um
meio de armazenamento.– Grava todos os blocos de dados presentes
em memória para o disco– Grava um registro <checkpoint> no
arquivo de log.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 53
CheckpointsCheckpoints
• Durante a recuperação, apenas as transações mais recentes são consideradas1. Procurar de trás para frente o último
checkpoint.
2. Procurar para trás o último registro de <start TID>, de qualquer transação.
3. Considerar apenas os registros existentes a frente.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 54
CheckpointsCheckpoints
4. Para todas as transações que não possuam um registro <commit>, realizar undo(T)
• Necessário apenas no esquema de modificações imediatas.
5. Para todas as transações com <commit T> no log, realizar redo(T).
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 55
CheckpointsCheckpoints
Desconsiderar T1
Refazer T2 e T3.
Desfazer T4.
TcTf
T1
T2
T3
T4
checkpoint system failure
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 56
ExercícioExercício
• Considere as transações abaixa e responda que operações devem ser tomadas pelo sistema de recuperação de falhas, tendo como base a técnica de modificação postergada. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
< CHECKPOINT>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 57
RespostaResposta
Não faz nada
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 58
ExercícioExercício
• Considere as transações abaixa e responda que operações devem ser tomadas pelo sistema de recuperação de falhas, tendo como base a técnica de modificação imediata. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
< CHECKPOINT>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 59
RespostaResposta
Realizar o UNDO de T0
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 60
Técnica ARCHIVE/DUMP/REDOTécnica ARCHIVE/DUMP/REDO
• Técnica baseada em Log para recuperação de falha de meio de armazenamento
• Operação ARCHIVE– ocorre durante o funcionamento normal do SGBD– gravação de uma ou mais cópias backup do BD em
dispositivos diferentes de memória secundária– disparo manual ou automático (periódico)– deve-se suspender o início de novas transações– nenhuma transação pode estar ativa
• se existem transações nesse estado, deve-se aguardar até elas encerrarem com sucesso
– o Log corrente é “descartado” (excluído ou mantido associado ao backup anterior do BD) e um novo Log (“zerado”) é iniciado
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 61
Técnica ARCHIVE/DUMP/REDOTécnica ARCHIVE/DUMP/REDO
• Operações DUMP + REDO– realizam o recovery de uma falha no BD– procedimento
• restaura o BD a partir do último backup (DUMP)• realiza uma varredura forward do Log, realizando REDO das
transações committed• as transações ativas no momento da falha podem ser re-
submetidas à execução pelo SGBD– já que não houve perda de dados na memória principal
• Técnicas baseadas em Log requerem um Log seguro– archive do Log também deve ser realizado
• com freqüência igual ou superior ao archive do BD
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 62
ARCHIVE/DUMP/REDO - ExemploARCHIVE/DUMP/REDO - Exemplo
T1
T2
T3
T4
T5
tempo
falha no BD intenção dearchive
ARCHIVE
T6
DUMP backup BDREDO T4 e T6
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 63
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 64
Página sombra / Página sombra / ShadowShadow
• Página sombra é um mecanismo não baseado em log, útil para transações serializadas.
• Para cada página de dado manipulada por uma transação, duas cópias em disco são mantidas.– Corrente: onde os novos valores são gravados– Sombra: que não sofre alterações, mantém os
dados no estado inicial.
• Ao final da transação, uma delas é mantida e a outra descartada.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 65
Técnica Baseada em Técnica Baseada em Shadow PagesShadow Pages
• Supõe a existência de uma tabela de blocos (páginas) de disco que mantém dados do BD– Tabela de Páginas Corrente (TPC)
• A TPC é copiada para uma Tabela de Páginas Shadow (TPS) a cada nova transação Tx
– páginas atualizadas por Tx são copiadas para novas páginas de disco e TPC é atualizada
– TPS não é atualizada enquanto Tx está ativa
• Em caso de falha de Tx, TPC é descartada e TPS torna-se a TPC– não é preciso acessar o BD para realizar restaurações
• Técnica– NO-UNDO/NO-REDO (com FORCE)
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 66
Técnica Técnica Shadow PagesShadow Pages
disco
Tabela de PáginasCorrente (TPC)
Tabela de PáginasShadow (TPS)
(não é atualizada)
5
4
3
2
1
5
4
3
2
1
x=5 y=10 z=20
x=5 y=15 z=25
a=1 b=2 c=3
a=5 b=2 c=15
cópias das páginas 2 e 5com dados atualizados por Tx
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 67
Shadow Pages - Shadow Pages - Procedimento Procedimento
1) Quando uma transação Tx inicia
– TPS TPC– FORCE TPS
2) Quando Tx atualiza dados de uma página P
– se é a primeira atualização de Tx em P• se P não está na cache então busca P no disco• busca-se uma página livre P’ na Tabela de Páginas
Livres (TPL)• P’ P (grava nessa página livre em disco)
• apontador de P na TPC agora aponta para P’
– atualiza-se os dados em P
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 68
Shadow Pages – Shadow Pages – Procedimento (cont.) Procedimento (cont.)
3) Quando Tx solicita commit– FORCE das páginas P1, ..., Pn atualizadas por Tx que
ainda não foram para disco• com FORCE da TPC atualizada primeiro• lembre-se que P1, ..., Pn estão sendo gravadas em páginas
diferentes no disco
• Falha antes ou durante o passo 3– não é preciso UNDO pois TPS mantém as páginas do
BD consistentes antes de Tx
– faz-se TPC TPS
• Falha após o passo 3– não é preciso REDO pois as atualizações de Tx estão
garantidamente no BD
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 69
Técnica Técnica Shadow Pages - Shadow Pages - DesvantagensDesvantagens
• Adequada a SGBD monousuário– uma transação executando por vez– SGBD multiusuário
• gerenciamento complexo!
• Não mantém dados do BD clusterizados
• Requer coleta de lixo– quando Tx encerra, existem páginas obsoletas
• páginas obsoletas devem ser incluídas na TPL
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 70
ExercícioExercício
• Considere as transações abaixa e responda que operações devem ser tomadas pelo sistema de recuperação de falhas, tendo como base a técnica de Shadow Pages. Considere o log gerado!
• Duas transaçõesT0: read (A) T1 : read (C)
A: - A * 50 C:-C- 100
write (A) write (C)
read (B)
B:- B + 150
write (B)
Log de execução
<T0, Start>
<T1, Start>
<T0, A, 10, 500>
<T1, C, 100, 0>
<T1 COMMIT>
<T0, B, 50, 200>
< CHECKPOINT>
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 71
RespostaResposta
Não realiza nada
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 72
SumárioSumário
1. Subsistema de reabilitação2. Tipos de falhas 3. Estruturas de armazenamento4. Acesso a dados5. Técnicas de recuperação
I. Técnica baseada em Loga) Logb) Gerenciamento de buffersc) Checkpointsd) Técnica de modificação postegadae) Técnica de modificação Imediataf) Técnica ARCHIVE / DUMP / REDO
II. Técnica Baseada em Shadow Pages6. Backup
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 73
BackupBackup
• Procedimentos de backup são necessários em qualquer ambiente
• Deve-se considerar as hipóteses mais remotas– Esperar o inesperado– Considerar os custos para a empresa se não for
possível recuperar a base de dados de forma consistente.
• Deve-se estabelecer uma política consistente e mantê-la persistemente
• Os DBAs devem treinar a ocorrência de falhas.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 74
Tipos de BackupTipos de Backup
• Backup total– É realizada uma cópia completa da base de
dados– A base de dados deve estar indisponível para
os demais usuários.– Em caso de falha, basta recarregar a última
cópia da base de dados e aplicar todos os logs da última cópia em diante.
– É mais cara em termos de armazenamento e tempo de indisponibilidade
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 75
Tipos de BackupTipos de Backup
• Backup incremental– São gravadas apenas as atualizações sofridas
na base de dados desde o último backup.– Também requer que a base de dados se torne
indisponível para os demais usuários.– Para recuperar uma base de dados, é
necessário retomar o último backup total e aplicar todos backups incrementais, na ordem cronológica adequada.
– Necessita menos espaço de armazenamento e menos tempo de indisponibilidade para os usuários
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 76
Tipos de BackupTipos de Backup
• Backup on-line– A cópia de segurança é gravada com a base de
dados disponível para os usuários.– Ao iniciar a cópia, cria-se um arquivo de log
específico.– Todas as alterações realizadas durante o
backup são registradas neste arquivo de log.– Ao final, o arquivo de log é gravado no backup– A recuperação é realizada aplicando os dados
no backup e, imediatamente, o arquivo de log correspondente.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 77
Tipos de BackupTipos de Backup
• Grupos de backup– Pode-se agrupar uma ou mais tabelas em
um grupo de backup. – Tipicamente, as tabelas formam um núcleo
fortemente relacionado entre si.– O processo de backup pode bloquear
apenas as tabelas de um grupo por vez.– Garante a consistência do grupo
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 78
BackupBackup
• Formas de backups– É possível fazer backup de três tipos de
objetos:• Usuários• Tabelas• Base de dados
– Há dois tipos de backups:• Nível físico: cópia dos arquivos de armazenamento
em disco.• Nível lógico: gravando comandos SQL que recriam a
base de dados conforme o estado atual.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 79
Recuperação e backupRecuperação e backup
• Em caso de falhas graves, deve-se utilizar o último backup disponível e aplicar o arquivo de log de transações, desde o backup até o momento da falha.
© Marcelo Bezerra de Alcântara Banco de Dados II - Transação - 80
FechamentoFechamento1. As falhas em um SGBD são categorizadas:
– Falha de Transação, Falha de sistema, Falha de meio de armazenamento
2. Estruturas de armazenamentos:– Armazenamento volátil, Armazenamento não volátil e
Armazenamento estável3. Acesso aos dados
– Input, output, write e read4. Técnicas de recuperação
– Baseadas em Log• modificação imediata do BD• modificação postergada do BD• recuperação de meio de armazenamento
– Baseadas em Shadow Pages