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