sistema de recuperação. Esse sistema tem a responsabilidade de azer com que,a responsabilidade de azer com que, após a ocorrência de alguma alha, o banco de dados volte a um estado de após a ocorrência de alguma alha, o banco de dados volte a um estado de consistência. Nesta aula, estudaremos justamente os
consistência. Nesta aula, estudaremos justamente os sistemas de recuperação.sistemas de recuperação.
Sistema de recuperação
Sistema de recuperação
5.1 Classicação de falhas 5.1 Classicação de falhas
Existem vários tipos de alhas que podem ocorrer em um sistema, cada um Existem vários tipos de alhas que podem ocorrer em um sistema, cada um deles precisa ser tratado de uma maneira dierente. O tipo mais simples de alha deles precisa ser tratado de uma maneira dierente. O tipo mais simples de alha é o que não resulta na perda de inormações no sistema. Falhas que causam é o que não resulta na perda de inormações no sistema. Falhas que causam perda de inormações são mais diíceis de tratar (SILBERSCHATZ; KORTH; perda de inormações são mais diíceis de tratar (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).
SUDARSHAN, 2006).
Elmasri e Navathe (2005) descrevem alguns tipos principais de alhas, Elmasri e Navathe (2005) descrevem alguns tipos principais de alhas, subdividindo-os em categorias: alha de transações, alha de sistema e alha de subdividindo-os em categorias: alha de transações, alha de sistema e alha de discos (ou mídia). Vejamos em que consiste cada uma dessas alhas.
discos (ou mídia). Vejamos em que consiste cada uma dessas alhas.
Falha do computador Falha do computador •
• : um erro de: um erro de hardware hardware ,, sotware sotware ou rede ocorre eou rede ocorre e
em um sistema de computador durante a execução de uma transação, em um sistema de computador durante a execução de uma transação, por exemplo, uma alha na memória principal.
por exemplo, uma alha na memória principal.
Um erro de transação ou sistema Um erro de transação ou sistema •
• :: alguma operação da transação podealguma operação da transação pode
ocasionar uma alha, como um estouro de inteiro, ou uma divisão por ocasionar uma alha, como um estouro de inteiro, ou uma divisão por zero. Falhas de transação também podem oco
zero. Falhas de transação também podem ocorrer por conta de valoresrrer por conta de valores errados de um parâmetro ou por erros na lógica de programação. errados de um parâmetro ou por erros na lógica de programação. Além disso, o próprio usuário pode interromper a operação antes do Além disso, o próprio usuário pode interromper a operação antes do término da transação.
término da transação.
Erros locais ou condições de exceção detectadas para a transação Erros locais ou condições de exceção detectadas para a transação •
• ::
durante a execução de uma transação, podem ocorrer determinadas durante a execução de uma transação, podem ocorrer determinadas condições que necessitem o cancelamento da transação, por exemplo, condições que necessitem o cancelamento da transação, por exemplo, os dados para a transação não estarem disponíveis.
os dados para a transação não estarem disponíveis.
Imposição do controle de concorrência Imposição do controle de concorrência •
• : o método de controle de concor-: o método de controle de concor-
rência pode optar por abortar
rência pode optar por abortar uma transação para ser reiniciada poste-uma transação para ser reiniciada poste- riormente caso ela viole a ordem de serialização ou porque diversas riormente caso ela viole a ordem de serialização ou porque diversas transações estão em estado de
transações estão em estado de deadlock deadlock .. Falha de disco
Falha de disco •
• :: alguns blocos de disco podem perder seus dados poralguns blocos de disco podem perder seus dados por
causa de mau uncionamento de uma leitura ou
causa de mau uncionamento de uma leitura ou gravação.gravação.
Problemas ísicos ou catástroes Problemas ísicos ou catástroes •
• :: reerem-se a uma lista sem m dereerem-se a uma lista sem m de
problemas que incluem alha de energia, urto, sabotagem, sobre problemas que incluem alha de energia, urto, sabotagem, sobre gravação de dados, etc.
5.2 Recuperação
Para determinar como um sistema deve se recuperar de alhas, precisamos identicar os modos de alha dos dispositivos usados para armazenamento de dados. Em seguida, temos de considerar como esses modos de alhas aetam o conteúdo do banco de dados. Podemos, então, propor algoritmos para garantir a coerência do banco de dados e a atomicidade das transações eetuadas apesar das alhas (SILBERSCHATZ; KORTH; SUDARSHAN, 2006). Essas ações podem ser tomadas durante a execução das transações para garantir que haja
inormações sucientes para recuperar alhar (caso elas ocorram) ou podem ser tomadas após a ocorrência de alhas, para recuperar os dados e retornar o
banco de dados a um estado consistente.
Segundo Elmasri e Navathe (2005), a recuperação de transações que alharam signica, em geral, que o banco de dados será restaurado para o estado de consistência mais recente, exatamente antes do momento da alha. Para isso, o sistema deverá manter inormações sobre as alterações que oram aplicadas no banco de dados pelas várias transações executadas. Geralmente, essas inorma- ções são armazenadas em arquivos chamados de log (histórico) do sistema.
Uma estratégia genérica para recuperação de alhas pode ser baseada em dois pontos principais, que são mencionados a seguir.
a) Se houver um dano extenso em uma grande porção do banco de dados, por conta de uma alha catastróca, tal com uma alha de disco, o método de recuperação restaura uma cópia anterior do banco de dados que estava guardada em um arquivo de armazenamento (o que chamamos de backup ) e o reconstrói em um estado mais atual, reapli-
cando ou reazendo as operações das transações armazenadas no log
até o instante da alha.
b) Quando o banco de dados não or danicado sicamente, mas se tornar inconsistente por causa de uma alha não catastróca, a estratégia é
reverter quaisquer mudanças que causaram a inconsistência, desa-
zendo algumas operações. Além disso, será necessário reazer algumas operações para restaurar o estado consistente do banco de dados.
5.2.1 Recuperação baseada em log
A estrutura mais utilizada para registrar as modicações do banco de dados é o log. O log é uma seqüência de registros de atividades de atualização no
banco de dados. Um registro de log de atualização descreve uma escrita no
banco de dados, ou seja, armazena dados sucientes para que a transação seja reeita, caso necessário. Em geral, uma entrada de log, conorme Silberschatz,
Korth e Sudarshan (2006) contém os seguintes campos:
identifcador de transação
• : é o identicador exclusivo da transação que
identifcador do item de dados
• : identicador único do item de dados que
oi escrito, normalmente, o local no disco em que o item oi armazenado;
valor antigo
• : valor do item de dados antes da escrita;
novo valor
• : valor que o item de dados passa a ter após a escrita.
Observe que a capacidade de desazer uma alteração no banco de dados se apóia no armazenamento do valor antigo dos dados envolvidos em uma escrita. Assim, em caso de alhas, eles podem ser restaurados. Sempre que uma transação realiza uma escrita, é essencial que o registro de log seja eito antes
que o banco de dados seja modicado. Após o registro em log da transação, a
modicação do banco de dados pode ser liberada.
Um ponto importante para que a técnica de recuperação baseada em log
seja realmente útil é que os registros de log devem estar armazenados em local
estável. Imagine uma situação em que os arquivos de log estão armazenados no
mesmo disco que o sistema de banco de dados e que ocorra uma alha no disco. Existe a possibilidade de que o arquivo de log seja danicado em conjunto do banco de dados. Dessa maneira, sugere-se que o log seja armazenado em um
local externo ao sistema de banco de dados.
Outro aspecto a ser observado é que cada transação eetuada em um banco de dados resulta em uma entrada no registro de log. Dessa orma, esse arquivo
pode se tornar muito grande em um pequeno intervalo de tempo. Portanto devemos pensar, também, em como manipular esses arquivos com eciência.
5.2.2 Recuperação baseada na atualização adiada
A idéia contida nas técnicas de atualização adiada é postergar quais- quer atualizações no banco de dados real até que a transação complete sua execução com sucesso e alcance o seu ponto de eetivação. Durante a execução de uma transação, as atualizações são gravadas em log. Quando
a transação alcançar o seu ponto de eetivação, há a gravação do log em um
meio estável de armazenamento, então as atualizações podem ser eetuadas sobre o banco de dados.
Se uma transação alhar antes de alcançar o seu ponto de eetivação, não será necessário desazer nenhuma alteração, pois a transação não aetou o banco de dados no disco. Assim, segundo Elmasri e Navathe (2005), podemos denir um protocolo de atualização adiada em:
a) uma transação que não pode mudar o banco de dados em disco até que atinja o seu ponto de eetivação;
b) uma transação que não alcança o seu ponto de eetivação até que todas as suas operações de atualização sejam registradas no log, e até que o
Outra observação interessante é que alguns tipos de transações não aetam o banco de dados. Operações como geração e impressão de relatórios são caracterizadas por ações de leitura apenas. Mesmo assim pode ser inviável que elas sejam retornadas ao usuário “meio completas”, pois um relatório baseado em dados incorretos pode ser usado como instrumento para tomada de decisão, o que acarretaria um problema não para o sistema em si, mas para o negócio (o que pode ser ainda pior!).
Um sistema de recuperação pode atuar nesse contexto inormando ao usuário que um determinado relatório oi gerado com erro. Outra ação seria garantir que esse relatório somente seja gerado depois que a transação alcance o seu ponto de eetivação. Outra opção é compor comandos que gerem relatórios e os mantenham como tareas em lote, sendo executadas apenas depois que a
transação alcançar seu ponto de eetivação. Caso a transação alhe, as tareas em lote são canceladas.
5.2.3 Recuperação baseada na atualização imediata
As técnicas de modicação imediata permitem que as modicações no banco de dados sejam enviadas ao sistema quando a transação ainda está em estado ativo. As modicações de dados escritas pelas transações ativas
são chamadas de modifcações não confrmadas (SILBERSCHATZ; KORTH;
SUDARSHAN, 2006). Caso ocorra alguma alha durante uma transação, o sistema precisará utilizar o campo valor antigodo registro de log para restaurar
os itens de dados modicados para que retornem aos valores que tinham antes da transação ser iniciada.
Para que esse método uncione corretamente, é necessário que cada operação de atualização (mesmo antes da eetivação da transação) seja execu- tada somente depois que um registro de log dessa operação seja gravado em
meio de armazenamento estável. Dessa maneira, as atualizações no banco de dados podem ser eitas imediatamente, mas com a possibilidade de recupe- ração das alterações eitas.
Segundo Elmasri e Navathe (2005), teoricamente, podemos identicar dois tipos principais de algoritmos de atualização imediata, que citamos a seguir.
Algoritmo de recuperação
• UNDO/NO-REDO (desaz e não reaz):
caracterizado pelo ato de que é garantido que todas as atualizações (escritas) de uma transação sejam registradas no banco de dados em disco antes da transação se eetivar. Dessa orma, em caso de alha
na transação, não será necessário reazer as atualizações, apenas desazer as que já executaram.
Algoritmo
• UNDO/REDO (desaz-reaz): se é permitido que a transação
seja eetivada antes que todas as mudanças sejam escritas no banco de dados, temos uma técnica do tipo UNDO/REDO.
5.2.4 Pontos de vericação (checkponts)
Quando ocorre uma alha do sistema, é preciso consultar o arquivo de
log para determinar quais transações precisam ser reeitas e quais transações
precisam ser deseitas. Em muitos casos, é preciso percorrer todo o arquivo de log para obter essa inormação. Conorme Silberschatz, Korth e Sudarshan
(2006), essa técnica apresenta duas difculdades:
o processo de busca é demorado;
•
a maioria das transações que precisam ser reeitas já enviaram suas
•
atualizações para o banco de dados. Embora reazê-las não cause dano algum, a recuperação leva mais tempo.
Para reduzir esse tipo de sobrecarga, são utilizados os pontos de vericação. Durante a execução, o sistema mantém o log, usando uma das duas técnicas
apresentadas (atualizações adiadas ou imediatas). Além da utilização de logs,
o sistema implementa pontos de verifcação, por meio das seguintes ações:
a) enviar para armazenamento estável todos os registros atualmente resi- dentes na memória principal;
b) enviar para o disco todos os blocos modicados;
c) enviar para o armazenamento estável um registro de log <checkpoint >.
Essa técnica permite melhorar o esquema de recuperação das outras já citadas e unciona da seguinte maneira: quando houver uma alha, o esquema de recuperação examina o log no sentido do último registro para o primeiro,
para identicar a transação T que oi iniciada após o último ponto de vericação. Dessa maneira, apenas precisarão ser deseitas, ou reeitas as transações que iniciaram após o começo da transação T , além de T , é claro. Assim diminui o
custo da recuperação do banco de dados.
5.2.5 Recuperação com transações concorrentes
Segundo Elmasri e Navathe (2005), independente do número de transações simultâneas, um sistema de banco de dados tem um único buer de disco e um
O esquema de recuperação depende muito do mecanismo de controle de concorrência. Para reverter uma transação que alhou, temos de desazer as atualizações realizadas pela transação. Supondo que uma transação T deve ser revertida e que atualizou um item de dados X, ela deve ser revertida e o valor do item de dados modicado deve ser restaurado de acordo com o seu valor antigo registrada em log. Vamos supor, ainda, que outra transação S atualizou o valor
do item de dados X antes de T ser reeita. Nesse caso, a atualização eita pela transação S será perdida.
Para resolver essa situação, podemos perceber que, enquanto a transação T é revertida, atualizando um item de dados X, nenhuma outra transação poderá atualizar o mesmo item de dados até que T seja revertida ou eetivada. Esse requisito pode ser garantido utilizando uma técnica de bloqueio em duas ases com bloqueios exclusivos enquanto a transação é completada.
5.2.6 Recuperação em sistemas de bancos de dados múltiplos
Até o momento consideramos apenas a recuperação de alhas em um único sistema de banco de dados. Porém não é rara a execução de transações em bancos de dados distribuídos (conceitos que veremos com mais detalhes na próxima aula). Nesse cenário, uma única transação, chamada de transação multibanco de dados, pode acessar diversos bancos de dados, que podem estar armazenados em dierentes sítios e ainda sob a gerência de dierentes SGBDs (ELMASRI; NAVATHE, 2005).
Para manter a atomicidade de uma transação em um multibanco de dados é necessário ter um mecanismo de recuperação em dois níveis: um gerenciador de recuperação global, ou coordenador, responsável por manter as inormações exigidas para recuperação; e os gerenciadores de recuperação locais, respon- sáveis pelos registros de log.
A recuperação em múltiplos bancos de dados é baseada em duas ases.
a) Fase 1: quando todos os bancos de dados participantes sinalizarem
ao coordenador que a sua parte na transação multibanco de dados oi concluída, ele envia uma mensagem de preparação para eetivação a m de inormar cada participante, que deverá registrar as alterações em
log e enviar ao coordenador uma resposta de OK ou não-OK (no caso
de ocorrer alguma alha).
b) Fase 2: se todos os bancos de dados participantes responderem OK
(inclusive o coordenador), o coordenador enviará um sinal de “eetivar” para cada participante, que gravará as alterações em log.
A idéia é que todos os bancos de dados eetivem a transação, ou nenhum deles o aça. No caso de haver alguma alha, será possível recuperar a consis- tência a partir de um estado no qual a transação possa ser eetivada ou revertida.
Uma alha ocorrida durante a ase 1 requer que a transação seja revertida (deseita), enquanto que uma alha durante a ase 2 requer que a transação seja revertida e, em seguida, eetivada (deseita e reeita novamente).
5.2.7 Sistema de backup
Certamente você já ouviu alar em backupe, provavelmente, a denição mais
encontrada para esse termo é cópia de segurança. Muitos administradores de
bancos de dados eetuam essa tarea no dia-a-dia, sempre azendo uma cópia do banco de dados para que, em caso de alguma alha (sobretudo as catastrócas). Silberschatz, Korth e Sudarshan (2006) sugerem que, para obtermos alta disponibilidade, podemos realizar o processamento das transações em um local chamado de sítio primário e manter um sítio secundário, no qual todos os dados
do sítio primário são replicados. O sítio secundário também é chamado de
backup remoto.
O backup precisa ser sincronizado com o sítio primário enquanto as transa-
ções são processadas nele. Essa sincronização pode ser obtida enviando todos os registros de log para o backup. Esse sítio de backup deve estar sicamente
distante do sítio primário para evitar que, caso ocorra algum desastre, o backup
não seja danicado junto com o primário.
Quando o sítio primário alhar, o sistema debackupremoto irá utilizar a última
cópia de segurança eetuada e aplicar sobre essa cópia todos os registros de log
das transações eetuadas desde então. Assim teremos, ao nal desse processa- mento o banco de dados no seu estado atualizado e consistente. Três desafos
são undamentais para o bom uncionamento de um sistema de backup.
Detecção de falha
• : o sistema de backup deve ter um mecanismo para
detectar uma alha no sistema primário. Um caso clássico é uma alha na comunicação que pode azer com que o sistema de backup “ache” que o sistema primário alhou e inicie as rotinas de recuperação. Uma solução para esse caso é manter duas conexões distintas utilizando tecnologias die- rentes para aumentar a confabilidade do sistema de detecção de alhas. Transerência de controle
• : quando o sistema primário alha, o sistema de
backup assume o papel e passa a processar as transações. Ao retornar
à operação, o antigo sistema primário pode tanto permanecer como
backup, quanto voltar a ser o primário. Essa decisão pode depender,
por exemplo, da tecnologia de comunicação que dá acesso ao sistema primário original e ao sistema de backup;
Tempo de recuperação
• : quando os arquivos de logse tornam muito grandes
pode ser necessário um longo tempo para processá-los e deixar o banco de dados em um estado consistente e atual. Um sistema de backup que leva
aplicação. Uma solução para esse problema é o processamento periódico do arquivo de log, para que, quando houver a necessidade, seja gasto
menos tempo para iniciar a operação do sistema de backup.
A utilização de sistemas de recuperação é muito importante, já que as inor- mações correspondem a um dos bens mais preciosos das instituições. A perda dessa inormação pode trazer um prejuízo muito grande em termos de tempo, de reazer o trabalho anterior e também nanceiro.
Nesta aula, estudamos algumas metodologias para recuperação de alhas
em sistemas de bancos de dados, como a utilização de logs, que armazenam