Transações e Controle de Concorrência

Conceitos Básicos Sistema de Banco de Dados Sistemas Monousuários e Multiusuários Transações Início e Fim de uma Transação Operações em uma Transação Estados de Execução de uma Transação Propriedades de uma Transação (ACID) Controle de Concorrência Escalonadores (Schedules) Planos Seriais Planos Não Seriais Serialidade dos Planos (Planos Serializáveis) Fenômenos em Transações Concorrentes Níveis de Isolamento das Transações Nível de Isolamento x Fenômeno em Transações Bloqueios (Lock) Tipos de Bloqueio (Lock) Deadlock Granularidade Escalonamento de Bloqueio (Lock) Sumário

1 Conceitos Básicos

O conceito de concorrência em banco de dados trata dos métodos necessários para que mais de um agente (usuário ou programa) possa acessar um conjunto de dados compartilhados entre eles. Este controle também deve garantir transparência e independência, para que outros agentes não precisem saber ou interagir entre si para resolver o acesso aos recursos em questão. O estudo da concorrência é feito sobre o conceito de transações em banco de dados.

2. Sistema de Banco de Dados

2. Sistema de Banco de Dados

2. Sistema de Banco de Dados

3. Sistemas Monousuários e Multiusuários

4. Transações

Transação é uma unidade lógica, que consiste de uma série de operações executadas, onde o sistema de banco de dados precisa manter certas propriedades para garantir o sucesso sem perda de informações lógicas. Definições: 1. Transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos dados (C. J. Date); 2. É uma unidade lógica de processamento no BD (Navathe); 3. É uma unidade de execução do programa que acessa e possivelmente atualiza vários itens de dados (Silberschatz). Pode ser um programa inteiro, uma parte dele ou somente um comando. Deve-se especificar explicitamente o início da transação e o seu fim. Todas as operações entre estas cláusulas são consideradas parte de uma transação.

5. Início e Fim de uma Transação

Uma transação inicia-se, basicamente, com uma instrução BEGIN e termina com um COMMIT ou ROLLBACK. COMMIT Indica a conclusão de uma transação bem-sucedida (parcialmente efetivada), informando ao gerenciador de transações do SGBD que uma unidade lógica de trabalho foi concluída com sucesso. Com essa ação, o banco retoma o seu estado consistente e todas as atualizações feitas por essa unidade já podem se tornar permanentes (efetivada). ROLLBACK Indica o cancelamento ou conclusão de uma transação mal sucedida (em falha). Ela informa ao gerenciador a ocorrência de uma falha. Nesse momento o banco pode estar inconsistente, portanto, todas as atualizações realizadas pela transação devem ser desfeitas (abortada).

6. Operações em uma Transação

Temos as seguintes operações dentro de um banco de dados: 1. BEGIN TRANSACTION: Início da execução de uma transação; 2. END TRANSACTION: Fim da execução de uma transação; 3. READ ou WRITE: Operações de leitura ou escrita de um dado em um banco de dados; 4. COMMIT: Efetiva a mudança feita por uma transação que foi executada com sucesso; 5. ROLLBACK: Aborta a transação e as mudanças realizadas devem ser desfeitas.

7. Estados de Execução de uma Transação

8. Propriedades de uma Transação (ACID)

1. Atomicidade: Uma transação é uma unidade atômica de processamento que deve ser executada integralmente ou totalmente desfeita; 2. Consistência: A execução de uma transação deve levar o banco de dados de um estado consistente a outro, garantindo a integridade dos dados (unicidade de chaves e integridade referencial); 3. Isolamento: A execução de uma transação não pode ser afetada por outras que estão sendo executadas concorrentemente. Para isso suas atualizações não devem ser efetivadas até que se tenha uma confirmação (COMMIT); 4. Durabilidade: Os efeitos de uma transação confirmada não podem ser desfeitos, a menos que outra transação modifique tais dados. Deve também prevenir falhas durante a efetivação de uma transação.

9. Controle de Concorrência

Para garantir as propriedades de uma transação (ACID) o banco de dados deve utilizar algum tipo de controle de concorrência. Sem este controle diversos problemas podem ocorrer quando transações são executadas concorrentemente.

10. Escalonadores (Schedules)

Escalonadores representam a ordem cronológica em que as instruções são executadas no sistema. O objetivo é definir uma seqüência de operações em um conjunto de transações concorrentes, preservando a ordem das operações em cada uma das transações. Temos 2 modelos: 1. Planos Seriais: As operações de cada transação são executadas de maneira

consecutiva sem nenhuma intercalação nas operações. 2. Planos Não Seriais: As operações de um conjunto de transações são executadas de

maneira intercalada. Planos seriais nunca permitem que um BD fique em um estado inconsistente. Infelizmente desperdiçam tempo de CPU e são inaceitáveis na prática.

11. Planos Seriais

11. Planos Seriais (Execução)

12. Planos Não Seriais

13. Serialidade dos Planos (Planos Serializáveis)

O objetivo da capacidade de serialização é de encontrar escalonadores não seriais que permitam uma execução concorrente, sem haver interferência de uma transação na outra e, conseqüentemente, sem gerar um estado inconsistente. Um plano (escalonador) é dito serializável se ele produzir os mesmos resultados que uma execução em série. Em sistemas com transações simultâneas, é importante garantir a SERIALIZAÇÃO. Pode existir mais de um escalonamento serial equivalente. Escalonamentos não seriais devem ser proibidos pelo Escalonador.

13. Serialidade dos Planos (Planos Serializáveis)

13. Serialidade dos Planos (Planos Serializáveis - Execução)

14. Fenômenos em Transações Concorrentes

1. Dirty Read (Leitura suja) A transação lê dados não efetivados (uncommitted) escritos por uma transação concorrente.

14. Fenômenos em Transações Concorrentes

2. Nonrepeatable Read (Leitura que não pode ser repetida) A transação lê uma segunda vez os dados e descobre que eles foram modificados por outra transação que os efetivou (commit) entre o intervalo das duas leituras.

14. Fenômenos em Transações Concorrentes

3. Phantom Read (Leitura fantasma) A transação executa uma segunda vez a consulta e descobre que o conjunto de linhas que satisfaz a condição agora é diferente, devido a uma outra transação efetivada recentemente. Ela difere da “Nonrepeatable Read” no seguinte aspecto: os dados lidos não mudaram. Mais dados, agora, satisfazem os critérios de procura.

15. Níveis de Isolamento das Transações

O isolamento de transações é mais uma alternativa de funcionamento do controle de concorrência para auxiliar na difícil tarefa de manter a integridade dos dados em momentos de múltiplas transações. Existem quatro níveis possíveis de isolamento:

1. Serializable; 2. Repeatable Read; 3. Read Commited; 4. Read Uncommited.

Cada banco de dados define sua operação interna de acordo com seu projeto e, por vezes, os níveis SERIALIZABLE e READ COMMITED são os mais usados.

15. Níveis de Isolamento das Transações (Serializable)

Este é considerado o nível mais alto de isolamento de uma transação. A transação opera em um ambiente que “aparenta” não terem outros usuários modificando dados na base. Qualquer consulta que for executada retornará sempre os mesmos dados, durante o tempo de vida da transação. É o modo mais restritivo, ou seja, o que resulta em menor concorrência. - A transação fica completamente isolada; - Comparta-se como se tivesse executada serialmente.

15. Níveis de Isolamento das Transações (Serializable)

15. Níveis de Isolamento das Transações (Repeatable Read)

O objetivo do “Repeatable Read” é prover um nível de isolamento que forneça consistência, respostas corretas e previna a perda de modificações. Ele bloqueia os dados até o final da transação, garantido que os valores dos dados acessados não serão modificados por outras transações, mas permite a inserção de novas tuplas nas tabelas, podendo originar "linhas fantasma". - No banco, todas as leituras serão consistentes.

15. Níveis de Isolamento das Transações (Read Commited)

A transação só lerá dados que já sofreram “commit” no banco de dados. Não ocorrerão “Dirty Reads”. Podem ocorrer “Nonrepeatable Reads” (releituras da mesma linha podem retornar uma resposta diferente dentro da mesma transação) e “Phantom Reads” (novas inserções e alterações em linhas que sofreram “commit” se tornam visíveis para uma consulta quando antes não eram, na mesma transação). - São visualizadas apenas linhas já commitadas por outras transações;

15. Níveis de Isolamento das Transações (Read Commited)

15. Níveis de Isolamento das Transações (Read Uncommited)

Este nível de isolamento permite “Dirty Reads”. Alguns bancos de dados sequer permitem o uso deste tipo de isolamento. O objetivo neste caso é ignorar o uso de bloqueios. É o modo menos restritivo que resulta em maior concorrência, mas que deve ser usado somente quando não se tem nenhum compromisso com a consistência do resultado. - Nível mais baixo de isolamento; - Também conhecido como “leitura suja”; - Permite a leitura de linhas que não sofreram “commit”; - Utilizado para melhorar performance.

16. Nível de Isolamento x Fenômeno em Transações

17. Bloqueios (Lock)

Quando diversas transações são executadas de forma concorrente em um banco de dados, a propriedade do isolamento pode não ser preservada.

Além da definição do nível de isolamento das transações, existe outra técnica que auxilia no controle da interação entre transações concorrentes. Este mecanismo é chamado de bloqueio.

O uso de bloqueio garante a serialização, obrigando que o acesso aos itens de dados seja feito de maneira mutuamente exclusiva.

Enquanto uma transação modifica um ítem de dado, nenhuma outra transação pode modificá-lo.

17. Bloqueios (Lock)

O gerenciador de lock é a parte do SGBD responsável pelo gerenciamento dos bloqueios concedidos às transações. Para cumprir sua função ele mantém uma tabela de locks onde armazena todos os locks associados aos objetos de dados. Com ela o gerenciador é capaz de manipular as requisições de lock das transações, concedendo locks sobre objetos que não representem ameaça de conflito ou colocando as requisições na fila até que possam ser atendidas. A implementação dos comandos de lock e unlock deve garantir que eles sejam operações atômicas. Para tal o acesso à tabela de lock deve utilizar algum mecanismo de sincronização (ex: semáforos).

18. Tipos de Bloqueio (Lock)

1. Compartilhado: Se uma transação (T) obteve um bloqueio compartilhado (S) sobre o item de dado (Q), então T pode ler, mas não escrever Q; 2. Exclusivo: Se uma transação (T) obteve um bloqueio exclusivo (X) do item de dado (Q), então T pode tanto ler quanto escrever Q.

18. Tipos de Bloqueio (Lock)

O modo compartilhado é compatível apenas com o modo compartilhado, não com o modo exclusivo.

Se existe um bloqueio compartilhado, outra transação também pode requisitar bloqueio compartilhado para o mesmo item de dado, mas não pode solicitar bloqueio exclusivo para este item.

18. Tipos de Bloqueio (Lock)

18. Tipos de Bloqueio (Lock)

19. Deadlock

Caso especial de lock, onde duas transações entram em conflito mútuo e dependem da intervenção do SGBD em realizar rollback de uma das duas transações para resolver o problema. Passos: 1. A transação T1 faz um bloqueio do recurso A do banco; 2. A transação T2 faz um bloqueio do recurso B; 3. T1 precisa fazer bloqueio do recurso B (pendente por T2). Ocorre o lock; 4. T2 tenta bloquear o recurso A (pendente por T1). Ocorre o conflito mútuo.

19. Deadlock

20. Granularidade

Granularidade está relacionado diretamente ao tamanho do item de dado em que as operações de lock podem ocorrer. Podem ser: - Coluna - Bloco do Disco - Linha - Arquivo - Tabela - Áreas Lógicas (oracle: tablespace, db2: dbspace, etc)

21. Escalonamento de Bloqueio (Lock)

Em alguns casos, uma transação necessita obter um lock exclusivo sobre um objeto no qual ela já possui um lock compartilhado. Isto é chamado de upgrade de lock e é uma característica importante e desejável nos SGDBs. A escolha da Granularidade (maior ou menor) pode afetar a execução do controle de concorrência. Em alguns bancos de dados a questão da granularidade é uma opção para se tratar melhor determinadas situações onde uma classificação de lock pode melhorar o desempenho de uma transação. Ex: Sair de uma série de “rows lock” para um “table lock” caso a quantidade de linhas alcance um volume significativo da tabela. Em outros bancos de dados a questão da granularidade é afetada pela arquitetura do sistema de banco de dados. Ex: Se um banco de dados só consegue fazer lock por bloco e não por linha, várias linhas serão afetadas pela utilização de somente uma delas.

22. Sumário

22. Sumário