© Marcelo Bezerra de AlcântaraBanco de Dados II - Transação - 1 Disciplina Banco de Dados II Recuperação de falha Msc, Marcelo Bezerra de Alcântara [email protected]

© 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

[email protected]


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.


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


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


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


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


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


SumárioSumário





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



• 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



• 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


SumárioSumário





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.


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.


SumárioSumário





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.



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



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



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



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


SumárioSumário





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.


• 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


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


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


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


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


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


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



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



• 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


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


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)


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



• 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



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



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


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.



– 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.



• 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



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



(a): desfazer a transação T0.

(b): refazer T0 e desfazer T1.

(c): refazer T0 e T1.


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!


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>


RespostaResposta

Realizar a operação de REDO de T1



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


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>


RespostaResposta

Realizar a operação de REDO de T1 e UNDO de T0



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


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>


RespostaResposta

A = Não pode saberB = Não pode saberC = Não pode saber



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


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>


RespostaResposta

A = 50B = 50C = Não pode saber


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



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



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



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).



Desconsiderar T1

Refazer T2 e T3.

Desfazer T4.

TcTf

T1

T2

T3

T4

checkpoint system failure



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


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>


RespostaResposta

Não faz nada



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


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>


RespostaResposta

Realizar o UNDO de T0


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


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


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


SumárioSumário





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.


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)


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


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


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


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



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


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>


RespostaResposta

Não realiza nada


SumárioSumário





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.


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



• 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



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



• 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


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.


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.


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

Documents

© Marcelo Bezerra de AlcântaraBanco de Dados II - Transação - 1 Disciplina Banco de Dados II Recuperação de falha Msc, Marcelo Bezerra de Alcântara [email protected]