ÍNDICE

RESUMO ................................................................................................................................... 1

2. Introdução......................................................................................................................... 3

3. Controle de Concorrência................................................................................................. 4

4. Recuperação de Falhas ..................................................................................................... 6

Log ......................................................................................................................................... 9

Tipos de Registro do Log ....................................................................................................... 9

Recuperação ......................................................................................................................... 10

Checkpoint Fuzzy................................................................................................................. 10

5. Conclusão ....................................................................................................................... 12

6. Bibliografia..................................................................................................................... 13

RESUMO

O presente trabalho tem como objectivo abordar o tema referente a Recuperação de falhas em
transações concorrentes, abordar os mecanismos utilizados para correção ou reversão de estados
em transações, falaremos sobre logs que são registos de operações, o cache que aborda sobre os
métodos de armazenamento, assim como os algoritmos de recuperação de falhas.

Palavras-chave: Transações, Concorrência, Recuperação, Falhas, Algoritmo, Escalonamento.

2. INTRODUÇÃO

Qualquer banco de dados que seja utilizado por mais de um usuário, terá que administrar o
controle de concorrência entre as informações que estão sendo acessadas pelos usuários.
Controle de concorrência é quando, em um banco de dados, usuários distintos tentam acessar a
mesma informação e então é feito um controle entre essas transações. E para a solução deste
problema existem diversas técnicas de controle de concorrência que são utilizadas como forma
de assegurar o isolamento das transações executadas ao mesmo tempo.

Técnicas de controle de concorrência são utilizadas para garantir que transações concorrentes
sejam executadas adequadamente.

Muitos problemas podem ocorrer quando transações concorrentes são executadas sem
controle

 problema da perda de atualização;

 problema da atualização temporária (leitura suja);
 problema da agregação incorreta;
 problema da leitura não-repetitiva.

3
3. CONTROLE DE CONCORRÊNCIA

Técnicas de controle de concorrência são utilizadas para garantir que transacções concorrentes
sejam executadas adequadamente. Muitos problemas podem ocorrer quando transacções
concorrentes são executadas sem controle, a saber:

 Problema da perda de actualização: Ocorre quando duas transacções que acessam os

mesmos itens do banco de dados possuem operações entrelaçadas, de modo que torne
incorreto o valor de algum item do banco de dados.;

Figure 1: Problema da perda de atualalização

O valor final do item X em T2 estará incorreto, porque T2 lê o valor de X antes que T1 o

altere no banco de dados e, portanto, o valor atualizado resultante de T1 será perdido.

 Problema da atualização temporária (leitura suja): Ocorre quando uma transacção

actualiza um item do banco de dados e, por algum motivo, a transacção falha; no caso, o
item actualizado é acessado por uma outra transacção antes do seu valor ser retornado ao
valor anterior.

4
 Figure 2: problema da actualização temporária

A transacção T1 falha e o sistema deve alterar o valor do item X para o seu valor anterior;
porém, T2 já leu o valor temporário "incorrecto" do item X.

 Problema da agregação incorrecta: Se uma transacção estiver calculando uma função

de agregação em um número de itens, enquanto outras transacções estiverem
actualizando alguns desses itens, a função agregada pode considerar alguns itens antes
que eles sejam actualizados e outros depois que tenham sido actualizados.

Figure 3: Problema da agregação incorrecta

5
  Problema da leitura não-repetitiva: Ocorre quando uma transação T lê um item duas
vezes e o item é alterado por uma outra transação T' entre as duas leituras de T. Portanto,
T recebe diferentes valores para suas duas leituras do mesmo item.

Figure 4: Problema da leitura não-repetitiva:

4. RECUPERAÇÃO DE FALHAS

A seguir iremos ver quais os efeitos das falhas de transacção durante a execução concorrente.

Se uma transacção Ti falhar, por qualquer razão, precisamos desfazer seus efeitos para garantir a
propriedade de atomicidade da transacção. Em um sistema que permite execução concorrente,
também é necessário assegurar que qualquer transacção Tj que seja dependente de Ti também
seja abortada. Para alcançar essa segurança, precisamos colocar restrições no tipo de escalas
permitidas no sistema.

Escalas de Execuções Recuperáveis

A figura a seguir mostra uma escala na qual T9 e uma transacção que executa apenas uma
instrução: read(A). Supondo que o sistema permita que T9 seja efectivada imediatamente após
executar a instrução read(A). Assim, T9 é efectivada antes que T8 o seja. Agora supondo que T8
falhe antes da efectivação. Como T9 leu o valor do item de dados A escrito por T8, temos de

6
abortar T9 para assegurar a atomicidade da transacção. Porém, T9 já foi efectivada e não poderá
ser abortada. Assim, temos uma situação em que é impossível se recuperar correctamente da
falha de T8.

Figure 5: Escala 11

A escala 11, com a efectivação acontecendo imediatamente após a instrução read(A), é um

exemplo de escala não-recuperável que, portanto, não deveria ser permitida. A maioria dos
sistemas de banco de dados exige que todas as escalas sejam recuperáveis. Uma escala
recuperável é aquela na qual, para cada par de transacções Ti e Tj, tal que Tj leia itens de dados
previamente escritos por Ti, a operação de efectivação de Ti apareca antes da operação de
efectivação de Tj.

Escalas sem Cascata

Mesmo em uma escala recuperável, para o sistema recuperar-se correctamente da falha de uma
transacção Ti, pode ser que seja necessário desfazer diversas transacções. Tais situações ocorrem
se as transacções leram dados escritos por Ti, como ilustração pode se considerar a a escala
parcial da figura que se segue. A transacção T10 escreve um valor para A que é lido pela
transacção T11. A transacção T11 escreve um valor para A que é lido pela transacção T12.
Supondo que, nesse momento, T10 falhe. T10 deverá ser desfeita. Como T11 é dependente de T10,
T11 deverá ser desfeita. Como T12 é dependente de T11, T12 deverá ser desfeita. Esse fenómeno,
no qual a falha de uma única transacção conduz a uma série de revisões de transacção, é
chamado de retorno em cascata (cascading rollback).

7
 Figure 6: Escala em cascata

O retorno em cascata é indesejável, já que leva a desfazer uma quantia significativa de

trabalho. É conveniente restringir as escalas àquelas nas quais os retornos os retornos em cascata
não possam acontecer. Tais escalas são chamadas de escalas sem cascata. Uma escala sem
cascata é aquela na qual para cada par de transacções Ti e Tj tal que Tj leia um item de dados
previamente escrito por Ti, a operação de efectivação de Ti apareça antes da leitura de Tj. É fácil
verificar que toda escala sem cascata também é recuperável.

O SGBD não deve permitir que algumas operações de uma transação T sejam aplicadas ao
banco de dados enquanto outras operações de T não sejam. Isso pode acontecer quando uma
transação falha após executar algumas de suas operações (e não todas).

Propósito

 Restaurar o BD ao seu último estado consistente antes de uma falha

 Preservar as propriedades ACID: Atomicidade e Durabilidade

Os tipos de falhas possíveis

 Falha do computador (falha do sistema): Um erro de hardware, software ou rede no

sistema de computação durante a execução da transacção;
 Erro de transacção ou de sistema: Alguma operação na transacção pode fazer que esta
falhe, como um estouro de inteiro ou divisão por zero. Uma falha de transacção também
pode ocorrer devido a valores de parâmetro erróneos ou a um erro lógico de
programação. Além disso o usuário pode interromper a transacção durante sua execução;

8
  Imposição do controle de concorrência: O método de controle de concorrência pode
decidir abortar uma transacção porque ela viola a serialização, ou pode abortar uma ou
mais transacções para resolver um estado de deadlock entre várias transacções. As
transacções abortadas devido a violações de serialização ou deadlock em geral são
reiniciados automaticamente em outro momento;
 Falha no disco: alguns blocos de disco podem perder seus dados devido a um defeito de
leitura, gravação ou por causa de uma falha da cabeça de leitura/gravação. Isso pode
acontecer durante uma operação de leitura ou gravação da transacao;
 Problemas físicos e catástrofes: isso se refere a uma lista sem fim de problemas que
incluem falha de energia ou de ar condicionado, incêndio, roubo, sabotagem entre outros.

Para os 3 primeiros tipos de falhas, o sistema deve manter informações suficientes para se
recuperar da falha.

Log
Mantém o registro sequencial das operações de transacção que afectam itens do BD estes
dados podem ser necessários para desfazer ações de uma transação “abortada”, recuperar o
sistema de falhas e Auditoria. O Log é mantido em disco afectado apenas pelas falhas em disco
ou catastróficas, recomenda-se um disco separado

Quando ocorre uma falha:

 As transacções inicializadas, mas que não gravaram seus registos de commit no log,
devem ser desfeitas;
 As transacções que gravaram seus registos de commit no log podem ter que ser refeitas a
partir dos registros do log.

Tipos de Registro do Log

 [start_transaction,T]: Indica que a transacção T iniciou.
 [write_item,T,X,valor_antigo,novo_valor]: Indica que a transacção T mudou o valor
do item do banco de dados X de valor_antigo para valor_novo.
 [read_item,T,X]: Indica que a transacção T leu o valor do item de banco de dados X.
 [commit,T]: Indica que a transacção T foi concluída com sucesso, e afirma que seu
efeito pode ser confirmado (registado permanentemente) no banco de dados.

9
  [abort,T]: Indica que a transacção T foi abortada.
 [checkpoint]: indica gravação de todos os dados modificados do buffer em disco

Cada transação T tem um identificador único gerado automaticamente pelo sistema.

No processo de recuperação de falhas relativa a uma transação T, usam-se as operações:

 UNDO (desfazer): desfaz a transação, ou seja, percorre o log de forma retroativa,

retornando todos os itens alterados por uma operação write de T aos seus valores
antigos.
 REDO (refazer): refaz a transação, ou seja, percorre o log para frente, ajustando
todos os itens alterados por uma operação write de T para seus valores novos.

Campos para recuperação (UNDO e REDO):

BFIM (Before Image): estado antes da alteração

 usado para UNDO

AFIM (After Image): estado depois da alteração

 usado para REDO

Recuperação

Checkpoint Fuzzy
Usa [begin_checkpoint] no início do processo e libera para outros processos.

Usa [end_checkpoint] no final

 Não válido enquanto não alcança este ponto

10
Algoritmo básico:

 Varre o log de trás para frente

-Cria listas de transacções commit e rollback

-Desfaz alterações de transações ativas

 Varre o log de frente para trás

-Refaz alterações de transações confirmadas

-Ignora transações abortadas

 Restaura transações ativas?

Operações devem ser idempotentes (execuções múltiplas têm o mesmo efeito de uma
execução única)

11
5. CONCLUSÃO

12
6. BIBLIOGRAFIA

Elmasri, Ramez; Navathe, Shamkant B. Sistemas de Bancos de Dados. Addison-Wesley, 4a

edição em português. 2005.

Elmasri, Ramez; Navathe, Shamkant B. Sistemas de Banco de Dados. Pearson, 6a edição. 2010.

Ramakrishnan, Raghu; Gehrke, Johannes Database Management Systems. McGraw-Hill, 3rd

edition. 2003.

Ramakrishnan, Raghu; Gehrke, Johannes. Database Management Systems. McGraw-Hill, 3rd

edition (companion slides). 2003.

13