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