Recuperação e Atomicidade
Hierarquia de Armazenamento – As transações são
programas e, portanto, ocorrem na Memória
Principal, ao passo que o Banco é armazenado em
Disco
Movimento de dados entre Disco e Memória
Principal ocorre “em blocos” e NEM SEMPRE
OCORRE de forma isolada (ocorre em BLOCOS)
nem de forma instantânea
input(X)  Transfere para a memória o bloco
físico no qual reside um item de dado principal X
output(X)  Transfere para o disco o bloco de
buffer no qual reside X e substitui o bloco físico
apropriado
Recuperação e Atomicidade
read(X, xi)  Atribui o valor do item de dado
X para a variável xi
Esta operação é executada da seguinte maneira:
1. Se o bloco no qual X reside não está na
memória principal, então emite-se um “input
(X)”
2. Atribui para xi, o valor de X do bloco do buffer
Recuperação e Atomicidade
write(X, xi)  Atribui o valor da variável xi
para o item de dado X no bloco de Buffer. Esta
operação é executada da seguinte maneira:
1. Se o bloco no qual X reside não está na
memória principal, então emite-se um “input
(X)”
2. Atribui para xi, o valor de X do bloco de buffer
para X
Recuperação e Atomicidade
Obervações:
1. As duas operações podem requerer a
transferência de um bloco do disco para a
memória principal, mas elas não requerem
especificamente a transferência de um bloco da
memória principal para o disco.
2. Um bloco de buffer é gravado no disco ou
porque o gerenciador de buffer precisa de
espaço na memória para outros blocos ou
porque o SGBD precisa refletir a mudança de
X no disco. Dizemos que o SGBD força a saída
do bloco de buffer se ele emite um output(X)
Recuperação e Atomicidade
Obervações:
3. A operação output(X) nãp precisa tomar efeito
imediatamene após o comando write(X, xi) é
executado, uma vez que o bloco no qual X
reside pode conter outros dados aos quais ainda
está se fazendo acesso.
4. Entretanto se o sistema cair entre um
write(X,xi) e o output(X), X não será
atualizado.
Modelo de Transação
Uma transação não deixa de ser um
programa que é executado em memória
principal, porém ela tem algumas
propriedades que mais à frente
Modelo de Transação
EXEMPLO BÁSICO DE UMA TRANSAÇÃO T1:
TRANSFERÊNCIA BANCÁRIA
T1:
read (A,a1)
a1 := a1 - 50;
write (A,a1)
read (B,b1)
b1 := b1 + 50;
write (B,b1)
Modelo de Transação
Cada “write” de uma transação, é uma sinalização
que o correspondente registro do banco de dados
(BD) deverá ser alterado. Esta alteração não ocorre
de forma imediata, por dois motivos: Primeiro,
porque como já falamos, esta passagem para o BD
ocorre em Blocos e, não necessariamente, após cada
write, o Bloco em que o registro reside será
imediatamente escrito no BD. Segundo, como
veremos, com o objetivo de garantir a consistência e
eventual recuperação do BD, os novos valores do
registro a ser alterado é primeiramente escrito num
LOG (residente em disco) e, depois, do LOG para o
Banco de Dados.
ESTRUTURA DO LOG
Estamos considerando o mecanismo das “modificações adiadas”,
quando a atualização efetiva do BD somente PODE começar a
ocorrer após ser emitido um comando COMMIT no LOG.
Um registro de atualização de log descreve uma única operação
(de escrita) com um dado e possui os seguintes campos:
< Ti, Xj, V1 >
Onde:
Ti corresponde ao identificador da transação;
Xj, identificador do item de dado;
V1, valor novo;
Outros registros de log:
< Ti starts > < Ti commits>
< Ti, abort >
Modificação de Banco de Dados Adiada
Vamos supor as transações T0 e T1 com A= 1000, B =2000 e
C= 700 antes do início da execução das transações
T0: read (A,a1)
a1 := a1 - 50;
write (A,a1)
read (B,b1)
b1 := b1 + 50;
write (B,b1)
T1: read (C,a1)
c1 := c1 - 100;
write (C,c1)
LOG “completo” referente às transações T0 e T1
<T0 starts>
<T0, A, 950>
<T0, B, 2050>
<T0 commits>
<T1 starts>
<T1, C, 600>
<T1 commits>
Vamos supor três situações possíveis que poderíamos encontrar
o
LOG após uma falha
<T0 starts>
<T0, A, 950>
<T0, B, 2050>
<T0 commits>
<T1 starts>
<T1, C, 600>
<T1 commits>
(a)
<T0 starts>
<T0, A, 950>
<T0, B, 2050>
<T0 commits>
<T1 starts>
<T1, C, 600>
(b)
<T0 starts>
<T0, A, 950>
(c)
Ações de recuperação a serem tomadas após o sistema voltar:
Caso (a)
LOG ENCONTRADO
<T0 starts>
<T0, A, 950>
<T0, B, 2050>
<T0 commits>
<T1 starts>
<T1, C, 600>
<T1 commits>
Análise: As transações T0 e T1 ocorreram com sucesso, pois seus
registros de LOG foram escritos, haja vista que seus COMMITS estão
presentes. Porém, não pode-se afirmar que os registros do LOG já foram
escritos no BD, pois os sistema pode ter caído exatamente quando esta
ação ainda estava acontecendo (lendo o LOG e escrevendo no BD).
Ações a serem tomadas: Redo T0 e Redo T1
Caso (b)
LOG ENCONTRADO
<T0 starts>
<T0, A, 950>
<T0, B, 2050>
<T0 commits>
<T1 starts>
<T1, C, 600>
Análise: A transação T0 ocorreu com sucesso. A
transação T1 não necessariamente ocorreu até o final,
pois não existe no LOG o “COMMIT” referente a ela.
Ações a serem tomadas: Redo T0 e
Reexecuta T1
Caso (c) LOG ENCONTRADO
<T0 starts>
<T0, A, 950>
Análise: Nem a transação T0, nem a transação T1
ocorreram com sucesso, pois não existem “COMMIT”
referentes a elas no LOG.
Ações a serem tomadas: Reexecuta T0 e
Reexecuta T1
 REEXECUTAR a transação significa
ignorar seu LOG e executar o
programa referente a ela novamente
 REDO numa transação significa ler
novamente os registros de LOG
correspondentes a ela e atualizá-los
no BD. Se isto já ocorreu, não tem
problema, pois como o LOG trabalha
com
valores
absolutos,
esta
atualização pode ser feita várias vezes
com o mesmo efeito
Consideramos até agora a recuperação pelo mecanismo das
“modificações adiadas”, quando a atualização efetiva do BD
somente PODE começar a ocorrer após ser emitido um comando
COMMIT no LOG. Existe um outro mecanismo de recuperação
que se chama mecanismo das “modificações imediatas”, através
do qual a atualização efetiva do BD “PODE” começar antes
comando COMMIT no LOG. Neste caso, a recuperação deve
desfazer os efeitos de uma transação abortada, para a qual não
aparece o registo de COMMIT no LOG. Para que isso seja
possível, o LOG de escrita deve conter o valor antigo e para tanto
o registro do LOG deve possuir os seguintes campos:
< Ti, Xj, V1, V2>
Onde:
Ti corresponde ao identificador da transação;
Xj, identificador do item de dado;
V1, valor novo;
V2, valor velho;
Vamos supor três situações possíveis que poderíamos encontrar
o LOG após uma falha no caso de um mecanismos de
recuperação pelo mecanismo das “modificações imediatas”
(a)
<T0 starts>
<T0, A, 950,1000>
<T0, B, 2050, 2000>
<T0 commits>
<T1 starts>
<T1, C, 600, 700>
<T1 commits>
(b)
(c)
<T0 starts>
<T0 starts>
<T0, A, 950,1000> <T0, A, 950,1000>
<T0, B, 2050, 2000>
<T0 commits>
<T1 starts>
<T1, C, 600, 700>
Ações a serem tomadas para cada uma das três situações:
(a) Redo T0 e Redo T1
(b) Redo T0, Undo T1 e Reexecuta T1
(c) Undo T0 e Reexecuta T0
Propriedades da Transação
Atomicidade
Consistência
Isolamento
Durabilidade
Propriedades da Transação
Atomicidade
Uma transação deve ser uma unidade atômica de trabalho;
ou todas as suas modificações de dados são executadas ou
nenhuma delas é executada.
Propriedades da Transação
Consistência
Quando concluída, uma transação deve deixar todos os dados
em um estado consistente. Em um banco de dados relacional,
todas as regras devem ser aplicadas às modificações da transação
para manter toda a integridade dos dados.
Todas as estruturas de dados internas, tais como índices
em árvore B ou listas duplamente vinculadas, devem estar corretas
ao término da transação.
Propriedades da Transação
Isolamento
Modificações feitas por transações simultâneas devem ser isoladas
das modificações feitas por qualquer outra transação simultânea.
Uma transação reconhece os dados no estado em que estavam ante
de outra transação simultânea tê-los modificado ou reconhece os
dados depois que a segunda transação tiver sido concluída, mas nã
reconhece um estado intermediário. Isso é chamado seriabilidade
porque resulta na capacidade de recarregar os dados iniciais e
reexecutar uma série de transações de modo que os dados obtidos
estejam no mesmo estado em que estavam depois que as transações
originais foram executadas.
Propriedades da Transação
Durabilidade
Depois que uma transação tiver sido concluída, seus efeitos ficam
permanentemente no sistema. As modificações persistem até mesm
no caso de uma queda do sistema.