5 Transações e Controle de Concorrência (parte 1)

Prévia do material em texto

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, duranteo 
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