Processamento de Transações - Inf

Arquitetura de Banco de Dados
Processamento de Transações
Carolina Nogueira
Marcelo Eduardo Cardoso
Rodrigo Dlugokenski
Vítor De Araújo
Bancos de dados
Single-users versus Multiusers
classificação baseada no número de usuários
que pode utilizar o sistema de forma concorrente
●
processamento intercalado X processamento paralelo
Transações
Unidade lógica de processamento de banco de
dados; ou
● Conjunto de operações que devem ser
executadas como uma operação atômica
●
Transações concorrentes
São aquelas que podem interferir entre si
Exemplo clássico:
Duas transações que incrementam um
valor
X=0
T1
read(X)
X++
write(X)
T2
read(X)
X++
write(X)
X = 1 ou X = 2 ?
Problemas de concorrência
●
Problema da atualização perdida
Problemas de concorrência
●
Problema da atualização temporária (leitura suja)
Problemas de concorrência
●
Síntese incorreta
Problemas de concorrência
●
Problema de não repetição de leitura
Exemplo: Reserva de lugares num vôo
read(L): assentos livres
escolhe_lugar(): pessoa escolhe assento
read(L): lê novamente assentos livres
Outros Problemas
Falha de hardware;
● Falha no sistema ou na transação;
● Erros locais ou condições de exceção
detectadas pela transação
● Controle de execução da concorrência
(deadlocks, violação da serialização)
● Falha de disco
● Problemas físicos e catástrofes
●
Propriedades Desejáveis
Transações idealmente devem possuir as
propriedades ACID:
●
●
●
●
Atomicidade
Consistência
Isolamento
Durabilidade
Atomicidade
Cada transação é executada como se fosse
uma operação atômica, ou seja, indivisível
● Ela é executada até o final, ou não é
executada (não tem efeito)
● Característica garantida pelo subsistema de
recuperação de transações
●
Consistência
Transação leva de um estado consistente a
outro
● É de responsabilidade do programador ou do
módulo de restrições de integridade
●
Isolamento
Transações não interferem entre si
● Responsabilidade do subsistema de controle
de concorrência
● Proteção contra os problemas por níveis:
● Nível 0: atualizações temporárias;
● Nível 1: atualizações perdidas;
● Nível 2: nível 0 nível 1;
● Nível 3: nível 2 + leitura consecutivas
●
Durabilidade
Se transação foi concretizada (committed),
será preservada no banco de dados
● Se o SGBD confirmou a concretização, não
poderá desfazer a transação depois
● Responsável: subsistema de recuperação de
transações
●
Histórico de Transações
Histórico de N transações:
Ordenamento das operações dessas
transações
● Operações de uma mesma transação
preservam sua ordem relativa
● Operações de diferentes transações podem
ser intercaladas
●
Histórico de Transações
Conflito de operações ocorre se as operações:
1. pertencem a transações distintas; e
2. acessam o mesmo item X; e
3. pelo menos uma das operações é write(X)
Histórico Completo
Contém todas as operações de todas as
transações
● Inclusive commit/abort como última operação
de cada transação;
● Preserva ordem relativa das operações de
cada transação;
● Se duas operações conflitam, uma
certamente ocorre antes da outra
●
Histórico de Transações
Dinâmico, pois novas operações são
constantemente incluídas no histórico pelo
SGBD
● Histórico nem sempre contém transações
completas
●
●
Projeção completa: subconjunto do
histórico que é completo, ou seja, operações
de commit/abort de cada transação está
presente
Escalonamento de Transações
Recuperabilidade através do histórico do
escalonador:
Pode haver dependências entre as
transações
● Se uma falhar, pode ser necessário desfazer
outras
●
Escalonamento Recuperável
Se garantidamente, depois que ocorre o
commit de uma transação, nunca é necessário
desfazê-la
●
T não salva permanentemente as alterações
até que aconteça o commit de todas as
transações T' que irão escrever itens que T lê
●
Escalonamento Recuperável
Uma transação T lê de T' se:
T lê item X depois que T' escreve item X; e
● cada T' não pode ter abortado antes de T
ler de T'; e
● não há escritas depois de T' escrever e
antes de T ler
●
Pode ocorrer de uma falha cancelar outras
transações (cascata de rollback)
Escalonamento sem cascatas
T só lê itens de T' depois que T' salvou
permanentemente as alterações (commit)
Escalonamento Estrito
Nenhuma transação pode ler nem escrever
item X até que a última transação que escreveu
item X tenha efetuado uma alteração
permanete (commit)
Serializabilidade
Escalonamento serial:
uma transação de cada vez
● Escalonamento não-serial:
transações intercaladas
● Escalonamento serializável:
equivalente a um escalonamento serial
●
Equivalência de Conflitos
Diz-se que dois históricos S e S' possuem
equivalência de conflitos se a ordem de
quaisquer duas operações conflitantes é a
mesma em ambos históricos
●
S é conflito-serializável se possui equivalência
de conflitos a um histórico serial S'
●
Teste de serialização de conflitos
1. Crie um grafo com um nó para cada
transação
2. Adicione uma seta de Ti para Tj se:
a. Ti escreve X, e depois Tj lê X; OU
b. Ti lê X, e depois Tj escreve X; OU
c. Ti escreve X, e depois Tj escreve X.
3. Histórico é serializável se e somente se o
grafo não tiver ciclo.
Serializabilidade
Normalmente, não se testa serializabilidade
Muito caro primeiro gerar escalonamento,
armazenar no histórico e depois descartar
se não for serializável
● Em vez disso, garante-se que o
escalonamento é serializável por construção
Ex. locks (garantem que certas operações
serão postergadas até um momento seguro)
●
Equivalência de Visualização
Ordem relativa de leituras e escritas do
mesmo item são preservadas
● Menos restritivo do que equivalência de
conflitos
● Permite reordenar "escritas cegas"
●
Outros tipos de equivalência
●
Dependentes da aplicação
Ex. débito/crédito: somar um valor (positivo
ou negativo) a um registro é comutativo
Dúvidas?
Arquitetura de Banco de Dados
Processamento de Transações
Carolina Nogueira
Marcelo Eduardo Cardoso
Rodrigo Dlugokenski
Vítor De Araújo