Teoria de Processamento de Transações

Teoria de Processamento de Transações
Introdução
Definimos o conceito de uma transação, que é usado para representar uma unidade lógica de
processamento de banco de dados que deve ser concluída por inteiro para garantir a exatidão.
Uma transação normalmente é implementada por um programa de computador que inclui
comandos de banco de dados como recuperação, inserções, exclusões e atualizações.
Sistemas de monousuário versus multiusuário
Um critério para classificar um sistema de banco de dados é de acordo com o número de
usuários que podem usar o sistema simultaneamente. Um SGBD é monousuário se no
máximo um usuário de cada vez pode utilizar o sistema, e é multiusuário se muitos usuários
puderem fazê-lo – e, portanto, acessar o banco de dados – simultaneamente.
Exemplos:
Sistema monousuário: restrito a sistemas de computador pessoal.
Sistema multiusuário: sistemas de reservas aéreas.
Multiusuários podem acessar os bancos de dados – e usar sistemas de computação –
simultaneamente devido ao conceito da multiprogramação, que permite que o sistema
operacional do computador execute vários programas – ou processos – ao mesmo tempo. Uma
única unidade central de processamento (CPU) pode executar apenas, e no máximo, um
processo de cada vez.
A execução simultânea dos processos é, na realidade, intercalada, conforme ilustrado na Figura
1, que mostra dois processos, A e B, executando simultaneamente em um padrão intercalado.
Se o sistema de computação tiver múltiplos processadores de hardware (CPUs), o
processamento paralelo de vários processos é possível, conforme ilustrado pelos processos C e
D da Figura 1.
Figura 1. Processamento intercalado versus processamento paralelo de transações simultâneas
(Elmasri e Navathe, 2011).
ENG10734 – Gerenciamento de Banco de dados
Pág. 1
É importante ressaltar que boa parte da teoria referente ao controle de concorrência nos bancos
de dados é desenvolvida em relação à concorrência intercalada.
Um modo de especificar os limites de transação é determinado pelas instruções explícitas Begin
transaction e end transaction em um programa de aplicação. Todas as operações em de acesso
ao banco de dados efetuadas entre estes dois comandos, são consideradas operações de uma
transação.
É chamada transação somente de leitura, a transação que apenas recuperar dados (SELECT).
Por outro lado, se além de recuperar dados, outras operações como inserção, alteração e
exclusão ocorrerem, esta transação é chamada de transação de leitura-gravação.
Um banco de dados é basicamente representado como uma coleção de itens de dados nomeados.
Um item de dados pode ser um registro de banco de dados, mas também pode ser uma unidade
maior, como um bloco de disco inteiro, ou mesmo uma unidade menor, como um valor de
campo (atributo). O tamanho de um item de dados é chamado de sua granularidade. Vale
ressaltar que, cada item de dados tem um nome único, que no geral não é utilizado pelo
programador; em vez disso, ele é apenas um meio para identificar exclusivamente cada item de
dados.
Operações básicas de acesso ao banco de dados:
 READ_ITEM(X): Lê um item do banco de dados para uma variável do programa.
 WRITE_ITEM(X): Grava o valor da variável de programa X no item de banco de
dados chamado X.
A execução de um comando READ_ITEM(X) inclui as seguintes etapas:
1. Ache o endereço do bloco de disco que contém o item X.
2. Copie esse bloco de disco para um buffer na memória principal.
3. Copie o item X do buffer para a variável de programa chamada X.
A execução de um comando WRITE_ITEM(X) inclui as seguintes etapas:
1. Ache o endereço do bloco de disco que contém o item X.
2. Copie esse bloco de disco para um buffer da memória principal.
3. Copie o item X da variável de programa chamada X para o local correto no buffer.
4. Armazene o bloco atualizado do buffer de volta no disco (imediatamente ou em algum
momento posterior).
A Figura 2 mostra exemplos de duas transações. O conjunto de leitura de uma transação é o
conjunto de todos os itens que a transação lê, e o conjunto de gravação é o conjunto de todos
os itens que a transação grava. Por exemplo, o conjunto de leitura de T1 é {X, Y} e seu conjunto
de gravação também é {X, Y}.
ENG10734 – Gerenciamento de Banco de dados
Pág. 2
Figura 2. Duas transações de exemplo. (a) Transação T1. (b) Transação T2 (Elmasri e Navathe,
2011).
Os mecanismos de controle de concorrência e recuperação tratam principalmente dos comandos
de banco de dados em uma transação. As transações submetidas pelos diversos usuários podem
ser executadas simultaneamente, acessar e atualizar os mesmos itens de banco de dados. Se essa
execução simultânea for descontrolada, ela pode ocasionar problemas, como um banco de
dados inconsistente.
Uma transação é vista pelo SGBD como uma série ou lista de ações. As ações que podem ser
executadas por uma transação
Por que o controle de concorrência é necessário
Para ilustrar alguns desses problemas, faremos uma referência a um banco de dados, muito
simplificado, de reservas e uma companhia aérea, no qual será armazenado um registro para
cada voo da companhia. Cada registro conterá, como um item denominado de dados, o número
de poltronas reservadas para aquele voo, entre outras informações. A Figura 3.a mostra uma
transação T1 que transfere N reservas de um voo, cujo número de poltronas reservadas está em
um item do banco de dados chamado X, para um outro voo, cujo número de assentos reservados
está armazenado em um item de dados chamado Y. A Figura 3.b mostra uma transação T2 mais
simples, que apenas reserva M assentos no mesmo voo (X) referenciado na transação T1.
Problemas com transações executadas concorrentemente



O Problema da Atualização Perdida. Esse problema ocorre quando duas transações
que acessam os mesmos itens de banco de dados tiverem suas operações intercaladas,
de forma que tornem o valor de alguns dos itens do banco de dados incorreto. Este tipo
de problema é ilustrado na Figura 3.a.
O Problema da Atualização Temporária (ou Dirty Read – Leitura de Sujeira). Esse
problema ocorre quando uma transação atualizar um item de banco de dados e, a seguir,
falhar por alguma razão. A Figura 3.b mostra um exemplo para este tipo de problema.
O Problema do Sumário Incorreto. Se uma transação aplicar uma função agregada
para sumário de um número de registros enquanto outras transações estiverem
atualizando alguns desses registros, a função agregada deverá calcular alguns valores
antes de eles serem atualizados e outros depois de feita a atualização. A Figura 3.c
ilustra uma situação para este tipo de problema.
ENG10734 – Gerenciamento de Banco de dados
Pág. 3

Leitura sem Repetição. Quando uma transação T lê um item duas vezes e o item for
modificado por outra transação T’ entre essas duas leituras.
Figura 3. Problemas que podem ocorrer quando uma execução concorrente não for controlada
(Elmasri e Navathe, 2011).
Por que a Restauração (Recuperação) é Necessária
Se uma transação for executada por um SGBD, o sistema deverá garantir que:
1. Todas as operações na transação foram completadas com sucesso e seu efeito será
gravado permanentemente no banco de dados;
2. A transação não terá nenhum efeito sobre o banco de dados ou sobre quaisquer outras
transações.
Tipos de Falhas de uma Transação
1. O computador falhar (crash ou queda do sistema);
ENG10734 – Gerenciamento de Banco de dados
Pág. 4
2.
3.
4.
5.
6.
Um erro de transação ou sistema;
Erros locais ou condições de execução detectadas pela transação;
Imposição de controle de concorrência (deadlock);
Falhas de disco;
Problemas físicos e catástrofes.
Conceitos de Transação e Sistema
Estados da Transação e Operações Adicionais
Uma transação é uma unidade atômica de trabalho que ou estará completa ou não foi realizada.
Para propostas de restauração, o sistema precisa manter o controle de quando a transação inicia,
termina e de suas efetivações ou interrupções (commits ou aborts). Portanto, o administrados de
restaurações mantém o controle das seguintes operações:
 BEGIN_TRANSACTION;
 READ ou WRITE;
 END_TRANSACTION;
 COMMIT_TRANSACTION;
 ROLLBACK (ou ABORT).
A Figura 4 mostra um diagrama de transição de estados que descreve como uma transação
percorre seus estados de execução. Uma transação entra em estado ativo imediatamente após o
início de sua execução, no qual poderá emitir operações READ (leitura) e WRITE (gravação).
Quando a transação termina, ela passa para o estado de efetivação parcial. Nesse ponto, alguns
protocolos de restauração precisam garantir que uma falha de sistema não impossibilite a
gravação permanente das mudanças promovidas pela transação (geralmente pela gravação de
mudanças no log do sistema). Uma vez atendidas todas as verificações, diz-se que a transação
alcançou seu ponto de efetivação, e entra, então, no estado de efetivação (committed state).
Figura 4. Diagrama de transição de estado (Elmasri e Navathe, 2011).
Entretanto, uma transação poderá entrar em estado de falha se uma das verificações falhar ou
se a transação for interrompida durante seu estado ativo. A transação poderá, então, ser revertida
para desfazer os efeitos de suas operações WRITE no banco de dados. O estado encerrado
corresponde ao estado da transação quando deixa o sistema.
ENG10734 – Gerenciamento de Banco de dados
Pág. 5
O Log (Registro de Ocorrência) do Sistema
Para poder se recuperar de falhas que afetam as transações, o sistema mantém um log para
controlar todas as operações da transação que afetam valores dos itens do banco de dados.
Ponto de Efetivação (Commit Point) de uma Transação
Uma transação T alcança seu ponto de efetivação (commit point) quando todas as operações
que acessam o banco de dados estão sendo executadas com sucesso e o efeito de todas elas
estiverem sendo gravado no log.
Para reduzir a carga de sistema (overhead), os arquivos de log são gravados no disco em blocos.
Vale ressaltar, que, antes que uma transação alcance seu ponto de efetivação, toda porção do log
que ainda não tiver sido registrada em disco precisará agora ser feita. Esse processo é chamado
de gravação formada (force-writting), do arquivo de log antes da efetivação de uma transação.
Propriedades Desejáveis das Transações
As transações devem possuir algumas propriedades, chamadas propriedades ACID, e elas
devem ser impostas pelo controle de concorrência e métodos de restauração do SGBD. As
propriedades ACID são as seguintes:
1. Atomicidade: Uma transação é uma unidade atômica de processamento; ou ela será
executada em sua totalidade ou não será de modo nenhum.
2. Preservação de consistência: Uma transação será preservadora de consistência se sua
execução completa fizer o banco de dados passar de um estado consistente para outro.
3. Isolamento: Uma transação deve ser executada como se estivesse isolada das demais.
Isto é, a execução de uma transação não deve sofrer interferência de quaisquer outras
transações concorrentes.
4. Durabilidade ou permanência: As mudanças aplicadas ao banco de dados por uma
transação efetivada devem persistir no banco de dados. Essas mudanças não devem ser
perdidas em razão de uma falha.
Plano de Execução (SchedulesI)
Quando transações são executadas concorrentemente, de maneira intercalada, a ordem de
execução das operações das várias transações é conhecida como plano de execução (ou
histórico).
Planos de Execução (Histórico) de Transações
Um plano (ou histórico) S de n transações T1, T2, ..., Tn é a ordenação das operações das
transações sujeitas a uma restrição tal que, para cada transação Ti que participe de S, as
operações de Ti em S deverão aparecer na mesma ordem em que elas ocorrem em Ti. Observe,
entretanto, que operações de outras transações Tj poderão ser intercaladas com as operações de
ENG10734 – Gerenciamento de Banco de dados
Pág. 6
Ti em S. Por hora, considere que a ordem das operações em S seja a ordenação total, embora
teoricamente seja possível tratar planos cujas operações tenham ordenações parciais.
Para fins de restauração e controle de concorrência, estamos interessados principalmente nas
operações de LER_ITEM (leitura de item) e ESCREVER_ITEM (gravação de um item), bem
como nas operações COMMIT (efetivação) e ABORT (interrupção). Uma notação resumida
para codificação de um plano usa os símbolos r, w, c e a para as operações de LER_ITEM,
ESCREVER_ITEM, COMMIT e ABORT, respectivamente, e anexa para documentação, o id
da transação (número da transação) em cada operação do plano. Nessa notação, o item X do
banco de dados que for lido ou gravado segue as operações r e w entre parênteses. Por exemplo,
o plano da Figura 3.a, que chamaremos de Sa, pode ser escrito nesta notação, como segue:
Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);
De forma similar, o plano para a Figura 3.b, que chamaremos de Sb, pode ser escrito como
segue, se assumirmos que a transação T1 abortou depois de sua operação de LER_ITEM(Y):
Sb: r1(X); w1(X); r2(X); w2(X); r1(Y); a1;
Duas operações de um plano são ditas em conflito se elas satisfizerem todas as três condições
seguintes:
1. Pertencerem a diferentes transações;
2. Acessarem o mesmo item X; e
3. Pelo menos uma das operações ser em ESCREVER_ITEM(X).
Por exemplo, se o plano As, as operações r1(X) e w2(X) conflitam, bem como as operações de
r2(X) e w1(X), e as operações w1(X) e w2(X). Entretanto, as operações r1(X) e r2(X) não conflitam,
uma vez que ambas são de leitura; as operações w2(X) e w1(Y) não conflitam por que operam em
diferentes itens de dados, X e Y; e as operações r1(X) e w1(X) não conflitam porque pertencem à
mesma transação.
Um plano S, de n transações T1, T2, ..., Tn é chamado de plano completo se forem garantidas as
seguintes condições:
1. As operações em S são exatamente as operações de T1, T2, ..., Tn, tendo um commit ou
um abort como última operação de cada transação no plano.
2. Para quaisquer pares de operações da mesma transação Ti, sua ordem de aparecimento
em S será a mesma que em Ti.
3. Para quaisquer duas operações conflitantes, uma das duas precisa aparecer antes da
outra o plano.
A condição (3) anterior permite que duas operações não conflitantes apareçam no plano sem
definir qual deva aparecer primeiro, levando, assim, à definição de um plano com ordenação
parcial das operações das n transações. Entretanto, a ordenação total deve ser especificada em
planos com algum par de operações conflitantes (condição 3), e para algum par de operações da
mesma transação (condição 2). A condição 1 simplesmente declara que todas as operações das
transações devem aparecer em um plano completo. Uma vez que toda transação ou será
efetivada ou será abortada, um plano completo não conterá nenhuma transação ativa em seu
término.
ENG10734 – Gerenciamento de Banco de dados
Pág. 7
Referências
Elmasri R.; Navathe, S.B.; Sistemas de Banco de Dados. 6ed, Ed. Pearson Education, 2011.
ISBN: 9788579360855.
Ramakrishnan, R.; Gehrke, J.; Sistemas de Gerenciamento de Banco de Dados. 3ed, Ed. Mc
Graw Hill, 2008. ISBN: 9788577260270.
ENG10734 – Gerenciamento de Banco de dados
Pág. 8