1. Administração de SGBDs

ADMINISTRAÇÃO DE BANCOS DE
DADOS
MÓDULO 12
Índice
1. Administração de SGBDs - Continuação ....................... 3
1.1. Recuperação (Recovery) .............................................. 3
1.1.1. Recuperação de sistema ......................................... 3
1.1.2. Recuperação da mídia ............................................ 4
2
Administração de Banco de Dados - Módulo 12
1. ADMINISTRAÇÃO DE SGBDS - CONTINUAÇÃO
1.1. RECUPERAÇÃO (RECOVERY)
O Recovery (recuperação), segundo DATE (2003:381) ”em um sistema
de banco de dados significa basicamente a recuperação do próprio banco de
dados: ou seja, restaurar o banco de dados a um estado que se sabe ser
correto depois que alguma falha o leva a um estado incorreto ou, pelo
menos, suspeito. E os princípios fundamentais em que se baseia essa
recuperação são muito simples, e podem ser resumidos em uma palavra:
redundância. Em outras palavras, o modo de garantir que o banco de dados
de fato é recuperável é garantir que toda informação que ele contém possa
ser reconstruída a partir de alguma outra informação armazenada de modo
redundante em outro lugar do sistema”.
O sistema deve estar preparado para se recuperar não apenas de falhas
puramente locais, como a ocorrência de uma condição de estouro (overflow)
dentro de uma transação individual, mas também de falhas “globais”, como
uma queda de energia. Por definição, uma falha local só afeta a transação
em que a falha realmente ocorreu. Ao contrário, uma falha global afeta todas
as transações em andamento no instante da falha e, portanto, tem
implicações significativas em todo o sistema. Essas falhas se enquadram em
duas grandes categorias (DATE, 2003):
 Falhas do sistema (por exemplo, queda de energia), que afetam todas
as transações em curso no momento, mas não danificam fisicamente o
banco de dados. Às vezes, uma falha do sistema é chamada de soft
crash;
 Falhas da mídia (por exemplo, queda da cabeça de gravação sobre o
disco), que causam danos ao banco de dados ou a uma parte dele, e
afetam pelo menos todas as transações que, no momento, estão
usando essa parte. Às vezes, uma falha da mídia é chamada de hard
crash.
1.1.1. Recuperação de sistema
O ponto crítico com relação a falhas do sistema é o fato de que o
conteúdo da memória principal é perdido (em particular, os buffers do banco
de dados se perdem). Então, o estado exato de qualquer transação em curso
no momento da falha deixa de ser conhecido; desse modo, tal transação não
poderá nunca mais ser concluída com sucesso e deverá ser desfeita – isto é,
retomada – quando o sistema for reinicializado. Além disso, também pode
ser necessário refazer no momento da reinicialização certas transações
concluídas com êxito antes da queda, mas que não conseguiram ter suas
atualizações transferidas dos buffers do banco de dados para o banco de
dados físico (DATE, 2003).
Segundo DATE, “o sistema mantém um log ou diário em fita ou (mais
comumente) em disco, no qual são registrados detalhes de todas as
3
Administração de Banco de Dados - Módulo 12
operações de atualização – em particular, valores do objeto atualizado antes
e depois de cada atualização, às vezes chamados de imagens antes e depois”
(2003:383).
Surge aqui a questão óbvia: de que maneira o sistema saberá, no
momento da reinicialização, quais transações devem ser desfeitas e quais
devem ser refeitas? A resposta é a seguinte: em certos intervalos
predeterminados – em geral, sempre que algum número preestabelecido de
entradas é gravado no log – o sistema automaticamente marca um
checkpoint (ponto de verificação). Marcar um checkpoint envolve:
a) Gravar fisicamente o conteúdo dos buffers do banco de dados físico;
b) Gravar fisicamente um registro de checkpoint especial no log físico.
O registro de checkpoint fornece uma lista de todas as transações que
estavam em andamento no momento em que o checkpoint foi marcado. O
sistema percorre o log do fim para o início, desfazendo as transações; em
seguida, ele percorre o log de novo para a frente, refazendo as transações.
A restauração do banco de dados a um estado correto refazendo o
trabalho é chamada de recuperação direta. De modo semelhante, a
restauração do banco de dados a um estado correto desfazendo o trabalho às
vezes é chamada de recuperação inversa. Observe que a recuperação direta
refaz as atualizações na ordem em que foram feitas originalmente, enquanto
a recuperação inversa desfaz as atualizações na ordem inversa.
Finalmente, quando toda essa atividade de recuperação for concluída,
então o sistema estará pronto para aceitar um novo trabalho.
1.1.2. Recuperação da mídia
A recuperação de uma falha desse tipo envolve basicamente a recarga ou
a restauração do banco de dados a partir de uma cópia de backup. Em
seguida, usa-se o log – em geral, tanto a parte ativa quanto a parte
arquivada – para refazer todas as transações que se completaram desde que
foi feita a última cópia de backup. Não há necessidade de desfazer as
transações que ainda estavam em curso no momento da falha, pois, por
definição, todas as atualizações dessas transações de qualquer modo foram
“desfeitas” – perdidas (DATE, 2003).
A necessidade de ser capaz de efetuar a recuperação da mídia implica a
necessidade de um utilitário de dump/restore (ou de descarga/recarga). A
parte de dump desse utilitário é usada para criar cópias de backup do banco
de dados por solicitação. Essas cópias podem ser mantidas em fita ou em
outro meio de armazenamento de arquivos; não é necessário que estejam na
mídia de acesso direto. Depois de uma falha de mídia, a parte de restauração
do utilitário é usada para recriar o banco de dados a partir de uma cópia de
backup especificada.
4
Administração de Banco de Dados - Módulo 12