Gerenciamento de Transações

Gerenciamento de Transações
Outros tipos de recuperação:
Além das falhas causadas por transações incorretas, conforme vimos
anteriormente, podem ocorrer outros tipos de falhas, que ocorrem por fatores não
locais. São diferenciados em dois tipos de falhas:
 Falhas de sistema: não danificam fisicamente o banco de dados, mas afetam
todas transações em curso no momento.
 Falhas da mídia: causam danos ao banco de dados ou parte dele, e
prejudicam as transações que fazem acesso a esta parte do banco. Exemplo:
queda da cabeça de gravação.
1
Gerenciamento de Transações
Falhas de sistema:
Primeiramente, iremos abordar as falhas de sistema. Neste caso, o conteúdo da
memória de processamento é perdido, e não se sabe mais em qual ponto de
execução de programas e instruções manuais estamos. Por tal motivo, não é
possível ter conhecimento do ponto em que paramos em cada transação, e
devemos desfazer cada transação, retornando todo o banco de dados à situação
anterior.
Em segundo lugar, vamos compreender melhor qual o processo utilizado pelo
SGBD para gravar os dados no meio físico.
Para cada operação (instrução INSERT, DELETE, UPDATE):
 As alterações de dados aceitas (‘COMMIT’) são guardadas em um ‘buffer’.
 A operação realizada é registrada em um ‘log’ físico, para termos controle das
transações.
2
Gerenciamento de Transações
Obedecendo o intervalo de tempo Δt, o SGBD:
 Grava todas as alterações do ‘buffer’ no meio físico.
 Marca um ponto de verificação (checkpoint) no ‘log’ físico, para separar as
operações já confirmadas daquelas em realização.
Para compreender como é realizada a recuperação de sistema, vamos supor o
seguinte conjunto de transações, compostos cada um pelas operações
respectivas de inserção (I1, I2, etc.) e exclusão (D1, D2, ...):
 Transação 1: I1, I2 e I3
 Transação 2: I4, I5 e I6
 Transação 3: I7, I8 e D1
 Transação 4: I9, I10, I11, I12, I13 e I14
 Transação 5: I15, I16 e D2
3
Gerenciamento de Transações
Para facilitar o entendimento, iremos representar através de uma figura a
evolução de cada transação ao longo do tempo. Vamos definir que:
 Em tc, o sistema realiza uma marcação de ponto de verificação (checkpoint).
 Em tf, ocorre uma falha do sistema.
4
Gerenciamento de Transações
Ao reiniciar o sistema, pela figura, verificamos que:
 A transação T1 teve todas as suas atualizações gravadas no banco de dados
em tc. Portanto, como não houve prejuízo ao sistema físico, nada é necessário
fazer.
 A transação T2 não estava completa em tc, portanto não foi gravada em meio
físico. Mas encerrou antes de tf, e portanto, ao reiniciar, o sistema deverá refazer
a transação T2.
 A transação T3 iniciou após tc, mas terminou antes de tf. Deve ser também
recuperada e gravada no reinício.
 As transações T4 e T5 não terminaram antes de tc, e devem ser desfeitas.
5
Para recuperar os dados da forma descrita, utilizaremos o ‘log’ físico das
transações. Iremos encontrar:
T1: I1
T1:I2
T2: I4
T1: I3
T1: COMMIT
T2:I5
T4: I9
Checkpoint
T2: I6
T2: COMMIT
T4: I10
T3: I7
T4: I11
T3: I8
T4: I12
T5: I15
T3: D1
T3: COMMIT
T4: I13
T5: I16
6
Gerenciamento de Transações
Não encontraremos no ‘log’ T4: I14 e T5: D2 pois não foram executadas (sistema
falha antes). Desta forma, não poderemos completar esta transação
posteriormente
pois
não
teremos
os
dados
necessários.
Para recuperar o sistema, iremos partir do banco de dados existente no meio
físico. Com base no ‘log’ físico, iremos percorrer este arquivo do seu início até o
final. Para cada nova transação, verificaremos:
 Se recebeu um COMMIT antes do ‘checkpoint’ do sistema; neste caso, pode
ser ignorada pois já se encontra no banco. Em nosso exemplo, seria T1, o qual
podemos retirar do ‘log’ antes de sua execução.
 Se não encontramos um COMMIT antes do fim do ‘log’; neste caso, também
removemos do arquivo, pois a transação não se completou e deve ser ignorada.
Em nosso exemplo, T4 e T5.
7
T2: I4
T2:I5
T4: I9
Checkpoint
T2: I6
T2: COMMIT
T4: I10
T3: I7
T4: I11
T3: I8
T4: I12
T5: I15
T3: D1
T3: COMMIT
T4: I13
T5: I16
Desta forma, para recuperar o banco, bastará aplicar sobre o conjunto de dados
existentes em meio físico novamente as transações T2 e T3, na seqüência
indicada acima no ‘log’ após a análise efetuada, a qual remove transações já
completadas antes do ‘checkpoint’ e aquelas não completadas antes da falha do
sistema.
8
Gerenciamento de Transações
Falhas de mídia:
Neste caso, a recuperação é realizada utilizando o recurso de backup do banco.
Faz-se uso da dupla de utilitários do SGBD denominada ‘dump’/’restore’. O
primeiro copia o atual conteúdo do banco de dados físico para outro meio físico
(exemplo: fitas), enquanto o segundo é capaz de reconstituir o primeiro quando
necessário.
Para casos de falhas de mídia, restaura-se o backup e em seguida utiliza-se o
‘log’ de transações para recuperar as transações correntes até o ponto da falha,
utilizando o mesmo processo utilizado para as falhas de sistema.
9
Exercício 5
10
Exercícios
1) Sob o ponto de vista do usuário de um banco de dados, avalie as situações:
No início do dia, o correntista possui um saldo de R$2.000,00. Vai, então, a um caixa
automática e retira R$100,00. No instante seguinte, imprime um extrato de conta corrente e
vê o seguinte demonstrativo:
Saldo anterior: R$2.000,00
Saque do caixa automático: R$100,00
Saldo atual: R$2.000,00
Aguarda mais 20 minutos e solicita outro extrato:
Saldo anterior: R$2.000,00
Saque do caixa automático: R$100,00
Saldo atual: R$1.900,00
A) Para o SGBD o banco de dados estava íntegro entre o 1º. e o 2º. extrato? E sob o
ponto de visão do analista que criou a transação? Explique o por quê nos dois casos.
B) Quais propriedades das transações foram violadas? Por que?
11
Exercícios
Resposta do exercício 1
A) Sob o ponto do SGBD, o banco de dados estava íntegro porque as transações estavam
em processo de execução durante a emissão do 1º. e o 2º. extrato, e ao fim a transação
finalizou sucesso.
No ponto de vista do analista, o banco de dados não estava íntegro porque no momento da
emissão do 1º. extrato, após a realização de operação de saque, não houve alteração do
saldo bancário.
B)
Atomicidade: Violada, porque a transação ocorreu em duas etapas.
Consistência: Violada, porque no momento de emissão do 1º. extrato o saldo bancário não
refletiu a operação de saque realizada anteriormente. No ponto de vista do
usuário, houve inconsistência.
Isolamento: Violada, porque o usuário teve acesso aos dados antes da finalização da
transação.
Durabilidade: Dados registrados corretamente no banco de dados.
12
Exercícios
2) A partir das transações abaixo, analise se há violação das propriedades de
transação.
tc
T1
i1
e1
tf
a1
T2
i2
i3
T3
a2
d1
d2
d3
d4
d5
13
Exercícios
3) Como é implementada a propriedade Durabilidade (D) de uma transação
na prática? O que distingue um conjunto de dados antes e depois de um
COMMIT? Pense nos dispositivos utilizados pelo computador para
efetuar este controle.
 Dados armazenados no buffer aguardando a próxima instrução para liberar
esses dados da memória do computador.
 Executa o comando COMMIT.
 O SGBD copia os dados da memória para o disco rígido para um arquivo de
banco de dados e libera a memória. Estes dados se tornam dados persistentes.
14