Captulo 6.

INTRODUO GERNCIA DE TRANSAES

No captulo anterior foram descritos procedimentos atravs dos quais comandos que partem do usurio so decompostos em aes elementares e distribudos atravs dos vrios ns que compem o sistema. As preocupaes bsicas recaam, tipicamente, em tcnicas para se determinar quais os mecanismos de acesso mais eficientes s tabelas residentes em cada n particular; em como deslocar dados entre os ns quando a informao necessria encontra-se distribuda ou mesmo replicada pelos vrios ns; etc. Neste captulo, e de ora em diante, tais questes sero pressupostas como devidamente equacionadas. Tudo se passa como se adentrssemos uma camada mais interior do sistema de gerncia do banco de dados qual so requisitadas tarefas bem determinadas. O leitor deve estar atento para o fato de que tais tarefas ou seqncias de aes elementares manipulam os dados a nvel fsico, uma vez que o processador de comandos da LMD, discutido no captulo anterior, j resolveu, a partir de uma anlise da consulta do usurio, todos os dilemas a nvel lgico. O objetivo primordial deste captulo dar uma viso panormica dos problemas enfrentados pelo gerente de transaes. O conceito fundamental de uma transao introduzido na prxima seo. Toda discusso subseqente dele depender criticamente. A seo seguinte aborda aspectos relativos ao gerenciamento de transaes e discute os procedimentos que devem ser efetivados em vrios pontos especficos durante a execuo de transaes. A prxima seo toca nos problemas advindos de falhas no sistema que perturbam o ciclo de vida normal de transaes em execuo. Por questes de eficincia do sistema como um todo desejvel que vrias transaes executem simultaneamente em cada n. Isto acarreta problemas de controle de concorrncia que so mencionados na ltima seo deste captulo. Os trs captulos seguintes detalham as questes relativas ao gerenciamento de transaes, controle de concorrncia e falhas no sistema, respectivamente.

6.1 O CONCEITO DE TRANSAO

6.1.1 Noes Bsicas A nvel lgico, um banco de dados distribudo descrito por um esquema conceitual global. Neste e nos captulos que se seguem, os objetos descritos no esquema conceitual global sero chamados de objetos lgicos, e uma funo associando a cada objeto lgico um valor ser chamada de estado lgico do banco. A linguagem de manipulao de dados (LMD) oferece ento uma srie de comandos para criar, destruir ou modificar objetos lgicos. Embora a natureza dos objetos lgicos e as caractersticas da LMD dependam do modelo de dados usado para descrever esquemas conceituais, a discusso neste captulo ser largamente independente destes detalhes. A nvel fsico, o banco de dados definido atravs de uma srie de esquemas internos, um para cada n em que o banco armazenado. Os objetos descritos nos esquemas internos sero chamados de objetos fsicos ou simplesmente objetos. A cada objeto fsico est associado um nico nome de tal forma que objetos diferentes recebem nomes distintos. Os operadores atmicos que atuam sobre os objetos fsicos sero chamadas de aes elementares. Finalmente, a cada instante, o estado fsico ou, simplesmente, o estado do banco de dados associa a cada objeto fsico um determinado valor, que poder mudar por meio de uma ao elementar. -1-

O relacionamento entre o esquema conceitual global e os vrios esquemas internos definido atravs de mapeamentos, que servem a dois propsitos: 1. indicar os objetos fsicos que implementam um objeto lgico; 2. indicar como construir um estado lgico do banco a partir do estado fsico corrente. A cada objeto lgico podero naturalmente estar associados vrios objetos fsicos atravs destes mapeamentos. Neste captulo, para efeitos dos exemplos, assumiremos que o modelo relacional usado para descrever o esquema conceitual global e que a linguagem de manipulao de dados SQL. Portanto, os objetos lgicos sero relaes, tuplas e campos de tuplas. Quanto aos objetos fsicos, assumiremos que so tabelas do SAR, e no pginas e segmentos conforme seria de se supor tendo em vista a discusso da Seo 3.3. Isto uma mera convenincia para tornar os exemplos mais simples. Alm disto, assumiremos ainda que as tabelas so descritas como "arrays" em PASCAL, o que possibilita usar a notao usual de PASCAL para descrever aes elementares sobre as tabelas. Um exemplo simples servir para esclarecer a discusso acima, um tanto compacta. Considere um esquema conceitual global contendo apenas um esquema de relao, definida como (ignorando os domnios dos atributos):
CONTAS[CPF,NOME,SALARIO,ENDERECO,NUMERO_CONTA,SALDO,SALDO_MEDIO]

A chave neste caso NUMERO_CONTA. Suponha que este esquema de relao mapeado em duas tabelas, CADASTRO e CONTAS_CORRENTES (a localizao exata das tabelas no importante), descritas da seguinte forma:
type PESSOA = record of CPF = integer; NOME = array[1..30] of CHAR; SALARIO = real; ENDERECO = array[1..5,1..50] of CHAR end; MOVIMENTO = record of NUMERO_CONTA, CPF integer; SALDO, SALDO_MEDIO = real end; var CADASTRO = array[1..1000] of PESSOA; CONTAS_CORRENTES = array[1..1000] of MOVIMENTO;

O mapeamento de CONTAS nas tabelas CADASTRO e CONTAS_CORRESTES definido da seguinte forma:

CADASTRO a projeo de CONTAS em CPF, NOME, SALARIO, ENDERECO; CONTAS_CORRENTES SALDO, SALDO_MEDIO.

a projeo de CONTAS em NUMERO_CONTA, CPF,

-2-

Os objetos lgicos deste banco sero dados pela relao associada a CONTAS, as tuplas da relao associada a CONTAS e os campos destas tuplas. Note que as tuplas, ao contrrio das relaes, no tm um nome especfico. Os objetos fsicos sero as tabelas, os elementos das tabelas e seus campos. Um comando de SQL, a LMD usada no exemplo, refere-se a uma relao pelo seu nome (dado no esquema conceitual), mas identifica as tuplas de uma relao pelos valores dos seus campos. Observe a seguinte atualizao:
update CONTAS set SALDO = SALDO - 1000 where NUMERO_CONTA = 34.567

Atravs de uma srie de transformaes, um comando da LMD eventualmente gera uma seqncia de aes elementares. Por exemplo, o comando anterior poderia gerar a seguinte seqncia
A1 = (LEIA,CONTAS_CORRENTES[4].SALDO,X) A2 = (COMPUTE,X:=X-1000) A3 = (ESCREVA,CONTAS_CORRENTES[4].SALDO,X)

onde X representa uma varivel tipo "real" e :f/CONTAS_CORRENTES[4] indica que o quarto elemento de CONTAS_CORRENTES corresponde a tuplas de CONTAS com NUMERO_CONTA =
34.567.

Por ltimo, h a noo de consistncia de estados. Podemos visualizar tambm dois nveis de consistncia para o banco, consistncia lgica e consistncia interna. Considere consistncia lgica primeiro. fcil de aceitar que, sob o ponto de vista do usurio, cada estado do banco deve satisfazer certos critrios de consistncia. Por exemplo, o saldo das contas dever ser sempre positivo. Um estado lgico do banco consistente quando satisfizer a todos os critrios de consistncia. Caso contrrio, diz-se que o estado inconsistente. Suporemos aqui que no seja de responsabilidade do SGBD cuidar para que violaes dos critrios de consistncia no ocorram. Isto ser obrigao do usurio ao codificar as atualizaes do banco. J consistncia interna se refere coerncia das estruturas internas (objetos fsicos) usados para armazenar o banco. Por exemplo, uma rvore-B poder ser usada para manter um ndice sobre determinados campos de uma tabela. Isto implica que as chaves e ponteiros da rvore-B devem estar sempre consistentes com os dados armazenados na prpria tabela. Dentro deste conceito, o SGBD dever, ento, ser responsvel pela manuteno da consistncia interna do banco. 6.1.2 Transaes Suponha que um usurio apresente a seguinte atualizao a um banco de dados usado para processar compensao de cheques bancrios.
Debite $100,00 conta corrente do cliente N Credite $100,00 conta corrente do cliente M

Aps manipulao pelo processador de consultas, teramos algo como a seguinte seqncia de aes elementares

-3-

A1 = (LEIA,CONTA_CORRENTE[A].SALDO,X) A2 = (COMPUTE, W:=X-100) A3 = (ESCREVA,CONTA_CORRENTE[A].SALDO,W) A4 = (LEIA,CONTA_CORRENTE[B].SALDO,X) A2 = (COMPUTE, W:=X+100) A6 = (ESCREVA,CONTA_CORRENTE[B].SALDO,W)

onde A e B so os elementos de CONTA_CORRENTE correspondentes s tuplas de CONTAS com NUMERO_CONTA = N e NUMERO_CONTA = M, respectivamente. Por alguma razo qualquer (falta de energia, falhas no equipamento ou programas, etc.)., a atividade do banco de dados interrompida aps a execuo da ao elementar A3. Ao retornar atividade, teramos debitado $100,00 conta de A e ainda no creditado valor algum conta de B. Isto colocaria o banco de dados num estado inconsistente, pois $100,00 teriam simplesmente "desaparecido". Seria muito conveniente se pudssemos assegurar que a seqncia de aes elementares acima tivesse a propriedade de que "ou todas as aes elementares executam com sucesso ou nenhuma delas executada". Em outras palavras, gostaramos de estender o conceito de atomicidade de modo a envolver agora tambm seqncias de aes elementares. A atomicidade de seqncia de aes elementares poderia tambm ser violada por interferncia de outras aes executadas concorrentemente (exemplos sero dados no Captulo 8). A noo de transao introduzida para forar o sistema a executar uma seqncia de aes elementares como se fosse uma unidade atmica, sem interferncia externa. A nvel lgico, uma transao definida atravs de um programa em uma linguagem de alto nvel, contendo comandos da LMD embebidos, e iniciado e terminado pelos comandos COMEO-DE-TRANSAO e FIM-DE-TRANSAO. Na sua forma mais simples, uma transao contm apenas um comando da LMD. Exige-se do usurio que codifique as transaes de tal forma que quando executadas sozinhas: T1. T2. S1. S2. sempre terminem; preservem a consistncia do banco de dados. a transao T seja executada por completo; a execuo da transao T se d sem interferncia de outras transaes que porventura estejam sendo executadas concorrentemente.

Exige-se do SGBD, por sua vez, que a cada invocao de uma transao T:

Lembremos que a cada transao T corresponde uma seqncia de aes elementares sobre os objetos fsicos. O primeiro requisito, S1, garante ento que o efeito lquido, isto , aquele que ser tornado pblico aps o trmino da chamada a T, refletir o fato de que todas ou nenhuma das aes elementares de T foram executadas. Note que isto no implica em que cada uma das aes de T deva ser ativada apenas uma nica vez. Para ver isto, suponha que existam, no repertrio de aes elementares do n onde T foi executada, as aes elementares A1 ,, An onde Ai indica a ao elementar de efeito exatamente contrrio Ai. Em outras palavras, Ai devolve o banco de dados ao estado anterior execuo de Ai. Retornando ao exemplo anterior sobre compensao bancria, fcil ver que A1 , como uma

-4-

operao de "leitura", no altera o estado do banco. Portanto, seria vlido colocar A1 = (NULO), isto , A1 no corresponde operao alguma. Idem, A2 = (NULO). Continuando, A3 = (ESCREVA, CONTA_CORRENTE[A].SALDO, X) pois a varivel X detm o contedo inicial de CONTA_CORRENTE[A].SALDO at o trmino da transao. Note que isto restaura o valor do objeto CONTA_CORRENTE[A] ao valor que apresentava antes da execuo de A3. Podemos definir A4, A5 e A6 analogamente. Dentro deste esprito, se E = (A1, A2, A3, A4) for a seqncia de aes elementares gerada por uma execuo seqencial de T, ento cada uma das seqncias de aes elementares abaixo, quando ativadas pelo sistema, satisfazem ao requisito contido no item (1) acima. A1 , A2 , A3 , A4 A1 , A2 , A2 , A2 , A3 , A4 , A4 , A4 A1 , A1 , A1 , A1 , A1 , A2 , A3 , A3 , A2 , A1 , A1 , A2 , A3 , A4 Na realidade, embora as aes elementares Ai paream um tanto obtusas no momento, desempenharo um papel crucial nas idias a serem desenvolvidas mais adiante. O leitor atento j deve ter percebido isto. Voltando ao exemplo da compensao bancria, caso o sistema falhe aps a execuo das aes elementares A1 , A2 e A3 , e supondo que os objetos envolvidos residam em memria secundria, ao retornar atividade o banco de dados estaria em um estado refletindo uma execuo parcial de T. Neste ponto, aps executada as aes U = ( A3 , A2 , A1 ) o banco de dados recairia novamente em um estado que no reflete nenhuma ao de T, podendo retomar suas atividades normais. O segundo requisito, S2, no exclui a possibilidade de intercalar aes elementares de transaes diferentes sobre o mesmo banco de dados local, ou de executar paralelamente aes elementares da mesma transao ou de transaes diferentes sobre bancos de dados locais distintos. No entanto, o requisito S2 exige que algum controle seja exercido para que o nvel de concorrncia permitido no destrua a idia de atomicidade da execuo das transaes.

6.2 EXECUTANDO TRANSAES: INCIO, MIGRAO E TRMINO

Recordemos inicialmente a arquitetura para SGBDDs introduzida na Seo 1.1.3. Em um primeiro nvel, esta arquitetura divide o SGBDD em uma coleo de SGBDs locais interligados pelo SGBD global. Cada n da rede possui uma cpia do SGBD global. Este, por sua vez, dividido em trs grandes componentes: 1. diretrio de dados global (DDG): contm descries dos objetos lgicos e fsicos e dos mapeamentos entre estes; 2. gerente de transaes (GT): interpreta e controla o processamento de consultas e transaes submetidas ao sistema; 3. gerente de dados (GD): interface com o SGBD local, fazendo as tradues necessrias no caso de sistemas heterogneos. -5-

O propsito desta seo ser apresentar em mais detalhe como um GT processa transaes. Considere uma transao sobre um determinado banco de dados definida por um programa em uma linguagem de alto nvel contendo comandos da LMD embebidos. Como tal, a transao ter que passar por uma compilao inicial. Durante esta fase, os comandos da LMD encontrados podero ser tratados de duas formas distintas. Uma estratgia seria preparar, j nesta fase, um plano completo para sua execuo, o que equivaleria a uma compilao prvia dos comandos. Uma segunda estratgia seria substituir cada comando da LMD por uma chamada para o SGBDD, postergando o tratamento do comando. Em qualquer caso, o resultado da fase de compilao ser um programa objeto contendo chamadas para o SGBDD. Quando a transao T chamada, o gerente de transaes do seu n de origem assume o controle do seu processamento. O GT aciona mecanismos apropriados antes do incio da transao quando do trmino da transao durante a execuo da transao

Quando do incio da transao, o gerente de transaes deve identificar a transao de maneira unvoca. Esta identificao ser estendida a cada ao elementar executada a favor desta transao. Desta forma, no caso de ser necessrio desfazer parte das aes elementares associadas a uma particular transao, o gerente de transaes ter condies de faz-lo sem problemas. Tambm importante iniciar todo um contexto apropriado do qual dependero os mecanismos de controle de concorrncia e controle de integridade, que podero ser acionados durante a execuo da transao. Durante a execuo do programa-objeto que define a transao, o SGBDD chamado em cada ponto onde havia um comando da LMD. Se a estratgia de compilao prvia no foi adotada, o GT intersepta estas chamadas e invoca o processador de comandos da LMD para criar um plano de execuo para o comando. Caso tenha sido, o GT apenas verifica se o plano ainda continua vlido, refazendo-o se houve mudanas no banco de dados que o invalide. Um plano de execuo descrito por um programa concorrente consistindo de consultas e atualizaes para serem executadas pelos SGBDs locais, alm de transferncias de arquivos. Uma vez de posse do plano de execuo para o comando corrente, o GT chama o executor de transaes, ET, para interpretar o plano. O papel do ET consiste em enviar as consultas, atualizaes e transferncias para os ns apropriados e garantir que so executadas na ordem correta e em paralelo, quando o plano assim o permitir. Durante a execuo de transaes sob seu controle, o gerente de transaes interage tanto com os mecanismos de controle de concorrncia quanto com os mecanismos de controle de integridade. preciso que o gerente de transaes esteja atento ao fato de que recursos, do sistema estaro sendo requisitados pelas vrias transaes em andamento. Ao conceder o uso de determinados recursos o gerente de transaes aciona os procedimentos de controle de concorrncia para evitar que mais de uma transao tenha acesso, simultaneamente, a recursos que no podem ser compartilhados. Por outro lado, o prprio fato de cancelar transaes pressupe, tambm, que o gerente de transaes mantm um histrico da

-6-

seqncia de aes que vo sendo executadas em favor da transao. De outra forma, pode ser impossvel realizar a funo de controle de integridade uma vez que no haveria meios de se inverter efeitos de aes elementares passadas. Manter este histrico tarefa dos processos de controle de integridade com os quais o gerente de transaes deve, portanto, manter estreito contato durante a execuo da transao. Quando do trmino da transao, uma deciso deve ser tomada no sentido de tornar pblico todos os efeitos das aes elementares executadas em benefcio da transao ou nenhum deles, em cujo caso as aes elementares j invocadas devem ter seus efeitos removidos do BD. No primeiro caso, diz-se que a transao foi confirmada reservando-se o termo cancelada para o segundo caso. Uma transao pode terminar de forma natural ou devido a causas excepcionais. Quando terminada de maneira excepcional, tipicamente devido a falhas ou a incompatibilidades insolveis na repartio dos recursos do sistema, como veremos nas sees seguintes, a transao ser sempre cancelada. Neste instante, entram em ao os mecanismos de controle de integridade que invertero a transao, restaurando o BD a um estado consistente de onde possa recomear suas operaes normais. Transaes tambm podem ser canceladas mesmo estando em processamento normal. Isto pode ser visualizado num cenrio onde transaes so executadas iterativamente e o usurio tem a opo de simplesmente abandonar a transao antes de complet-la. Neste caso, a transao est sendo cancelada a pedido do usurio, no devido a fatores anormais operao do sistema. claro que os meios de controle de integridade devem, tambm neste caso, ser acionados para garantir a consistncia do BD. Note que o processo de confirmar uma transao tambm envolve os mecanismos de controle de integridade, pelo menos para registrar que este fato ocorreu, evitando que uma transao j confirmada tenha seus efeitos removidos quando de uma eventual falha posterior do sistema. Finalmente, ao trmino da transao, o gerente de transaes deve garantir que todos os recursos apropriados temporariamente por esta transao voltem ao controle do SGBD, sendo postos a disposio de outras transaes. Em um cenrio distribudo os mecanismos para terminar uma transao no so simples. De alguma forma todos os ns que se envolveram com a transao devem refletir ou remover todos os efeitos das aes elementares executadas em favor da particular transao. Quando do trmino da transao, portanto, protocolos especiais devem ser ativados para garantir a atomicidade da transao como um todo, mesmo na presena de falhas repetidas e imprevisveis que podem afetar a operao normal de vrios dentre os ns participantes. O leitor pode imaginar as dificuldades enfrentadas por um processo distribudo cuja misso seja obter o acrdo detodos os ns envolvidos quando uns e outros podem ser acometidos das falhas as mais variadas. No caso centralizado este complicador simplesmente inexiste. O problema referente confirmao/cancelamento de transaes fundamental. Em BDs distribudos os ns participantes devem adotar um protocolo comum para que o processo se desenvolva de forma ordenada. Uma possibilidade seria adotar o protocolo bifsico para confirmar intenes, ou simplesmente protocolo bifsico. Existem vrias verses deste protocolo, diferindo mais em aspectos de implementao que de filosofia bsica. Todas seguem o esquema geral abaixo. Suponha que uma transao distribuda chegou ao ponto onde deve ser confirmada ou cancelada. Um dos ns participantes, por exemplo o n de origem da transao, estabelecido, "a priori", como o coordenador da operao. Este coordenador conhecido dos demais ns e tambm dispe da identidade de todos os ns participantes. Isto no difcil de ser conseguido durante a fase em que a transao migra de um n para outro e dados so enviados de volta aos ns requisitantes.

-7-

NUMA PRIMEIRA FASE coordenador: envia, a todos os ns participantes, mensagens na forma PREPARE-SE. cada n participante 1. ao receber uma mensagem de PREPARE-SE vinda do coordenador, tenta registrar em memria estvel, isto , de forma que sobreviva eventuais falhas do sistema, os efeitos locais da transao 2. a seguir, envia ao coordenador mensagens na forma PREPARADO caso tenha conseguido o registro em memria estvel, ou na forma IMPOSSIBILITADO em caso contrrio NUMA SEGUNDA FASE coordenador 1. envia a todos os ns participantes a mensagem CONFIRME, caso deseje confirmar a transao e todos os ns participantes tenham remetido a mensagem PREPARADO na primeira fase; 2. em qualquer outro caso, o coordenador envia a mensagem CANCELE a todos os ns participantes cada n participante: ao receber o veredito do coordenador, procede de acordo com este.

Se nenhum dos ns participantes, o coordenador ou os canais de comunicao forem acometidos por falhas durante o processo, fcil de ver que o protocolo funciona a contento. O Captulo 7 contm mais detalhes sobre o mtodo, bem como explora outras variantes e filosofias que visam solucionar o problema, garantindo sempre a propriedade de atomicidade inerente ao conceito de transao. L tambm so examinados mecanismos para se lidar com as questes da migrao e trmino de transaes. Isto conclui a nossa descrio do processamento de transaes neste captulo.

6.3 FALHAS NO SISTEMA

Dada a complexidade dos equipamentos e programas modernos, ponto pacfico que falhas ocorrero, quer sejam problemas de "hardware", quer sejam defeitos de "software". Estas falhas tm como efeito indesejvel comprometer a integridade do BD. Para que seja de alguma utilidade prtica, O SGBD deve, portanto, incorporar mecanismos que garantam sua integridade, quando no pelo menos na presena daquelas falhas que ocorrem com mais freqncia. Desta forma, o SGBD pode ser mantido em operao por longos perodos de tempo sendo, quando muito, interrompido por curtos intervalos para que os mecanismos de controle de integridade sanem inconsistncias causadas por eventuais falhas. Esta seo sevir de introduo rea de controle de integridade em SGBD, onde os principais problemas e as solues mais importantes sero mencionadas de forma simplificada. Em captulo posterior, esta problemtica ser analisada em maiores detalhes. Intuitivamente, a nica maneira do SGBD se proteger contra falhas, que podem destruir parte dos dados, criar e manter certa redundncia no sistema. Desta forma, quando parte do BD -8-

danificado, sua "cpia redundante" pode ser revivida para recuperar os dados perdidos e restabelecer a operao normal. Inclusive, em sistemas que requeiram alta confiabilidade, as partes mais crticas do prprio "hardware" podem ser duplicadas de forma redundante. Note que, se a "cpia" de um objeto no recente, ento deve-se manter tambm um histrico das operaes efetuadas sobre este objeto, de tal modo que o SGBD possa refazer estas operaes e trazer esta "cpia" ao estado mais recente, idntico quele da "cpia" original antes da falha. Caso contrrio, transaes executadas entre o instante de criao da "cpia" e o momento atual sero perdidas. 6.3.1 Tipos de Falhas Um n qualquer, quando em operao normal, depende de um padro de interligaes complexas entre vrios elementos. Para efeito de examinar a ocorrncia e danos causados por falhas nestes componentes conveniente agrup-los da seguinte forma procedimentos processadores memrias no caso distribudo, comunicao de dados

Por procedimentos entende-se a totalidade dos mdulos e programas aplicativos ("software") que compem o SGBD, podendo-se incluir aqui tambm os utilitrios do sistema operacional usados pelo SGBD. Os processadores correspondem tanto ao processador, ou processadores, central como as demais unidades de controle de perifricos, terminais, "modems", etc. As memrias, onde reside o BD, aqui entendido como dados mais programas, so de crucial importncia. l que ser acomodada toda redundncia introduzida para fins de controle de integridade. Todos os mecanismos de proteo contra falhas prestam especial ateno ao tratamento dispensado aos vrios tipos de memrias com que o sistema interage e, em ltima anlise, se fiaro na boa caracterstica de resistncia a falhas que tais elementos oferecem. Para que se possa conduzir uma anlise mais detalhada, as memrias manipuladas pelo sistema sero subdivididas em: memria principal memria secundria imediatamente disponvel memria secundria dormente

A memria principal corresponde a memria associada aos processadores, isto , memria dos processadores centrais, memrias tipo cache, "buffers" de entrada/sada, espao de paginao, etc. H certos tipos de falhas s quais o contedo da memria principal no sobrevive, devendo ser considerado como irremediavelmente perdido. Estes defeitos sero cognominados de falhas primrias. Interrupo no fornecimento de energia eltrica, defeito nos processadores ou procedimentos do sistema podem causar este tipo de falha. Por no sobreviver a este tipo de falha mais comum, diz-se que a memria principal voltil. O termo memria secundria imediatamente disponvel, ou memria secundria ativa, referem-se memria de massa, geralmente discos magnticos, onde o BD residente e que est a disposio do SGBD a todo instante. O contedo da memria secundria ativa no afetado por falhas primrias que o sistema venha a sofrer. Porm, panes nos cabeotes de leitura/escrita dos discos ou partculas de poeira que assentem sobre a superfcie dos mesmos podem danificar os delicados mecanismos dos cabeotes e provocar danos irrecuperveis superfcie magntica destruindo, em todo ou em parte, o contedo da memria secundria -9-

ativa. Isto se verificando, diz-se que o sistema sofreu uma falha secundria. Fitas magnticas tambm podem ser usadas como memria secundria ativa, se bem que cuidados devem ser tomados para que a eficincia do sistema no seja por demais comprometida. Partes raramente usadas do BD, cpias antigas de parte ou da ntegra do sistema, alm de aplicativos ativados com pouca freqncia, so candidatos naturais a residirem em fita. Nunca dicionrios, catlogos e outros elementos freqentemente acessados. Como um ltimo recurso, e em casos realmente catastrficos, o controle de integridade do SGBD pode apelar para a memria secundria dormente ("off-line"). Entende-se como memria secundria dormente toda memria fisicamente desconectada do sistema. Geralmente, devido sua grande capacidade de armazenamento de dados, fitas magnticas so empregadas para este fim. Em BD de grandes propores, toda uma fitoteca pode ser necessria. comum armazenar os componentes da memria secundria dormente em locais prprios, distantes do centro onde opera o sistema. A preocupao bsica evitar que catstrofes sobre um dos lugares, tais como incndios ou furtos, no afete o outro. De qualquer maneira, eventos que destruam ou inutilizem o contedo da memria secundria dormente do sistema sero chamados de falhas tercirias. Existem situaes que exigem aes por parte do sistema de controle de integridade do BD, embora no se configurem propriamente como falhas em componentes do sistema. O caso tpico quando, sob operao normal, surje a necessidade de se cancelar transaes. Isto pode ocorrer tanto por erro ou a pedido do usurio, como podem ser aes foradas pelo SGBD como ltima instncia para evitar bloqueio na execuo de transaes que competem por certos recursos do sistema. Estes casos sero rotulados como pseudo-falhas do sistema. Agora, no est em cheque o contedo de nenhuma das memrias ou a sanidade dos processadores ou procedimentos associados ao sistema. A cooperao do controle de integridade, porm, necessria para invocar a transao que inverte o efeito das aes elementares executadas em benefcio da transao a ser cancelada. Deste modo, o BD permanece em um estado consistente, alm do que forada a liberao dos recursos que foram seqestrados pela transao. A discusso acima desloca-se a partir de falhas nos componentes mais nobres, isto , com menor tempo de acesso, para os menos nobres, com tempos de acesso consideravelmente maiores. importante ter em mente uma noo da freqncia com que os vrios tipos de falhas costumam ocorrer na prtica, bem como do tempo necessrio para que o controle de integridade restaure a operao normal do BD em cada caso. A Figura 6.1 resume a situao.
TIPO DA FALHA Pseudo-falha Primria Secundria Terciria FREQNCIA vrias por minuto vrias por ms vrias por ano uma por sculo TEMPO DE RECUPERAO milisegundos segundos minutos dias

Figura 6.1 - Caractersticas de Falhas Est implcito aqui que o SGBD pode, ao ser reconduzido operao normal, detectar que uma falha primria causou a interrupo das operaes. Ao voltar vida, o SGBD acionaria o - 10 -

controle de integridade para levar o BD a um estado consistente. Falhas secundrias tambm seriam detectadas pelo SGBD que interromperia momentaneamente suas operaes normais e acionaria o controle de integridade. A deteo de falhas tercirias ficaria a cargo de operadores externos ao SGBD os quais, uma vez verificado o problema, rodariam processos especficos que eventualmente restaurariam a memria dormente do sistema. Outra suposio importante diz respeito a freqncia ou probabilidade de cada tipo de falha. Ser sempre suposto que os vrios componentes do sistema tm modos de falha independentes, de tal modo que so praticamente negligenciveis as chances de que ocorrero efeitos cascata com uma falha provocando outra. Mais ainda, a probabilidade de dupla falha, isto , de falhas simultneas, torna-se desprezvel. No caso de BD distribudos, h ainda o complicador adicional de que a rede comunicao de dados ou os protocolos de comunicao de dados podem, um ou ambos, falhar. Isto ocorrendo, diz-se que o sistema sofreu uma falha de comunicao de dados ou simplesmente uma falha de comunicao. Como alertado no Captulo 1, o sistema de comunicao de dados ser suposto perfeito do ponto de vista de que mensagens no so perdidas, danificadas ou entregues a destinatrios errados. Existem mecanismos prprios para se atingir tais objetivos, mecanismos estes que fogem ao escopo deste texto. Sob a tica do SGBD, porm, estes processos so totalmente transparentes. O SGBD apenas coloca mensagens, isto , endereos mais contedos, nos "buffers" de sada e supe que mensagens podem materializar-se em seus "buffers" de entrada. O primeiro complicador encontrado diz respeito detectabilidade de falhas de comunicao. Torna-se extremamente difcil, se no impossvel, para um particular n da rede descobrir se o outro n, com o qual deseja se comunicar, no responde porque a comunicao foi cortada por uma falha de comunicaes ou se o outro n est simplesmente sobrecarregado e, portanto, muito lento ao responder. Note que um dado n no pode simplesmente continuar a retransmitir mensagens, sem tomar nenhum cuidado adicional, at que o n destinatrio finalmente se manifeste. Sob este cenrio, uma mesma transao poderia executar repetidas vezes no ambiente remoto. Focalizando o problema de falhas sob o ponto de vista dos objetos envolvidos, pode-se caracteriz-los como objetos volteis, estveis ou reais. No primeiro grupo situam-se os objetos cujos valores no sobrevivem a falhas primrias. O exemplo tpico dado pelos objetos que residem na memria primria do sistema. No grupo intermedirio esto todos os objetos cujos valores sobrevivem a falhas primrias mas no a falhas secundrias. Aqueles objetos residindo em memria secundria imediatamente disponvel classificam-se como tal. Finalmente, no terceiro e ltimo grupo so encontrados objetos cujos valores, uma vez modificados, escapam ao controle do SGBD. Numa transao envolvendo um caixa bancrio automtico, uma vez dispensando um certo nmero de cruzeiros, estes cruzeiros existem e esto fora do alcance do SGBD. A prxima subseo abordar, de forma simplificada, os mecanismos usados para garantir o controle de integridade do BD enquanto que o Captulo 9 detalhar as estruturas e algortmos usados nos mtodos mais importantes para efetivar esta funo. 6.3.2 Proteo Contra Falhas Como foi visto na subseco anterior, os mais variados tipos de falhas podem se abater sobre o BD, cobrindo todo um espectro que vai desde situaes amenas e imediatamente contornveis at catstrofes que deixam marcas irrecuperveis, destruindo dados e procedimentos do sistema. O problema agravado pela imprevisibilidade das falhas e, ainda, - 11 -

pelo fato de que novos desarranjos podem advir enquanto o SGBD est se recuperando de outros anteriores, caracterizando mltiplas falhas simultneas. importante notar, desde j, que no h proteo total e cabal contra todas as falhas que eventualmente podem vir a perturbar o sistema. O que os mecanismos de proteo visam tornar o SGBD mais e mais confivel e seguro a medida que se tornam mais sofisticados. No entanto, casos patolgicos sempre podero ser imaginados de tal forma que no possam ser tratados a contento pelos mecanismos de proteo. No deve ser esquecido, tambm, o aspecto da eficincia do SGBD como um todo. Dispor de um sistema extremamente seguro e confivel, porm a um custo absurdamente alto, inviabiliza o prprio SGBD, na medida em que no ser posto em operao devido a sua impraticabilidade. Todo o desafio est em se imaginar tcnicas, estruturas e procedimentos que dem proteo razoavelmente eficaz contra as falhas mais observadas na prtica e que sejam, por outro lado, suficientemete expeditos de modo a no causar impacto por demais negativo nas atividades do usurio. Os vrios mecanismos de proteo podem tambm ser dicotomizados segundo propiciem ou no certa robustez contra falhas. Muitos mecanismos provem simplesmente proteo aos dados e procedimentos do SGBD, isto , ao ocorrer uma falha, o SGBD impede a utilizao do BD enquanto aciona os mecanismos de proteo de que dispe na tentativa de restaurar um estado consistente quando, ento, permite novamente que usurios continuem seu trabalho. Outros mtodos detetam a ocorrncia de certos tipos de falhas e, de forma transparente ao usurio, ativam mecanismos corretores os quais reparam os eventuais danos causados, propiciando uma certa robustez a estes tipos de falhas. Na presente subseco sero abordados, a nvel descritivo, os mtodos mais importantes para controle de integridade. Alguns so de concepo muito simples e dispensam maiores comentrios. Outros, mais sofisticados, sero detalhados no Captulo 9. Dada a pletora de mtodos hoje desenvolvidos, a classificao abaixo um tanto arbitrria e algumas das tcnicas poderiam ser reagrupadas de formas diferentes. Mais ainda, muitos dos mtodos s garantem a integridade do BD contra certos tipos de falhas. comum, portanto, que o SGBD disponha de vrias estratgias a seu alcance e procure us-las de forma orquestrada visando cobrir um amplo espectro de falhas. Tambm, controlar vrios mtodos distintos permite ao SGBD criar um certo sinergismo ao explorar particularidades dos mtodos e, assim, torn-los mais eficientes e eficazes do que se operados individualmente. Programas Restauradores Uma das primeiras estratgias que vem a mente incorpora o conceito de um programa restaurador. Estes programas simplesmente revem todos os dados do BD aps a ocorrncia de um desarranjo e tentam salvar o que for possvel. Arquivos podem ser perdidos no processo se o algoritmo decidir que no pode recuper-los. O programa tenta, entretanto, deixar o BD em um estado consistente, embora no completo, no sentido de que os dados sobreviventes satisfazem os requisitos de consistncia do BD enquanto no h garantias de que parte dos dados no sejam eliminados. A situao tpica quando programs restauradores so ativados se d em SGBDs onde os algortmos empregados em operao normal no garantem a consistncia dos dados na memria secundria ativa, a cada instante. Se o SGBD acometido por uma falha primria quando est justamente no processo de transferir dados da memria principal para a memria secundria ativa o contedo da primeira destrudo, impedindo que a operao seja

- 12 -

completada. Neste ponto, a memria secundria ativa, ainda no tendo sido completamente atualizada, representa um estado inconsistente do BD. O programa restaurador vai, ento, examinar os arquivos da memria secundria ativa e tentar, de alguma forma, torn-los consistentes. fcil de imaginar situaes onde os dados da memria principal, destrudos quando da ocorrncia da falha, sejam de tal forma crticos que a nica alternativa seria o programa restaurador eliminar parte dos dados residentes na memria secundria ativa a fim de trazer todo o DB a um estado consistente. Programas restauradores normalmente entram em ao como um ltimo recurso ou na ausncia de mecanismos apropriados para contornar certos tipos de falhas. Embora seja um mecanismo primitivo de controle de integridade, o programa restaurador pode se tornar atraente em BDs simples que implementem estruturas pouco sofisticadas. Isto tanto mais verdade quando os dados que possam eventualmente vir a serem perdidos estiverem disponveis em outras formas, de tal modo que as operaes possam ser rapidamente refeitas, recuperando todo ou boa parte do que o programa restaurador no conseguiu salvar. Uma descrio mais detalhada destes programas dependeria fortemente da particular concepo de cada BD e, por isto, no ser tentada neste texto. H, porm, sistemas reais que se valem deste recurso em maior ou menor extenso. O leitor encontrar exemplos de tais sistemas na Figura 6.2 e nas notas bibliograficas no final do captulo. Descargas Aqui, novamente, a idia bsica bastante simples. Periodicamente, o contedo de toda a memria secundria ativa descarregado (evitando o anglicismo "dumped") para outros dispositivos ativos, geralmente fitas magnticas, que so em seguida arquivadas como memria secundria dormente. Ocorrendo uma falha secundria, e outros mecanismos de restaurao mais eficientes no operando a contento, o SGBD sempre pode apelar para esta cpia arquivada e retornar a um estado consistente, anterior, do BD. Apenas falhas tercirias podem afetar as cpias arquivadas. Note que se estas se constituem nos nicos objetos de que se pode valer o SGBD para voltar normalidade, ento todas as transaes invocadas desde o incio da descarga e o momento de ocorrncia das falhas sero perdidas. Nenhum trao de sua existncia, mesmo daquelas que foram confirmadas, ser notado aps a recuperao do sistema. Em muitos casos, isto pode ser intolervel. Mtodos apoiados em descargas do BD so, portanto, candidatos naturais para se aliarem a outras estratgias que tentam remediar este defeito, mantendo algum tipo de registro das atividades que ocorrem no hiato entre a obteno de duas descargas consecutivas. Uma variao bvia consiste em se descarregar no todo o BD, mas apenas as partes do BD que tenham sido afetadas desde a ltima descarga. Este processo conhecido como descarga incremental. Descargas, como tcnica de controle de integridade isolada, no sero descritas em maiores detalhes. Entretanto, alguns mtodos mais sofisticados que empregam descargas, de uma forma ou outra, sero pormenorizados no Captulo 9, onde, ento, tornado explcito o papel desempenhado pelas descargas no mtodo como um todo. Note que a periodicidade com que as cpias so obtidas deve ser analisada com cuidado. Quanto mais freqentes, tanto mais eficazes sero no combate a falhas secundrias, visto que representam um estado mais recente do BD em relao ao momento de ocorrncia da falha. Por outro lado, maior freqncia implicar em maior degradao do tempo de resposta do sistema, especialmente se o BD for de porte avantajado. O ajuste final dever ser feito levando-se em conta quo susceptvel o sistema aos vrios tipos de falhas combatidas atravs destas tcnicas.

- 13 -

H duas maneiras principais de se obter descargas, segundo o SGBD interrompe ou no suas atividades normais enquanto a descarga obtida. Um mtodo vlido seria o SGBD determinar, num dado momento, que por ora no aceitaria novas transaes. Aps aguardar que todas as transaes iniciadas antes deste instante fossem completadas, o SGBD acionaria os procedimentos prprios para obter a descarga desejada. Em seguida, retornaria a operao normal aceitando novas transaes. Este processo ser rotulado de descarga esttica. Como alternativa, o prprio SGBD poderia eleger algumas das transaes correntes para serem canceladas, evitando esperar que completassem. No caso distribudo esta alternativa deve ser abordada com cautela, visto que cancelar transaes que migraram para outros ns pode onerar sobremaneira o sistema. A principal desvantagem est, claro, no fato do sistema se tornar indisponvel entre o incio e trmino da descarga. Em contrapatida, pagando-se em complexidade quanto aos algortmos usados, pode-se elaborar mecanismos que obtenham uma descarga dinmica do BD. A cpia obtida dinamicamente, com o sistema ainda disponvel, talvez com um tempo de resposta ligeiramente dilatado. Os algortmos devem garantir, entretanto, que o BD congelado em um dado instante T de tal modo que apenas transaes confirmadas antes de T tero seus efeitos refletidos na cpia obtida, enquanto que no deixado trao algum das demais. No Captulo 9 ambos estes mecanismos sero examinados em maiores detalhes, visto que integram outros mtodos de controle de integridade mais elaborados. Arquivos Diferenciais Esta tcnica adota a filosofia de coletar todas as modificaes efetuadas contra certas entidades do BD, em particular arquivos de dados, em estruturas prprias, especificamente planejadas para este fim, mantendo os valores dos objetos originalmente associados a estas entidades inalterados. Estas estruturas, onde as modificaes so agrupadas, recebero o cognome de arquivos diferenciais. Tudo se passa como se o SGBD, ao concentrar modificaes sobre os arquivos diferenciais, atrasasse o momento de tornar irreversvel o efeito de aes elementares sobre o BD, mesmo daquelas correspondentes a transaes que j foram confirmadas. A vantagem pretendida bvia. Os originais formam, naturalmente, uma cpia que reflete um estado completo e consistente anterior do BD. Ocorrendo uma falha que venha a prejudicar os arquivos diferenciais tudo que o SGBD tem a fazer reler da memria secundria ativa os originais intactos, eventualmente disperdiando os trabalho das ltimas transaes invocadas. Porm, se o usurio j foi informado de que derminada transao confirmou, ignor-la neste ponto pode bem ser inadmissvel. Para maior segurana, os originais e os respectivos arquivos diferenciais podem ser mantidos em dispositivos fsicos distintos. Descarregando os originais em memria secundria dormente protejer o BD contra quaisquer falhas secundrias. No entanto, em algum ponto no tempo, os arquivos diferenciais tero que ser usados para reconstruir os originais, processo este que pode ser oneroso. Mais ainda, ao acessar dados o SGBD deve pesquisar, antes, se os objetos desejados no se encontram nos arquivos diferenciais, incorrendo, assim, numa perda de eficincia. Duplicar os arquivos diferenciais em memria secundria ativa, em unidades fsicas diferentes, pode, portanto, degradar ainda mais o sistema a ponto de inviabilizar a idia na maioria dos casos. Alguns mecanismos engenhosos e tcnicas especiais usadas na organizao dos arquivos diferenciais permitem minimizar este problema. Note, em especial, que aes elementares que remodificam o valor de um objeto que j est no arquivo diferencial no necessitam de criar um novo registro para este particular objeto. Basta alterar o contedo do registro que l se encontra. Aes elementares cujo efeito seja a remoo de um objeto so igualmente simples de serem implementadas. A seu favor, este mtodo tem o fato de que facilita bastante a operao de - 14 -

obter-se descargas incrementais do contedo do BD pois basta descarregar os arquivos diferenciais os quais so, em princpio, bem menores que os originais. Atas Imagine um SGBD onde o conceito de transao permeia toda sua organizao, isto , transaes so as unidades bsicas de trabalho do sistema. Falhas, ocorrendo em momentos imprevisveis, colhero algumas transaes em andamento, porm ainda no completadas, isto , no confirmadas ou canceladas. Ao voltar a cena, o SGBD deve, portanto, desfazer todos os efeitos parciais registrados por cada transao que ainda no completou at o instante de ocorrncia da falha. Para que isto possa ser levado adiante, cada ao elementar deve registrar, em uma ata (em ingls "log" ou "audit trail"), os valores iniciais e finais de cada objeto modificado, bem como deixar claro em benefcio de que transao esta ao elementar foi invocada. Normalmente, a ata reside na memria secundria ativa. Ocorrendo uma falha primria, tudo que o SGBD precisa fazer consultar a ata e refazer transaes confirmadas cujo efeito ainda no tenha sido registrado na memria secundria ativa; desfazer transaes canceladas cujo efeito j foi registrado em memria secundria ativa; desfazer transaes que ainda estavam em andamento quando do instante de ocorrncia da falha.

Note que tambm deve ir para a ata um registro de incio e trmino para cada transao executada. Assim, os mecanismos de controle de integridade do SGBD teriam condies de identificar todas as transaes em andamento a cada instante, bem como no teriam dificuldades em agrupar e associar aes elementares que correspondam a uma mesma transao. A prpria ordem seqencial em que aparecem os registros de aes elementares na ata se presta muito bem a refazer/desfazer transaes. Observe que atas devem residir em memria secundria ativa, visto serem estruturas muito solicitadas uma vez que a invocao de cada ao elementar deixa l um registro. J uma falha que destrua parte da memria secundria ativa, afetando segmentos da ata, provocaria uma catstrofe no sistema. Transaes confirmadas cujos efeitos no foram ainda registrados sobre os respectivos objetos simplesmente desapareceriam, uma vez ser a ata o nico registro destas transaes capaz de fornecer informaes suficientes para que sejam refeitas. Atas propiciam um meio de se restaurar o BD ao estado completo mais recente com relao ao ponto de ocorrncia da falha. A se manter este requisito, o dilema est em se imaginar estruturas eficazes que o satisfaam, mesmo na presena de falhas secundrias que podem destruir parte da ata. Uma alternativa duplicar a ata em memria secundria ativa de tal modo que as duas "cpias" residam em dispositivos fsicos distintos. Como estamos supondo que a ocorrncia de falhas so eventos independentes, isto minimizaria as chances de que partes da ata sejam perdidas. O preo, claro, seria comprometer o tempo de resposta ainda mais. Em princpio, pode-se tornar o mecanismo to confivel quanto se queira atravs da duplicao, triplicao, etc., da ata em unidades distintas. Um problema mais sutil diz respeito ao sincronismo entre a entrada de registros na ata e a alterao de valores de objetos na memria secundria ativa. Um bom procedimento seria adotar um protocolo para uso da ata que garantisse a catalogao de cada ao elementar antes de registrar seus efeitos em memria secundria ativa. Para apreciar que tipo de problemas podem surgir, considere a seqncia de passos abaixo, usualmente seguidos pelo - 15 -

SGBD ao manipular objetos do BD local: 1. determina se a pgina onde reside o objeto em questo est presente na memria principal; 2. se no estiver, aciona o sistema operacional local para que este leia a pgina necessria da memria secundria ativa para a memria principal; 3. perfaz as alteraes desejadas no valor do objeto, reconstruindo a pgina em que este reside, na memria principal; 4. torna a acionar o sistema operacional local para que este reescreva a pgina atualizada da memria principal para a memria secundria ativa, quando ento as modificaes se tornam permanentes; 5. registra a ocorrncia desta ao elementar na ata, alm de associ-la transao correspondente. Suponha que uma falha colha o sistema no hiato entre os passos 4 e 5 da seqncia acima. Neste caso, a situao se tornaria confusa pois o SGBD no teria condies de inverter a ao elementar que alterou o contedo desta pgina, dado que no haveria registro algum de sua invocao. Observe que, se tomada isoladamente, a ata teria que registrar todas as aes elementares efetuadas contra o BD desde que este foi criado. Esta situao remediada com o emprego de descargas. A ltima descarga obtida seria revivida e, ao se ler a ata, todas as transaes que porventura completaram antes da descarga ter sido iniciada poderiam ser ignoradas. As demais seriam refeitas ou desfeitas, de acordo com a respectiva situao no instante de ocorrncia da falha. Como pode ser visto, descargas complementam naturalmente tcnicas de controle de integridade que operam atravs de atas. Neste caso especfico, descargas sero conhecidas por balizadores (do termo em ingls "checkpoints"). Uma vez sabendo-se que as descargas operaro em estreita cooperao com as atas, possvel otimizar o tempo de resposta quando as primeiras esto sendo obtidas, dispensando-se certas informaes redundantes. Na realidade, a situao um pouco mais complexa do que pode deixar transparecer a discusso acima. Detalhes do mecanismo sero examinados no Captulo 9. Imagens Transientes Imagine que o BD seja composto por um certo nmero de pginas de tamanho fixo e que a memria secundria est dividida em setores do mesmo tamanho que as pginas. Conforme j foi ressaltado anteriormente, aes elementares manipulam objetos do BD, que sero identificados, para propsito desta discusso, com as pginas de memria. Uma transao modificaria, possivelmente, um certo nmero destas pginas, caso confirmada. claro que quaisquer alteraes na memria secundria ativa s podem ser efetivadas se a pgina for construda na memria principal e, posteriormente, reescrita em memria secundria ativa. Quando a pgina modificada repassada para a memria secundria ativa, porm, tem-se duas alternativas:

- 16 -

1. reescrever a pgina reconstruda sobre o setor que ocupava inicialmente, destruindo, por conseguinte, seu contedo original; 2. reescrever a nova pgina sobre um setor livre em memria secundria ativa, mantendo seu contedo original inalterado. As tcnicas de controle de integridade examinadas at o momento operavam na hiptese de que o SGBD adotava o mecanismo do item 1 acima. Idias que exploram a metodologia do item 2 seguem o esquema geral abaixo. Ao modificar a pgina proceda da seguinte forma: 1. leia a pgina i da memria secundria ativa para a memria principal, caso esta l ainda no se encontre; seja k o endereo desta pgina na memria principal; 2. modifique, na memria principal, valores de dados residentes nesta pgina; 3. encontre um setor livre, seja s, na memria secundria ativa; 4. reescreva a pgina i na memria principal sobre o setor de endereo s na memria secundria ativa; 5. altere o diretrio de pginas, indicando que a pgina i se encontra agora no setor s; 6. libere o setor ocupado originalmente pela pgina i. Visto de um certo ngulo, estas tcnicas criam uma imagem transiente com as modificaes desejadas, enquanto mantm a imagem certificada inalterada. Contrastando com a tcnica de arquivos diferenciais, porm, as imagens transientes so efmeras, substituindo, imediatamente aps escritas na memria secundria ativa, as imagens originais a partir das quais foram criadas. Obviamente, no caso do sistema sofrer uma falha primria durante a execuo dos passos acima, as imagens originais estariam ainda intactas, alm de representarem um estado consistente recente do BD. Sero descritas duas maneiras de se implementar os mecanismos de imagens transientes: atravs de vetores de ponteiros e atravs de listas de intenes. No esquema de vetor de ponteiros o BD suposto formado por um conjunto de segmentos divididos em pginas. O i-simo segmento dispe de um vetor de ponteiros, Vi , que d os setores que contm as suas pginas. Afora estes vetores, o mecanismo usa 2 vetores de "bits". Em um deles, MAP, o i-simo "bit" representa a situao do i-simo setor da memria secundria: 1 equivale a ocupado e 0 a livre. No outro vetor, EST, o j-simo "bit" indica a situao do i-simo segmento: 1 se h transaes manipulando pginas deste segmento e 0 em caso contrrio. Alterar a j-sima pgina do i-simo segmento corresponde a verificar se o i-simo segmento j est sendo manipulado, consultando o "bit" EST(i); se no, copiar o diretrio do i-simo segmento em outro vetor, V'i , em memria secundria; se preciso, trazer o setor de endereo Vi (j) = s para a memria principal; efetuar as modificaes desejadas na pgina residente na memria principal; procurar um setor livre na memria secundria ativa, consultando o vetor MAP. Seja s' o endereo do setor encontrado; - 17 -

reescrever a pgina modificada, na memria principal, para o setor de endereo s', na memria secundria ativa; preparar o setor de endereo s' para substituir o original, no endereo Vi(j), intercambiando os valores de Vi (j) e s' ; por motivo de segurana, copiar o vetor MAP para outro vetor, MAP'; efetivar as alteraes mudando MAP(s) para 0 e MAP(s') para 1;

Observe que, nos passos 2 e 8, so tomadas precaues para que, em caso de falha, o SGBD possa restaurar seu estado anterior simplesmente copiando os vetores MAP' e V'i sobre os vetores MAP e Vi, respectivamente. Uma variao deste primeiro esquema ser discutida em detalhe na Seo 9.2. No segundo esquema, o processo ligeiramente diferente. Suponha que cada arquivo Q do banco esteja dividido em pginas e que o banco possua um diretrio D indicando que setores contm as pginas de Q. Uma transao, T, prossegue normalmente, alterando pginas de acordo com o mesmo princpio de criar imagens transientes destas pginas. Suponha que a transao manipulou dados e que, para isto, alterou pginas de Q com endereos P1 ,, Pn. O endereo do setor contendo a imagem original da pgina Pk ik e o endereo do setor contendo a imagem transiente de Pk jk . Para finalizar, deve-se executar as aes Ak = D(k) := jk , representando as operaes de atribuio necessrias atualizao de D. A lista de aes L = (A1 ,, An ) chamada de lista de intenes para T. Esquematicamante, T executa de acordo com o plano abaixo. 1) Na fase de execuo a) T invoca cada uma de suas aes elementares, criando imagens transientes de P1 ,,Pn b) T cria, no processo, a lista de intenes L 2) Na fase de confirmao a) T escreve L em memria secundria ativa b) T executa L c) Libera o espao ocupado por L em memria secundria ativa. Portanto, se falhas primrias ocorrerem antes do passo 2, T simplesmente ignorada quando o SGBD, ao retornar vida, se depara com o diretrio D inalterado em relao ao estado anterior. Aps o passo 2a, T ser confirmada e falhas primrias no podem alterar este fato. Uma propriedade muito desejvel est, obviamente, embutida no mecanismo: repetidas execues de L, mesmo parciais, surtiro efeito equivalente a uma nica execuo de L. Isto assegura que, se o sistema for acometido por uma falha primria enquanto ainda est se recuperando de outra anterior, a transao ser, sempre, corretamente confirmada. O caso de um BD distribudo apresenta complicaes caractersticas. Um determinado n deve substituir as imagens certificadas pelas transientes ou, conforme o caso, executar a lista de intenes de uma transao, se e somente se todos os demais ns que atuaram em - 18 -

benefcio da transao atingirem um concenso neste sentido. Aqui poder-se-ia usar o protocolo bifsico para se atingir um entendimento entre os ns participantes. Muitas variaes podem ser construdas usando-se as mesmas idias bsicas. Por exemplo, manter-se duas cpias de cada arquivo do BD a cada instante, uma delas servindo de reserva caso a outra seja danificada por falhas. Modificaes seriam refletidas em ambas as cpias imediatamete aps cada ao elementar executada. Para evitar inconsistncias por ocasio de eventuais falhas, cada cpia disporia de um "bit" cuja funo seria indicar que a operao de atualizao est em progresso sobre a respectiva cpia, evitando que esta fosse usada como a cpia de reserva a ser usada quando o SGBD se recuperasse de falhas. Assumindo que este "bit" sempre resiste a todos os tipos de falhas que se pretende contornar com este mecanismo, o SGBD sempre resgataria um estado consistente anterior quando voltasse operao normal aps uma falha. Esta e outras variaes possveis no sero discutidas em maiores detalhes no texto que segue.

6.3 CONTROLE DE CONCORRNCIA

Um SGBD, suportando bancos de dados com vrias aplicaes, dever necessariamente permitir acesso concorrente aos dados. intuitivo que, em tese, quanto maior for o nvel de concorrncia permitido, tanto melhor ser o tempo de resposta do sistema como um todo. Em tese porque, forosamente, os mecanismos que controlam o acesso concorrente ao banco impem um nus adicional sobre o desempenho do SGBD. Os procedimentos que harmonizam o paralelismo no seio do SGBD sero conhecidos por mecanismos de controle de concorrncia. Num cenrio de BDs distribudos, ou mesmo de BDs centralizados com acesso distribudo, a implementao de paralelismo torna-se uma necessidade imperiosa. Com relao ao caso centralizado, hoje so conhecidas tcnicas que equacionam os problemas a contento, apoiadas em um tratamento terico preciso e confirmadas por implementaes reais. No que concerne ao caso distribudo, a situao mais confusa. Isto devido, em grande parte, ao fato de que os ns da rede operam de forma bastante independente, embora o controle de concorrncia deva ser efetivado de forma global, abrangendo informao que pode estar espalhada por vrios ns. Aqui, muitos dos aspectos do problema ainda se encontram em fase de pesquisa e experimentao. Nesta seo sero apresentados os problemas fundamentais a respeito de controle de concorrncia bem como sero descritos, de forma suscinta, alguns algortmos usados para solucion-los. No Captulo 8 estas questes sero examinadas em profundidade. No que tange ao restante desta seo, ser suposto que o sistema nunca falha, a no ser quando explicitamente dito em contrrio. Equivalentemente, suficiente supor que as tcnicas para controle de integridade, expostas na seo anterior, sejam adequadas para contornar eventuais falhas de maneira satisfatria e transparente. Na realidade, claro, ambos os mecanismos devem operar de forma integrada. A hiptese acima colocada simplesmente para isolar os problemas. 6.3.1 Colocao do Problema Quando transaes manipulam dados concorrentemente, certos problemas, chamados de anomalias de sincronizao, podero ocorrer. Exemplos so acessos a dados inconsistentes, perdas de atualizaes e perda da consistncia do banco. Por exemplo, considere duas

- 19 -

transaes, T1 e T2, ambas debitando uma determinada quantia a um saldo S. Seja a seqncia de aes: 1) T1 l o saldo S; 2) T2 l o saldo S; 3) T2 debita a quantia, escrevendo o novo valor de S; 4) T1 debita a quantia, escrevendo o novo valor de S; O valor final do saldo neste caso refletir apenas a quantia debitada por T1, sendo a atualizao submetida por T2 perdida. O exemplo acima tambm serve para ilustrar porque controle de concorrncia, embora semelhante, no equivalente ao dilema de gerenciar acesso a recursos partilhados em um sistema operacional. De fato, na seqncia acima, cada transao respeita o princpio de acesso exclusivo ao objeto partilhado S. Porm, isto claramente no suficiente pois uma atualizao perdida. Assim sendo, um mecanismo de controle de concorrncia no dever se limitar a implementar acesso exclusivo a objetos do banco de dados. O problema fundamental a ser resolvido pelos mtodos de controle de concorrncia colocado da seguinte forma. Assuma que todas as transaes preservam a consistncia lgica do banco de dados e terminam, quando executadas seqencialmente. Um mtodo de controle de concorrncia dever, ento, garantir que em toda execuo concorrente das transaes: 1) cada transao termina; 2) cada transao executada sem interferncia das outras, e sem que anomalias de sincronizao ocorram. Estes objetivos devero ser atingidos permitindo-se um mximo de concorrncia possvel, de forma transparente para os usurios, e para qualquer conjunto de transaes acessando qualquer parte do banco de dados. Note que o controle de concorrncia e a gerncia de transaes so tarefas que se complementam. Cabe ao gerente de transaes escalonar as aes de uma transao de tal forma que esta seja processada corretamente, conforme a especificao do usurio. Por outro lado, cabe ao mecanismo de controle de concorrncia arbitrar a intercalao das aes de transaes diferentes de tal forma a que todas as transaes terminem, sejam processadas sem que uma interfira com a outra e sem que anomalias de sincronizao ocorram. O resto desta subseo abordar em mais detalhe o critrio de correo imposto aos mecanismos de controle de concorrncia. A idia do critrio de correo comumente aceito bem simples. Seja T um conjunto de transaes. Inicialmente observa-se que uma execuo seqencial ou serial das transaes em T, ou seja, uma execuo em que as transaes so processadas uma aps a outra terminar, em uma ordem qualquer, necessariamente correta. Isto fcil ver pois em uma execuo serial no h processamento concorrente. O prximo passo postular que uma execuo concorrente E das transaes em T ser considerada correta se for computacionalmente equivalente a alguma execuo serial das transaes. A execuo E ser chamada neste caso de serializvel. A noo de equivalncia - 20 -

computacional usada aqui exige que o estado final do banco de dados seja o mesmo em E e S e que as transaes leiam os mesmos dados em E e S (assumindo que E e S comeam no mesmo estado inicial do banco de dados) e, portanto, executem a mesma computao em E e S. A postulao deste critrio de correo para execues concorrentes justificada pois, como S serial, as transaes em T so naturalmente executadas sem que uma interfira com a outra. fcil justificar que anomalias de sincronizao no ocorrem em S. Como E computacionalmente equivalente a S, as transaes so executadas em E sem que uma interfira com a outra e sem que anomalias de sincronizao ocorram. Os prximos exemplos ilustraro estes conceitos. Suponha que P e C representem os saldos da poupana e da conta corrente de um determinado cliente (armazenadas em um banco de dados centralizado, por simplicidade). Considere duas transaes cujos efeitos desejados so: T1: T2: se houver saldo suficiente na poupana, transfira $5.000,00 da poupana para a conta corrente; se houver saldo suficiente na conta corrente, debite um cheque de $10.000,00.

Suponha que a seqncia de aes elementares sobre o banco de dados gerada pela execuo da transao T1 (supondo que haja saldo suficiente) seja: T11: leia o saldo P para X; X := X - 5.000; T12: leia o saldo C para Y; Y := Y + 5.000; T13: T14: escreva o novo saldo Y em C; escreva o novo saldo X em P.

Apenas aquelas aes que acessam o banco de dados receberam rtulos pois so estas que nos interessaro a seguir. Suponha que a seqncia de aes elementares sobre o banco de dados gerada pela execuo da transao T2 (supondo que haja saldo suficiente) por sua vez seja: T21: leia o saldo C para Z; Z := Z - 10.000; T22: escreva o novo saldo Z em C.

Primeiro considere uma execuo puramente serial em que T2 processada antes de T1. Esta execuo pode ser abstrada pela seguinte seqncia de rtulos das operaes sobre o banco de dados: S = T21 T22 T11 T12 T13 T14 Considere agora uma execuo concorrente abstrada pela seguinte seqncia de rtulos: L = T11 T21 T22 T12 T13 T14 - 21 -

Esta execuo L no serial, porm serializvel por ser equivalente a S. Isto fcil de ver pois a ao T11 em L pode ser comutada com T21 e T22 sem que o resultado do processamento de T1 seja alterado e sem que o estado final do banco de dados seja modificado. De fato, T11 l o saldo P enquanto as aes de T2 afetam apenas o saldo C. Logo, T11 l o mesmo saldo P em L e em S. Por fim, considere uma execuo concorrente abstrada pela seguinte seqncia de rtulos: N = T11 T12 T21 T22 T13 T14 Esta execuo N no serial e tambm no serializvel por no ser equivalente nem a S, nem a uma execuo serial S em que T1 processada antes de T2. De fato, T12 l o saldo inicial C, que posteriormente escrito por T13. Desta forma, a atualizao expressa por T2 perdida e o banco de dados final (em N) no reflete a execuo de T2. Logo N no pode ser equivalente S ou S, ou seja, no serializvel. 6.3.2 Mtodos de Controle de Concorrncia Nesta subseo sero discutidos dois dos principais mtodos usados para implementar controle de concorrncia. O primeiro dos mtodos a ser discutido utiliza bloqueio aos dados para garantir que toda execuo concorrente serializvel. J o segundo mtodo impe uma ordenao "a priori" s transaes e garante que toda execuo concorrente equivalente execuo serial das transaes na ordem imposta. Mtodos baseados em Bloqueios Uma parte dos problemas levantados na seo anterior residia no fato de que os estados intermedirios gerados por uma transao eram visveis s outras transaes. A idia bsica dos mtodos de bloqueio consiste simplesmente em impedir que tais estados se tornem visveis bloqueando o acesso a eles. A soluo no to imediata como parece, no entanto. H dois aspectos envolvidos no uso de mtodos de bloqueio que precisam ser equacionados: como usar bloqueios para atingir apenas execues serializveis, e como gerenciar o bloqueio aos dados. Deve ficar claro, neste ponto, que apenas usar bloqueios para gerenciar o acesso aos objetos partilhados no suficiente para criar um controle de concorrncia correto. Por exemplo, considere o seguinte protocolo de bloqueio: 1) antes de ler ou atualizar em um objeto, este deve ser bloqueado; 2) aps a leitura ou atualizao, o objeto poder ser liberado. Este protocolo obviamente incorreto, pois permite gerar, por exemplo, a execuo N apresentada no final da seo anterior, que no serializvel. O protocolo de bloqueios mais comumente usado para garantir serializao chamado de bloqueio em duas fases e dita o seguinte: 1) uma transao deve sempre bloquear os objetos antes de acess-los, e eventualmente liber-los antes do seu trmino; 2) depois de liberar o primeiro objeto, uma transao no poder bloquear novos objetos.

- 22 -

Este protocolo assim chamado pois, pela segunda regra, cada transao passa por duas fases: em uma primeira fase objetos so apenas bloqueados e em uma segunda fase objetos so apenas liberados. O protocolo pode ser implementado tanto para um banco de dados centralizado quanto para um banco distribudo, conforme ser visto no Captulo 8. Podemos provar que toda execuo concorrente permitida pelo protocolo de bloqueio em duas fases serializvel usando o seguinte raciocnio. Seja E uma execuo concorrente de um grupo T de transaes. Suponha que todas as transaes em T terminam em E e que seguiram o protocolo de bloqueio em duas fases em E. O ponto em que cada transao Ti libera o primeiro objeto em E chamado de ponto de bloqueio de Ti . Considere a execuo serial S em que as transaes so processadas na ordem dos pontos de bloqueio em E. Teremos ento que S e E sero equivalentes pois, dado o uso de bloqueios, possvel comutar a ordem das operaes em E para que se transforme em S sem alterar a computao das transaes ou o estado final do banco de dados. Logo, E serializvel. A guisa de exemplo, considere novamente as transaes T1 e T2 da seo anterior acessando um banco de dados centralizado. Considere agora que elas bloqueiam explicitamente os dados seguindo a poltica do protocolo de bloqueio em duas fases. Suponha que a seqncia de aes elementares sobre o banco de dados, incluindo as aes de bloqueio e liberao, gerada pela execuo da transao T1 (supondo que haja saldo suficiente) seja: B11: T11: bloqueie o saldo P para T1 leia o saldo P para X X := X - 5.000 B12: T12: bloqueie o saldo C para T1 leia o saldo C para Y Y := Y + 5.000 T13: L11: T14: L12: escreva o novo saldo Y em C libere o saldo C escreva o novo saldo X em P libere o saldo P

Suponha que a seqncia de aes elementares sobre o banco de dados gerada pela execuo da transao T2 (supondo que haja saldo suficiente) por sua vez seja: B21: T21: bloqueie o saldo C para T2 leia o saldo C para Z Z := Z - 10.000 T22: L21: escreva o novo saldo Z em C libere o saldo C

- 23 -

A execuo concorrente, abstrada pela seguinte seqncia de rtulos, seria permitida pelo protocolo de bloqueios: L = B11 T11 B21 T21 T22 L21 B12 T12 T13 L11 T14 L12 Esta execuo serializvel conforme discutido na seo anterior. Isto pode ser visto de outra forma, ilustrando o raciocnio da prova de correo do protocolo de bloqueio em duas fases. O bloqueio de P para T1 desde B11 at L12 implica em que nenhuma ao de T2 ou qualquer outra transao pode acessar P durante este perodo, pois a transao em questo teria que bloquear tambm P, o que no permitido. Isto garante que as aes T21 e T22 no afetam o valor de P lido por T11. Logo T11 pode ser comutado com estas aes sem que o processamento de T1 em E se altere. Neste caso particular, esta observao basta para mostrar que, assim sendo, E equivalente seguinte execuo serial (obtida comutando-se &T11. com &T21. e &T22. em E): S = B21 T21 T22 L21 B11 T11 B12 T12 T13 L11 T14 L12 Considere agora uma outra execuo concorrente, abstrada pela seguinte seqncia de operaes: N = B11 T11 B12 T12 ( B21 O protocolo de bloqueios no permitiria que B21 fosse executada no ponto indicado pois o saldo C est bloqueado para a transao T1. A transao T2 espera ento pela liberao de C, sendo que a execuo poderia prosseguir da seguinte forma, por exemplo: N = B11 T11 B12 T12 T13 L11 B21 T21 T22 L21 T14 L12 Note que esta segunda execuo tambm serializvel. No exemplo acima, o bloqueio aos dados foi incorporado as transaes de tal forma a seguir a tcnica de duas fases. No entanto, o protocolo de bloqueio em duas fases pode ser implementado de forma transparente aos usurios, conforme discutido no Captulo 8. A mais imediata destas implementaes em um ambiente distribudo segue a seguinte idia: 1) quando uma consulta enviada para ler dados de um banco local, os dados so bloqueados automaticamente antes de execut-la; 2) quando uma mensagem PREPARE_SE recebida na primeira fase do protocolo bifsico, os dados que sero modificados so bloqueados, aqueles que foram apenas lidos podendo ser liberados, antes do n responder a mensagem; 3) aps as atualizaes terem sido instaladas no banco, caso o n receba uma mensagem CONFIRME, ou aps o n ter recebido uma mensagem CANCELE, os dados atualizados localmente so liberados. Na discusso sobre o protocolo de bloqueio em duas fases assumiu-se que todas as transaes terminam. O uso de bloqueios por si s no garante esta propriedade. De fato, um impasse criado sempre que uma seqncia de transaes T1 ,, Tn , T1, onde Ti espera por Ti+1 , formada. Esta situao ser chamada de bloqueio mtuo. Mecanismos adicionais devero existir para detetar e resolver bloqueios mtuos. O mtodo de resoluo usualmente empregado consiste em reiniciar a transao na seqncia de impasse que consumiu menos recursos at o momento. Em um banco de dados distribudo, deteo de bloqueios mtuos

- 24 -

especialmente difcil pois poder ser necessrio levantar quais transaes esperam por quais transaes ao longo de vrios ns. Ou seja, a seqncia de impasse poder se estender ao longo de vrios ns da rede. Quanto a gerncia dos bloqueios em si, apenas mencionaremos aqui que, na realidade, so h necessidade de bloquear o acesso concomitante a um objeto quando se est modificando seu valor. Posto de outra forma, no h inconveniente em que vrias transaes leiam o valor de um objeto sem bloque-lo. Isto porque a operao de leitura no muda o estado do banco de dados. Os problemas aparecem quando uma transao atualiza o valor de um objeto e outra l/atualiza o mesmo objeto, quando ento o estado do banco de dados modificado. Esta alterao, se tornada visvel intempestivamente, levaria a inconsistncias. Uma maneira de concretizar a idia seria postular-se diferentes modos de bloqueios: modo partilhado e modo exclusivo. Vrias transaes distintas poderiam bloquear um objeto em modo partilhado, desde que nenhuma destas transaes fosse atualizar o valor do respectivo objeto. Apenas uma transao poderia bloquear um objeto em modo exclusivo. Neste caso, a transao pretenderia modificar o valor do objeto. O protocolo de bloqueio/liberao de objetos teria, claro, que ser modificado para refletir esta nova mecnica. Mtodos de Pr-Ordenao O protocolo de bloqueio discutido na seo anterior garante que toda execuo E de um conjunto T de transaes serializvel. Mais ainda, sabemos que a ordem de serializao dada pela ordem em que os pontos de bloqueio foram atingidos em E. Ou seja, os usurios tm a iluso de que as transaes executaram seqencialmente na ordem dos pontos de bloqueio. Porm, esta ordem determinada "a posteriori", durante a execuo das transaes e reflete um entrelaamento arbitrrio das aes elementares destas transaes. No determinada por nenhum fator sobre o qual o usurio tenha controle direto. Uma transao Ti poder ser iniciada antes de outra Tj mas em E tudo se passa como se Tj tivesse sido executada antes de Ti. Basta para isto que o ponto de bloqueio de Tj tenha sido atingido antes do ponto de bloqueio de Ti em E. O mtodo de pr-ordenao, como o nome indica, tem um comportamento diametralmente oposto. Uma ordem inicial dada s transaes, digamos de acordo com o instante em que foram iniciadas. As transaes so processadas concorrentemente, mas o controle de concorrncia garante que a execuo final equivalente execuo seqencial das transaes na ordem imposta "a priori". Mais precisamente, o protocolo de pr-ordenao para um banco de dados distribudo dita o seguinte: 1) As transaes, quando so submetidas, recebem uma senha ou nmero de protocolo, nico em toda a rede, dado pelo gerente de transaes do n onde foram submetidas; 2) As aes de uma transao herdam a sua senha; 3) Localmente, em cada n onde uma parte do banco est armazenada, duas aes de transaes diferentes so processadas em ordem de senhas, exceto se a sua ordem relativa puder ser invertida sem afetar a computao (isto , se as aes no conflitam). 4) Se uma ao violar a condio do item anterior, rejeitada e a transao correspondente reiniciada com outra senha. - 25 -

A correo deste protocolo imediata. Seja E uma execuo concorrente de um grupo T de transaes. Suponha que todas as transaes terminem em T e que o protocolo de prordenao tenha sido seguido. Considere a execuo serial S em que as transaes so processadas na ordem de senha. Teremos, ento, que S e E sero equivalentes pois, como as aes locais que no podem ser comutadas foram executadas em ordem de senha, possvel comutar a ordem das outras operaes em E para que se transforme em S sem alterar a computao das transaes ou o estado final do banco de dados. Logo, E serializvel. Considere, novamente, as transaes T1 e T2 das sees anteriores supostas acessando contas em um banco de dados centralizado, por simplicidade. A seqncia de aes de T1 ento considerada repetida aqui para facilitar referncias: T11: T12: T13: T14: leia o saldo P para X X := X - 5.000 leia o saldo C para Y Y := Y + 5.000 escreva o novo saldo X em P escreva o novo saldo Y em C

A seqncia de aes de T2, por sua vez, ser: T21: leia o saldo C para Z Z := Z - 10.000 T22: escreva o novo saldo Z em C Suponha agora que T1 e T2 receberam senhas s1 e s2 tais que s1<s2. Estas senhas so repassadas para as aes de T1 e T2. Considere uma execuo concorrente de T1 e T2 representada pela seguinte seqncia de aes: L = T11 T12 T13 T21 T22 T14 Esta seqncia seria aceita como est pelo protocolo de pr-ordenao. De fato, acompanhando a dinmica do processamento, teramos: T11 submetida para o protocolo e aceita, j que nenhuma outra ao foi executada. T12 e T13 so submetidas e aceitas pois so da mesma transao que T11 T21 submetida. Como T21 l o saldo C e T13 escreve neste saldo, a ordem relativa de T13 e T21 no pode ser invertida sem alterar a computao. Logo estas operaes tero que ser processadas em ordem de senha. Mas a senha associada T21 maior do que a senha associada T13 (e T13 j foi processada). Logo T21 aceita. T22 aceita por motivos semelhantes. T14 submetida. A senha associada T14 menor do que a senha das duas ltimas aes processadas, T21 e T22. Porm, como T14 afeta o saldo P e T21 e T22 acessam o saldo C, a ordem relativa de T14 e T21 / T22 pode ser invertida sem que a computao seja alterada. Portanto, T14 aceita e processada. Considere agora uma seqncia diferente: N = T11 T12 T21 ( T13 - 26 -

A ao T13 necessariamente rejeitada pelo protocolo de pr-ordenao, provocando o reincio de T1. De fato, observe inicialmente que a ordem de T13 e T21 importante pois T21 l o saldo C e T13 cria um novo valor para C. Logo a ordem relativa de T13 e T21 no pode ser invertida sem afetar a computao. Assim, estas aes tm que ser processadas em ordem de senha, ou seja, T21 depois de T13, neste caso. Como na seqncia acima T21 j foi processada quando T13 recebida, esta ltima ao rejeitada, forando o reincio de T1 com um nmero de senha mais alto. Usando a notao O para indicar a ao que desfaz o efeito da operao O, a seqncia acima continuaria da seguinte forma, por exemplo: N = T11 T12 T21 T11 T12 T22 T11 T12 T13 T14 Diversas implementaes do protocolo de pr-ordenao, todas transparentes aos usurios, sero discutidas no Captulo 8. Faremos aqui apenas alguns comentrios sobre o problema de gerar senhas de forma unvoca e sobre o relacionamento do protocolo de pr-ordenao com o protocolo bifsico. Em bancos de dados centralizados senhas podem ser geradas de forma unvoca utilizando-se o prprio relgio do processador principal. Por outro lado, em um sistema distribudo, se os gerentes de transaes gerarem senhas desta forma, duas transaes podero potencialmente receber a mesma senha. Isto violaria o princpio de que cada senha deve estar associada a uma transao distinta. O dilema solucionado justapondo-se hora local a identidade do n onde a transao se origina, suposta nica para cada n da rede. Pode-se conseguir, assim, que transaoes distintas tenham senhas nicas em relao ao sistema como um todo. Quando o SGBDD faz uso do protocolo bifsico para confirmar intenes problemas aparecem com o protocolo de pr-ordenao. Note que, na fase dois daquele protocolo, os ns que participaram da execuo de uma transao no podero mais cancelar, unilateralmente, os efeitos locais desta transao e devero garantir que, quando a ordem do coordenador eventualmente chegar para que a transao seja confirmada, estejam preparados para tornar seus efeitos permanentes no banco de dados local. Este problema pode ser resolvido alterando-se o protocolo de pr-ordenao para que processe as aes de PREPARE_SE como se fossem as operaes que atualizam os dados. Uma vez que o n local emitiu uma mensagem de PREPARADO em resposta a uma mensagem PREPARE_SE, com senha S e indicando que um objeto X ser atualizado, nenhuma outra operao com senha maior do que s e que acesse X poder ser processada. Este problema seria solucionado, por exemplo, bloqueando-se X desde o processamento de PREPARE_SE at que a atualizao seja efetivada. Finalmente, necessrio examinar o problema de terminao. No contexto desta implementao, uma transao Ti poder no terminar se for reiniciada ciclicamente j que, a cada vez que uma de suas aes chegou "atrasada", por assim dizer, com relao outra ao com que conflita, a transao Ti reiniciada. Uma soluo para este problema consiste em reiniciar a transao Ti com uma nova senha bem maior do que a anterior para minimizar as chances de Ti ser novamente reiniciada. A poltica de aumento de senha ainda tem um outro fator determinante. Existe a possibilidade do processamento de vrias transaes sincronizar-se de tal forma a causar o reincio mtuo de todas elas. Ou seja, cria-se uma seqncia de transaes Ti0 , Ti1 ,, TI, m-1 , Ti0 tal que Tij fora o reincio de T i , j+1 (soma mdulo m). Se o aumento da senha for o mesmo para todas estas transaes, corre-se o risco de repetir-se a situao indefinidamente. Para se resolver - 27 -

este problema (probabilisticamente) basta randomizar o incremento dado as senhas. Este esquema simples naturalmente no evita completamente o problema de reincio cclico, mas o torna pouco provvel.

NOTAS BIBLIOGRFICAS
Lindsay [1980] contm uma descrio mais ou menos detalhada das fases de incio, migrao e trmino de transaes, especialmente desta ltima. A parte de trmino de transaes bem formulada. Tambm inclui uma boa descrio do mecanismo controle de integridade envolvendo atas e balizadores. Gray [1978] descreve algumas das estratgias usadas na implementao do Sistema R, desenvolvido no laboratrio de pesquisas da IBM, em San Jose. Descreve com algum detalhe o mecanismo de atas, bem como o protocolo bifsico. Gray et all. [1979] apresenta o mecanismo de recuperao do Sistema R. Lindsay et all. [1979] proporciona uma descrio detalhada do protocolo bifsico. Lorie [1977] apresenta um mtodo de imagens transientes. Severance e Lohman .1976] descrevem uma tcnica de arquivos diferenciais. Randell et all. [1978], Verhofstad [1978], Randell [1979] e Kohler [1981] contm tutoriais sobre controle de integridade. Bernstein e Goodman [1981] por sua vez contm um timo tutorial sobre controle de concorrncia. Mais referncias sobre os tpicos aqui cobertos encontram-se nas notas bibliogrficas dos trs prximos captulos.

- 28 -