BANCO DE DADOS AULA - 07 Weyler N M Lopes © Especialização em Banco de Dados Página 1 PARTE - I Gerenciamento de Transações Weyler N M Lopes © Especialização em Banco de Dados Página 2 Conceito de Transação Uma transação é uma unidade de execução de programa que acessa e, possivelmente, atualiza vários itens de dados. Silberschatz Transação provê mecanismos para descrever unidade lógicas de processamento em um banco de dados. Navathe Weyler N M Lopes © Especialização em Banco de Dados Página 3 GERENCIAMENTO DE TRANSAÇÕES • Em um sistema operacional de multiprogramação a execução de um programa pode ser intercalada ou simultânea; • A execução que acessa ou modifica o conteúdo de um BD é chamada de transação; • Podemos dizer que o conceito de transação é análogo ao de processos em um sistema operacional; • Uma transação é composta de várias operações; • Todas as operações de uma transação devem ser completadas com sucesso e seus efeitos gravados de forma permanente em um BD; • Uma transação pode ser interrompida, por algum tipo de falha, antes da finalização de todas as operações. Neste caso o estado do BD deverá ser recuperado; Weyler N M Lopes © Especialização em Banco de Dados Página 4 Operações Típicas de uma Transação • Begin_Transaction: marca o início da execução de uma transação; • Read: Especifica uma operação de leitura a algum item do BD; • Write: Especifica uma operação de escrita a algum item do BD; • End_Transaction: Especifica que as operações terminaram e marca o limite final da transação; • Commit_Transaction: Sinaliza o final com sucesso de uma transação de modo que qualquer atualização executada pela transação possa ser efetivada no BD; • Rollback: Sinaliza que a transação terminou sem sucesso e o que foi executado deve ser desfeito; Weyler N M Lopes © Especialização em Banco de Dados Página 5 Operações Adicionais • Undo: similar ao roollback, porém aplicada a uma única transação; • Redo: Especifica que certas operações devem ser refeitas para garantir que todas as operações de uma transação efetivada (commited) foram aplicadas com sucesso ao BD; Weyler N M Lopes © Especialização em Banco de Dados Página 6 Estados de uma Transação READ/WRITE BEGIN TRANSACTION END TRANSACTION COMMIT PARCIALMENTE EFETIVADA ATIVA ABORT EFETIVADA ABORT FALHA TERMINADA Weyler N M Lopes © Especialização em Banco de Dados Página 7 Log do Sistema • Utilizado para permitir recuperação de falhas de transações. Também chamado de Journal; • Registra todas as operações que afetam valores de itens do BD; • É guardado em disco; • Deve sofrer backup periodicamente; • Tipo de entrada no Log: [start_transaction, T] [write_item, T, X, old_value, new_value] [read_item, T, X] [commit, T] [abort, T] Weyler N M Lopes © Especialização em Banco de Dados Página 8 Pontos de Controle • Commit Point Quando todas as operações que acessam o BD foram executadas com sucesso e efeito destas operações no BD já foram gravadas no Log; O commit point está associado a uma transação específica. • Checkpoint É escrito no Log periodicamente quando o sistema grava no disco todas as operações Write de transações efetivadas. Weyler N M Lopes © Especialização em Banco de Dados Página 9 Checkpoint • O gerenciamento de recuperação do SGBD deve decidir em que tipo de intervalo deve ocorrer o checkpoint: Em unidade de tempo; Em número de transações efetivadas após o último checkpoint; • Ações de um checkpoint: Suspender temporariamente a execução de transações; Forçar a escrita de todas as operações de modificação das transações efetivadas do buffer para o disco; Escrever um registro de checkpoint e forçar a escrita do log no disco; retornar à execução de transações. Weyler N M Lopes © Especialização em Banco de Dados Página 10 Propriedades Desejáveis de uma Transação • Atomicidade – Unidade atômica de processamento; • Consistência – A correta execução de uma transação deve levar o BD de um estado consistente para outro estado consistente; • Isolamento – As atualizações não devem ser tornadas visíveis para outras transações até o commit; • Durabilidade – Sempre que o BD for modificado e estas mudanças forem efetivadas, não poderão ser perdidas por alguma falha posterior; Weyler N M Lopes © Especialização em Banco de Dados Página 11 ESCALONAMENTO DE TRANSAÇÕES • É também denominado de história de transações; • Diz respeito à ordem de execução das operações de várias transações executadas concorrentemente; • Um escalonamento S de n transações T1, T2, ..., Tn, é um ordenamento de operações dessas transações, sujeito à restrição de que para cada transação Ti em S, as operações de Ti em S devem aparecer na mesma ordem que ocorrem em Ti; Operações conflitantes São operações que pertencem a diferentes transações, acessam o mesmo item e pelo menos uma das duas operações é um write_item; Weyler N M Lopes © Especialização em Banco de Dados Página 12 Escalonamento Recuperável • É o escalonamento onde nenhuma transação T em S é efetivada até que todas as transações T’, que escrevam um item a ser lido por T, tenham sido efetivadas; Rollback em cascata • Uma transação não efetivada tem que ser rolled back porque lê um item de uma transação que falhou; • Toda transação que no escalonamento que apenas lêem itens por transações efetivadas evitam rollback em cascata. Esta estratégia á mais restritiva, porém pode ser eficiente quando falhas são constantes; Weyler N M Lopes © Especialização em Banco de Dados Página 13 Escalonamento Estrito • Ocorre quando nenhuma transação pode ler ou escrever itens que a última transação que o escreveu não tenha sido efetivada ou abortada. Escalonamento sem Intercalação • Ocorre quando todas as operações de uma transação T1 são seguidas por toda as operações de T2, ou vice-versa; Weyler N M Lopes © Especialização em Banco de Dados Página 14 TEORIA DA SERIALIZABILIDADE • Tenta determinar quais escalonamentos são corretos e quais não são; • Engloba a aplicação de técnicas que permita apenas escalonamento corretos. Escalonamento Serial • Ocorre quando as operações de cada transação são executadas consecutivamente, sem operações intercaladas com a de outras transação; • Este tipo de transação não gera conflito. Weyler N M Lopes © Especialização em Banco de Dados Página 15 Escalonamento Não-serial • As operações de uma transação são executadas intercaladas com as operações de outras transações; Escalonamento Serializável • É equivalente a algum escalonamento serial com as mesmas n transações; • Escalonamentos com resultados equivalentes produzem o mesmo resultado final da BD Weyler N M Lopes © Especialização em Banco de Dados Página 16 TESTE DE CONFLITO DE SERIALIZABILIDADE • Para testar se há conflito de serializabilidade em um determinado escalonamento, utiliza-se uma técnica baseada em um grafo de precedência, construído a partir da seqüência de operações do escalonamento; • Grafo de precedência é um grafo dirigido G=(N,E) que consiste de um conjunto de nós N={T1,T2,...,Tn} e um conjunto de lados dirigidos E={e1,e2,...,em} • Algoritmo : 1. Para cada transação participando de um escalonamento S, criar um nó rotulado de Ti no grafo de precedência; 2. Para cada caso em S onde uma transação Tj executa um read_item(x) após um write_item(x) executada por outra transação Ti, crie um lado (Ti -> Tj) no grafo de precedência; Weyler N M Lopes © Especialização em Banco de Dados Página 17 • Algoritmo : 3. Para cada caso em S onde uma transação Tj executa um write_item(x) após um read_item(x) executada por outra transação Ti, crie um lado (Ti -> Tj) no grafo de precedência; 4. Para cada caso em S onde uma transação Tj executa um write_item(x) após um write_item(x) executada por outra transação Ti, crie um lado (Ti -> Tj) no grafo de precedência; 5. Um escalonamento é serializável se e somente se o grafo de precedência não tem ciclos. Weyler N M Lopes © Especialização em Banco de Dados Página 18 Exemplos de Escalonamentos T1 T2 read(x) x = x + 5; write(x) read(y) y = y + x; write(y) read(x) x = x * 3; write(x) T 1 Weyler N M Lopes © T 2 Especialização em Banco de Dados SERIALIZÁVEL Página 19 T1 T2 read(x) x = x * 3; write(x) read(x) x = x + 5; write(x) read(y) y = y + x; write(y) T 1 Weyler N M Lopes © T 2 Especialização em Banco de Dados SERIALIZÁVEL Página 20 T1 T2 read(x) x = x + 5; read(x) x = x * 3; write(x) read(y) write(x) y = y + x; write(y) T 1 Weyler N M Lopes © T 2 NÃO SERIALIZÁVEL Especialização em Banco de Dados Página 21 EXERCÍCIOS 1) Todos os termos relacionados a seguir estão associados a gerenciamento de transações. O que significa cada um deles? Log; Rollback; Commit_Transaction; Checkpoint; ACID. 2) Baseado no seguinte esquema de execução de transações, responda os itens subseqüentes: (2,0) T1 T2 T3 read(y) read(x) x = x + 5; read(x) x = x * 3; write(x) read(y) write(x) y = y + x; write(y) a) b) c) d) O que você entende por escalonamento serializável? Construa um grafo de precedência para o escalonamento descrito acima. Este esquema representa um escalonamento serializável? Justifique. Elabore um escalonamento serializável para o esquema. Weyler N M Lopes © Especialização em Banco de Dados Página 22 NÍVEIS DE CONSISTÊNCIA Serializável — default Read repetitivo — somente registros que sofreram efetivação podem ser lidos, leituras repetidas do mesmo registro devem retornar o mesmo valor. Read com efetivação — somente registros que sofreram efetivação podem ser lidos, mas leituras sucessivas de registro podem retornar valores diferentes (mas que sofreram efetivação). Read sem efetivação — até mesmo registros que não sofreram efetivação podem ser lidos. Graus de consistência mais baixos são úteis para reunir informações aproximadas sobre o banco de dados, p. ex., dados estatísticos para o otimizador de consultas. Weyler N M Lopes © Especialização em Banco de Dados Página 23 CONCORRÊNCIA E SERIALIZABILIDADE •Testar a serializabilidade de um escalonamento após ele ter sido executado é um pouco tardio! •Meta – desenvolver protocolos de controle de concorrência que assegurem a serializabilidade . Eles geralmente não irão examinar o grafo de precedência assim que ele tiver sido criado; em vez disso, o protocolo irá impor uma disciplina que evite escalonamentos nãoserializáveis. •Testes de serializabilidade ajudam a compreender porque um protocolo de controle de concorrência está correto. Weyler N M Lopes © Especialização em Banco de Dados Página 24 PARTE - II Controle de Concorrência Weyler N M Lopes © Especialização em Banco de Dados Página 25 DEFINIÇÃO Concorrência é a propriedade de uma transação poder ser executada em paralelo com outras transações. Weyler N M Lopes © Especialização em Banco de Dados Página 26 Justificativa de uso Com a execução de várias transações ao mesmo tempo , o processador pode ser compartilhado entre estas transações, melhorando a eficiência global do computador, uma vez que uma quantidade maior de tarefas é executada em paralelo. Justificativa de Controle É necessário que o sistema monitore a interação entre transações concorrentes, de modo a evitar que a consistência do BD seja destruída. Weyler N M Lopes © Especialização em Banco de Dados Página 27 Arquitetura do SGBD para o Controle TRANSAÇÕES GERENCIADOR DE TRANSAÇÕES ESCALONADOR GERENCIADOR DE DADOS GERENCIADOR DE RECUPERAÇÃO GERENCIADOR CACHE Weyler N M Lopes © Especialização em Banco de Dados BD Página 28 TÉCNICAS DE BLOQUEIO LOCK Variável associada a um item de dados no BD que representa o status deste item com relação a possíveis operações a serem aplicadas sobre ele. Lock Binário Assume dois valores que representam dois estados: locked(1) ou unlocked(0). Um lock distinto é associado a cada item do BD – referenciado como lock(x) para o item x Weyler N M Lopes © Especialização em Banco de Dados Página 29 Lock Binário (continuação) Operações incluídas nas transações: lock_item unlock_item Estas operações são implementadas como operações indivisíveis; Um gerenciador é mantido pelo SGBD para gerenciar e controlar o acesso a locks; Para cada lock efetuado é mantido um registro da forma:<nome-item,LOCK>; Estes registros são mantidos em uma tabela de lock; Weyler N M Lopes © Especialização em Banco de Dados Página 30 Lock Binário (continuação) Regras de gerenciamento: Uma transação T tem que executar uma operação lock_item(x) antes de qualquer read_item ou write_item executado por T; Uma transação T tem que executar a operação unlock_item(x) após todo read/write completados em T; Uma transação não pode executar uma operação lock_item(x) se já tem um lock sobre x; Uma operação T não pode executar um unlock_item(x) a menos que tenha um lock sobre x; Apenas uma transação pode ter um lock sobre um dado item; Weyler N M Lopes © Especialização em Banco de Dados Página 31 Lock de Modo Múltiplo Neste tipo de lock, há três operações indivisíveis: read_lock(x) – lock compartilhado; write_lock(x) – lock exlusivo; unlock(x). O registro de lock, neste caso, assume o seguinte formato: <nome-item, LOCK, numero-leituras> Weyler N M Lopes © Especialização em Banco de Dados Página 32 Lock de Modo Múltiplo (continuação) Regras de gerenciamento: Uma transação T tem que executar uma operação read_lock(x) ou write_lock(x) antes de qualquer read_item(x) executado por T; Uma transação T tem que executar uma operação write_lock(x) antes de qualquer write_item(x) em T; Uma transação T tem que executar uma operação unlock(x) após todas as operações read_item(x) ou write_item(x) completadas em T; Uma transação T não executará um read_lock(x) se já tem um lock compartilhado (read_lock) ou um lock_exclusivo (write_lock) em x; Weyler N M Lopes © Especialização em Banco de Dados Página 33 Lock de Modo Múltiplo (continuação) Incremento de LOCK: Uma transação T após ter um read_lock(x) e sendo a única que detém x, pode posteriormente executar um write_lock(x); Decremento de LOCK: Após ter um lock exclusivo sobre um item x, uma transação T pode decrementar o lock, executando um read_lock(x). Weyler N M Lopes © Especialização em Banco de Dados Página 34 TÉCNICAS DE BLOQUEIO (continuação) Locks binários ou múltiplos não garantem a serializabilidade de escalonamentos nos quais transações participam. É necessário um protocolo adicional que contempla o posicionamento dos locks e unlocks em cada transação; Weyler N M Lopes © Especialização em Banco de Dados Página 35 Bloqueios Exclusivos Se uma transação T contiver um bloqueio exclusivo em algum item, então nenhuma transação distinta T’ pode fazer bloqueio daquele objeto até que T libere seu bloqueio; Bloqueios exclusivos seguem o seguinte protocolo: Qualquer transação que pretenda atualizar um registro R, primeiro terá que acessar aquele registro e bloqueá-lo exclusivamente. Se o bloqueio não puder ser realizado, a transação entra em estado de espera e apenas continuará a ser executada quando o registro se tornar disponível e o bloqueio puder ser concedido; O sistema terá que garantir que uma transação forçada a esperar por causa deste protocolo, eventualmente sairá deste estado de espera. Assim, não sofrerá livelock. Weyler N M Lopes © Especialização em Banco de Dados Página 36 Bloqueios Exclusivos (continuação) Par evitar a possibilidade de perda de atualizações, nenhuma transação poderá ter acesso aos dados de uma transação não efetuada; Bloqueios Compartilhados Se uma transação T mantiver um bloqueio compartilhado em algum item, então uma transação T’ distinta também pode fazer um bloqueio compartilhado sobre aquele item. Porém, nenhuma transação T’ distinta pode fazer um bloqueio exclusivo sobre aquele item até que todos os bloqueios compartilhados sobre o item tenham sido liberados; Weyler N M Lopes © Especialização em Banco de Dados Página 37 Bloqueios de Duas Fases Ocorre quando todas as transações obedecem às seguintes regras: 1. Antes de operar sobre qualquer item, primeiro a transação adquire bloqueio sobre este item; 2. Após liberar o bloqueio, a transação não adquire mais bloqueios; Todas as transações intercaladas destas transações são serializáveis; Fases do bloqueio: Crescente: quando bloqueios são feitos; Encolhimento: quando bloqueios são liberados. Weyler N M Lopes © Especialização em Banco de Dados Página 38 Bloqueios de Duas Fases (continuação) Se o decréscimo do lock for permitido, ele tem que ser feito na fase de encolhimento. Uma transação tem que manter um lock sobre x mesmo que não precise dele, se tiver que exercer um lock sobre outro item y. Este é um fato que limita o acesso concorrente; Variações do protocolo: • Básico: protocolo apresentado anteriormente; • Conservador ou Estático: bloqueia todos os itens que irão acessar, antes de iniciar a execução da transação; • Estrito: Não libera os locks até o commit ou abort. Weyler N M Lopes © Especialização em Banco de Dados Página 39 Deadlock É uma situação em que uma ou mais transações estão em estado simultâneo de espera, cada uma aguardando que a outra libere um bloqueio para poder prosseguir. Principais métodos para solucionar o impasse: Protocolos de prevenção de deadlock: Conservador: Se algum dos itens não pode ser bloqueado, nenhum será bloqueado; Ordenado: Tentar por uma ordenação em todos os itens. Os locks só podem ocorrer segundo esta ordem; Weyler N M Lopes © Especialização em Banco de Dados Página 40 Deadlock (continuação) Técnicas baseada em timestamp: Identificador único é assinalado em cada transação; Estes identificadores são ordenados segundo a ordem que as transações começam; Tem a não utilização de bloqueios como principal vantagem, o que impossibilita a existência de dealocks; Weyler N M Lopes © Especialização em Banco de Dados Página 41 Deadlock (continuação) Técnicas baseada em timestamp: (continuação) O protocolo associado a esta técnica é o seguinte: Quando uma transação solicita um bloqueio de registro que já está bloqueado por outra transação, então um dos dois procedimentos é seguido: 1) wait-die: se a transação que solicitou o bloqueio é a mais antiga, pode aguardar. Se for a mais nova, sofre rollback e começa mais tarde com o mesmo timestamp; 2) Wound-wait: Se a transação for a mais nova, pode aguardar. Se for a mais antiga, interrompe a nova que sofre rollback e mais tarde recomeça com o mesmo timestamp. Weyler N M Lopes © Especialização em Banco de Dados Página 42 Deadlock (continuação) Técnicas baseada detecção e recuperação: É baseada na verificação da existência de deadlock. Possui basicamente duas políticas de verificação: 1) Identifica imediatamente sempre a existência de uma solicitação de bloqueio que cause espera. Tal política, apesar de resolver imediatamente o impasse, acarreta em um overhead; 2) Toma por base um intervalo de tempo para verificar a existência de deadlock. Reduz o overhead, porém, deadlocks podem ser detectados de forma tardia. Weyler N M Lopes © Especialização em Banco de Dados Página 43 Deadlock (continuação) Condições ideais para evitar deadlocks: 1) Pequena interferência entre as transações; 2) Transações curtas; 3) Locks de poucos itens; 4) Carga de transação leve. Weyler N M Lopes © Especialização em Banco de Dados Página 44 Deadlock (continuação) A quebra de deadlock consiste na escolha de uma das transações para forçá-la a um rollback. As opções são: 1) A que foi iniciada mais cedo; 2) A que tiver realizado o menor número de bloqueios; 3) A que tiver feito menor número de atualizações; Políticas baseadas em que de deadlock agem sobre situações opostas às pretendidas pelas políticas de prevenção. Weyler N M Lopes © Especialização em Banco de Dados Página 45 Livelock Ocorre quando uma determinada transação não pode prosseguir por um período indefinido de tempo, enquanto outras transações continuam normalmente; Livelocks têm sua origem em esquemas injustos de espera; Podem ser evitados através das seguintes políticas: First-come-first-serve Incremento de prioridade com o tempo Weyler N M Lopes © Especialização em Banco de Dados Página 46 Starvation Problema similar ao livelock. Ocorre quando a mesma transação é “vítima” várias vezes para ser abortada, e por conseguinte, nunca encerrando a sua execução; Os protocolos wait-die e wound-wait, apresentados anteriormente, evitam este tipo de problema. Weyler N M Lopes © Especialização em Banco de Dados Página 47 Conclusão O ambiente de um BD se difere de outros ambientes no que concerne a problemas de bloqueios devido a vários fatores. Dentre eles, podemos destacar: Conjunto de objetos bloqueáveis não é só muito grande, como também mudam de forma rápida; Objetos bloqueáveis são tipicamente endereçáveis pelo conteúdo; Escopo preciso do bloqueio para determinada transação, normalmente é determinado com muito rapidez ; Weyler N M Lopes © Especialização em Banco de Dados Página 48 EXERCÍCIO Há algumas outras técnicas de controle de concorrência que não foram apresentadas com detalhes. Escolha uma destas técnicas e escreva um pequeno artigo descrevendo suas características. Sugestão: Dentre as técnicas, observe as não orientadas a bloqueio (técnicas baseadas em timestamp) Weyler N M Lopes © Especialização em Banco de Dados Página 49 PARTE - III Controle de Acesso (estudo prático em PostgreSQL) Weyler N M Lopes © Especialização em Banco de Dados Página 50