Transações em Banco de Dados

Prévia do material em texto

Administração de Banco de Dados
Prof. Luiz Vivacqua
1
Terceira Parte : Transações
Administração de Banco de Dados
Prof. Luiz Vivacqua
2
Transações
�Conceito de transação
�Estado da transação
�Execuções simultâneas
�Seriação
�Testando a seriação
�Facilidade de recuperação
�Definição de transação na SQL
Administração de Banco de Dados
Prof. Luiz Vivacqua
3
Conceito de transação
� Uma transação é uma unidade da execução de programa que acessa e 
possivelmente atualiza vários itens de dados.
� Normalmente iniciada por um programa escrito em uma linguagem de
manipulação de dados (C, C++, Java, Perl, etc)
� Delimitada pelas instruções BEGIN TRANSACTION e COMMIT
� Consiste de todas as operações executadas entre o BEGIN e o COMMIT
� Para garantir a integridade dos dados o SGBD deve manter as 
propriedades ACID:
� Atomicidade
� Consistência
� Isolamento
� Durabilidade
Administração de Banco de Dados
Prof. Luiz Vivacqua
4
Propriedades ACID
� Atomicidade
� Ou todas as operações da transação são refletidas corretamente no banco 
de dados ou nenhuma delas é.
� Consistência
� A execução de uma transação isolada preserva a consistência do banco de 
dados.
Administração de Banco de Dados
Prof. Luiz Vivacqua
5
Propriedades ACID
� Isolamento
� Embora várias transações possam ser executadas simultaneamente, cada 
transação precisa estar desinformada das outras transações que estão 
sendo executadas ao mesmo tempo. Os resultados intermediários da 
transação precisam estar ocultos das outras transações sendo executadas 
simultaneamente. 
� Ou seja, para cada par de transações, Ti e Tj parece para Ti que Tj terminou 
a execução antes que Ti começasse ou Tj iniciou a execução depois que Ti
terminou.
� Em outras palavras, cada transação não está ciente das outras transações 
executando simultaneamente no sistema.
� Durabilidade
� Depois que uma transação for completada com sucesso, as mudanças que 
ela fez no banco de dados persistem, mesmo que ocorram falhas no
sistema.
Administração de Banco de Dados
Prof. Luiz Vivacqua
6
Propriedades ACID
�Transações acessam os dados usando duas 
operações:
� Read(X) – transfere o item de dados X do 
banco de dados (disco) para o buffer da 
transação (memoria)
� Write(X) – transfere o item de dados X do 
buffer da transação para o banco de dados
� OBS: Em muitos SGBS, a operação Write não 
resulta na atualização imediata dos dados no 
disco
Administração de Banco de Dados
Prof. Luiz Vivacqua
7
Propriedades ACID
�Exemplo : Transferência de fundos de R$50 
da conta A para conta B. Saldo inicial de A 
é R$1.000 e de B é R$2.000
� Ti : (1)Read(A)
(2)A:= A – 50
(3)Write(A)
(4)Read(B)
(5)B:= B + 50
(6)Write(B)
Administração de Banco de Dados
Prof. Luiz Vivacqua
8
Propriedades ACID
�Atomicidade
� Se a transação falhar após a etapa 3 e antes da etapa 6, o 
sistema deve garantir que suas atualizações não sejam 
refletidas no banco de dados, ou uma inconsistência irá
resultar.
�Consistência
� A soma de A e B é inalterada pela execução da transação. 
Sem este requisito, o dinheiro poderia ser criado ou 
destruído pela transação. Pode existir uma inconsistência 
temporária durante a execução da transação (A=950 e 
B=2000), porém devido ao requisito de atomicidade este 
estado nunca será visível
Administração de Banco de Dados
Prof. Luiz Vivacqua
9
Propriedades ACID
� Isolamento
� Mesmo estando presente os requisitos de atomicidade e consistência, 
se várias transações estiverem executando simultaneamente suas 
operações podem intercalar de alguma maneira indesejável, 
resultando em um estado inconsistente.
� Por exemplo, Se entre as etapas 3 e 6, outra transação receber 
permissão de acessar o banco de dados parcialmente atualizado, ele 
verá um banco de dados inconsistente (a soma A + B será menor do 
que deveria ser). 
� Isso pode ser trivialmente assegurado executando transações 
serialmente, ou seja, uma após outra. Entretanto, executar múltiplas 
transações simultaneamente oferece vantagens significativas de 
desempenho.
� O requisito de isolamento garante que a execução simultânea de 
transações resulte em um estado do sistema equivalente ao estado 
que poderia ter sido obtido se as transações fossem executadas uma 
de cada vez em alguma ordem. 
Administração de Banco de Dados
Prof. Luiz Vivacqua
10
Propriedades ACID
� Durabilidade
� Quando o usuário é notificado de que a transação está
concluída (ou seja, a transação dos R$ 50 ocorreu), as 
atualizações no banco de dados pela transação 
precisam persistir apesar de falhas (perda de dados na 
memória principal).
� A durabilidade pode ser garantida se:
1. As atualizações executadas pela transação forem gravadas 
em disco antes que a transação termine,
2. As informações sobre as atualizações executadas pela 
transação e gravadas em disco sejam suficientes para 
permitir que o banco de dados reconstrua as atualizações 
quando o sistema for reiniciado após a falha
Administração de Banco de Dados
Prof. Luiz Vivacqua
11
Estado da Transação
� Ativa – O estado inicial; a transação permanece nesse 
estado enquanto está executando
� Parcialmente confirmada – Depois que a instrução final foi 
executada. 
� Falha – Depois da descoberta de que a execução normal 
não pode mais prosseguir
� Abortada – Depois que a transação foi revertida e o banco 
de dados foi restaurado ao seu estado anterior ao início da 
transação. Duas opções após ter sido abortada:
� Reiniciar a transação; pode ser feito apenas se não houver qualquer erro 
lógico interno
� Excluir a transação
� Confirmada – Após o término bem sucedido
Administração de Banco de Dados
Prof. Luiz Vivacqua
12
Estado da Transação
Administração de Banco de Dados
Prof. Luiz Vivacqua
13
Execuções simultâneas
� Várias transações podem ser executadas 
simultaneamente no sistema. As vantagens são:
� Melhor utilização do processador e do disco, levando a um melhor 
throughput de transação: uma transação pode estar usando a CPU 
enquanto outra está lendo ou escrevendo no disco
� Tempo de médio de resposta reduzido para transações: as 
transações curtas não precisam esperar atrás das longas
� Esquemas de controle de concorrência – mecanismos para 
obter isolamento; ou seja, para controlar a interação entre 
as transações concorrentes a fim de evitar que elas 
destruam a consistência do banco de dados 
Administração de Banco de Dados
Prof. Luiz Vivacqua
14
Execuções simultâneas
� Consistência do banco de dados pode ser destruída apesar 
da exatidão de cada transação individual.
� Schedule – Seqüências de instruções que especificam a 
ordem cronológica em que as instruções das transações 
simultâneas são executadas
� Um schedule para um conjunto de transações precisa consistir 
em todas as instruções dessas transações 
� Precisam preservar a ordem em que as instruções aparecem em 
cada transação individual
� Exemplo: Supor duas transações T1 e T2
� T1 transfere R$50 da conta A para a conta B
� T2 transfere 10% do saldo da conta A para a B
� Valores iniciais : A=R$1.000 e B=R$2.000 
Administração de Banco de Dados
Prof. Luiz Vivacqua
15
Execuções simultâneas
� Schedule 1(serial) – T1 executa primeiro que T2
� Valores finais: A=R$855 e B=R$2145
Administração de Banco de Dados
Prof. Luiz Vivacqua
16
Execuções simultâneas
� Schedule 2 (serial) – T2 executa primeiro que T1
� Valores finais: A=R$850 e B=R$2150
Administração de Banco de Dados
Prof. Luiz Vivacqua
17
Execuções simultâneas
� Schedule 3 – schedule não serial equivalente ao schedule 1
� Valores finais: A=R$855 e B=R$2145
Administração de Banco de Dados
Prof. Luiz Vivacqua
18
Execuções simultâneas
� Schedule 4 – schedule não serial
� Valores finais: A=R$950 e B=R$2100
� Estado inconsistente
Administração de Banco de Dados
Prof. Luiz Vivacqua
19
Execuções simultâneas
� Suposição básica – Cada transação preserva a consistência do banco de 
dados. Portanto, a execução serial de um conjunto de transaçõespreserva 
a consistência do banco de dados 
� Ignoramos as operações exceto read e write, e consideramos que as 
transações podem realizar cálculos arbitrários sobre dados em buffers 
locais entre reads e writes. Os schedules simplificados consistem apenas 
em instruções read e write.
Administração de Banco de Dados
Prof. Luiz Vivacqua
20
Seriação
� Instruções Conflitantes
� As instruções consecutivas Ii e Ij das transações Ti e Tj
respectivamente, estão em conflito se e somente se algum item Q é
acessado por Ii e por Ij e pelo menos uma destas instruções for uma 
operação Write.
Ii = read(Q), Ij = write(Q). Estão em conflito
Ii = write(Q), Ij = read(Q). Estão em conflito
Ii = write(Q), Ij = write(Q). Estão em conflito
Ii = read(Q), Ij = read(Q). Ii e Ij não estão em conflito
� Exemplo:
� Instrução Write(A) de T1 conflita com a instrução Read(A) de T2
� Instrução Write(A) de T2 NÃO conflita com a instrução Read(B)
de T1
Administração de Banco de Dados
Prof. Luiz Vivacqua
21
Seriação de Conflito
� Se um schedule S puder ser transformado em um schedule S’ por uma série de 
trocas de instruções não conflitantes, dizemos que S e S’ são equivalentes em 
conflito.
� Write(A) em T2 não conflita com Read(B) em T1
� Continuando a inversão de instruções não conflitantes:
� Troca de Read(B) em T1 com Read(A) em T2; Troca de Write(B) de T1 com 
Write(A) de T2; Troca de Write(B) de T1 com Read(A) de T2
Administração de Banco de Dados
Prof. Luiz Vivacqua
22
Seriação de Conflito
�O resultado final é um schedule serial, ou 
seja, o schedule inicial é equivalente a um 
schedule serial.
� Se o schedule S é serial de conflito então ele 
é um schedule correto.
�Um schedule S é serial de conflito se for 
equivalente em conflito a um schedule 
serial
Administração de Banco de Dados
Prof. Luiz Vivacqua
23
Testando a Seriação de Conflito 
� Algoritmo – grafo de precedência
1. Para cada transação Ti em S criar um vértice Ti
2. Criar uma seta Ti -> Tj se Tj executar um Read(Q) depois que Ti
executar um Write(Q)
3. Criar uma seta Ti -> Tj se Tj executar um Write(Q) depois que Ti
executar um Read(Q)
4. Criar uma seta Ti -> Tj se Tj executar um Write(Q) depois que Ti
executar um Write(Q)
� O schedule será serial de conflito (serializável) se o 
grafo de precedência não contiver ciclos
Administração de Banco de Dados
Prof. Luiz Vivacqua
24
Testando a Seriação de Conflito
Exemplo: 
(a) schedule 1 (b) schedule 2 (c) schedule 4
Administração de Banco de Dados
Prof. Luiz Vivacqua
25
Schedules aceitáveis 
sob o ponto de vista da recuperação de falhas
Administração de Banco de Dados
Prof. Luiz Vivacqua
26
Facilidade de Recuperação
� Se uma transação Ti falhar, o SGBD precisa desfazer o efeito desta transação para 
garantir a atomicidade.
� Também é necessário garantir que qualquer transação Tj que seja dependente de Ti
(Tj lê dados de Ti) também seja abortada.
� Schedule recuperável— Se uma transação Tj lê um item de dados anteriormente escrito 
por uma transação Ti , então a operação commit de Ti aparece antes da operação commit
de Tj.
� O schedule abaixo não é recuperável se T9 for confirmado imediatamente após o Read(A)
� SeT8 abortasse, T9 teria lido (e possivelmente mostrado ao usuário) um estado 
inconsistente. Portanto, o SGBD precisa garantir que schedules sejam recuperáveis
Administração de Banco de Dados
Prof. Luiz Vivacqua
27
Facilidade de Recuperação
� Schedules não em cascata
� Rollback em cascata – Uma única falha de transação leva a uma série de 
rollbacks de transação. Considere o seguinte schedule onde nenhuma das 
transações ainda foi confirmada (portanto, o schedule é recuperável)
� SeT10 falhar, T11 e T12 também precisam ser revertidos
� Pode chegar a desfazer uma quantidade de trabalho significativa
Administração de Banco de Dados
Prof. Luiz Vivacqua
28
Facilidade de Recuperação
� Schedules não em cascata
� Rollbacks em cascata não podem ocorrer; 
� Um schedule não em cascata é aquele em que para cada par de 
transações Ti e Tj tal que Tj leia um item de dados escrito anteriormente 
por Ti, a operação commit de Ti apareça antes da operação read de Tj.
� Todo schedule não em cascata também é recuperável
� É desejável restringir os schedules aos não em cascata
Administração de Banco de Dados
Prof. Luiz Vivacqua
29
Schedule não em cascata: Exemplo
. . .Rollback( )
write(X)
X = X + 10
read(X)
write(X)
X = X – 20
read(X)
T2T1
. . .
write(X)
X = X + 10
read(X)
commit( )
write(X)
X = X – 20
read(X)
T2T1
Escalonamento recuperável
com aborto em cascata
Escalonamento 
recuperável
sem aborto em cascata
Administração de Banco de Dados
Prof. Luiz Vivacqua
30
Definição de Transação na SQL
� O padrão SQL define 4 níveis de isolamento em termos de 
3 fenômenos que devem ser evitados pelo processamento 
concorrente. São eles:
� Leitura de sujeira – T1 pode ler um dado atualizado por uma 
transação T2 concorrente não confirmada. Se T2 abortar então T1 
lerá um valor que não existe e está incorreto.
� Leitura não repetível – T1 relê um dado previamente lido e obtém 
um valor diferente da primeira leitura (dado foi atualizado por 
outra transação).
� Leitura fantasma – T1 lê um conjunto de linhas de uma tabela. T2 
insere uma nova linha na tabela. Se T1 for repetida, ela verá um
fantasma, uma linha que não existia anteriormente.
Administração de Banco de Dados
Prof. Luiz Vivacqua
31
Definição de Transação na SQL
NãoNãoNãoSerializable
SimNãoNãoRepeatable 
Read
SimSimNãoRead 
Commited
SimSimSimRead 
Uncommited
Leitura 
fantasma
Leitura não 
repetível
Leitura de 
sujeira
Nível de
isolamento
*
**
*
**
* - Oracle ** PostGreSQL
Administração de Banco de Dados
Prof. Luiz Vivacqua
32
Verificação de seriação
� Técnicas propostas (em conflito e de visão) são 
difíceis de serem testadas
� exige que se tenha um conjunto fechado de 
transações para fins de verificação
� Na prática
� conjunto de transações executando concorrentemente 
é muito dinâmico!
� novas transações estão sendo constantemente submetidas ao 
SGBD para execução
� logo, a seriação é garantida através de técnicas (ou 
protocolos) de controle de concorrência que não 
precisam testar os escalonamentos