CAPTULO 9.

CONTROLE DE INTEGRIDADE
Os tipos de falhas que podem acometer cada n do sistema foram descritos e classificados no Captulo 6. Este mesmo captulo contm uma breve descrio dos principais mecanismos que so usados para se implementar a funo de controle de integridade. O sucesso desta operao vital para assegurar o prprio princpio de atomicidade em relao a cada transao submetida ao SGBD. Alguns dentre aqueles mtodos sero agora focalizados em mais detalhe. No Captulo 7 foi apresentada a integrao funcional de todos os mdulos que compem o SGBD em cada n da rede. Os mecanismos de controle de integridade lidam apenas com aes elementares estando, portanto, posicionados nas camadas inferiores que compem a hierarquia local do SGBD. Relembrando, o SGBD local em cada n tem sob seu controle os agentes locais que operam em benefcio das vrias transaes que a se originaram, ou que vieram a migrar para este n. Cada agente local j recebe do SGBD local uma seqncia de aes elementares que, por sua vez, formam parte de uma transao submetida pelo usurio em algum n da rede. Os agentes locais devem zelar para que as aes elementares que recebem sejam executadas na ordem especificada. Operando no prximo nvel mais interior est o mecanismo de controle de concorrncia. Este ltimo responsvel por serializar as aes elementares de todas as transaes que esto ativas neste n de modo a evitar inconsistncias. Os mecanismos de controle de integridade vem logo a seguir na hierarquia local. medida que o controle de concorrncia libera aes elementares, estas passam pelo controle de integridade antes de acionarem o sistema operacional local quando, ento, materializam o acesso ao BD local. Com este cenrio em mente, podemos passar descrio de alguns mtodos empregados para efetivar a funo de controle de integridade.

9.1 ATAS
Dentre todas as maneiras de se proporcionar segurana contra os efeitos malficos de eventuais falhas, o seguinte paradigma expe uma idia bastante singela: y sempre que a invocao de uma ao elementar implicar numa mudana de estado do BD, os estados anterior e posterior invocao da ao so postos a salvo em lugar seguro; y ocorrendo uma falha, uma busca junto aos registros que foram salvos permitir reconstruir um estado consistente do BD. O mecanismo de atas (ou, em ingls, "logs", "audit trails", "journals") se prope a implementar este paradigma. Conquanto a idia bsica seja simples, devido ao fato que operam em ambientes complexos, atas enfrentam problemas de sincronismo, de eficincia e de eficcia que geram mecanismos de controle de integridade bastante sofisticados. Atas garantem, em primeira instncia, proteo contra falhas primrias mesmo porque, exceo de pseudo-falhas, estas so, de longe, os tipos mais freqentes de falhas com que deve se preocupar um SGBD usual. Dependendo da gravidade e de que reas de memria secundria ativa foram atingidas por uma falha secundria, o mecanismo de atas pode tambm recuperar o BD a um estado consistente aps a ocorrncia de uma falha secundria. Nesta seo, porm, estaremos primordialmente

preocupados em combater falhas primrias. A menos que expressamente declarado em contrrio, o termo falha ser reservado, nesta seo, a designar falhas primrias. Quanto organizao, iniciaremos com comentrios gerais, seguidos de um mecanismo simplificado. medida que prosseguirmos, aprimoramentos sero introduzidos e discutidos. 9.1.1 Consideraes Gerais Nesta subseo levantaremos pontos importantes que devem ser tidos em mente quando o controle de integridade for descrito em detalhe. Muitos deles j foram abordados antes, de modo que a discusso abaixo servir para relembr-los, agora focalizando-os sob os aspectos que tocam mais de perto os mecanismos de controle de integridade. 9.1.1.1 O Sistema de Paginao Local Obviamente no se pretende salvar o estado completo do BD cada vez que uma ao elementar executada e provoca mudana de estado no BD. Mesmo em sistemas pequenos, isto implicaria em custos altos demais e, pior, para resguardar informao de forma muito ineficiente. Antes, registros so anotados na ata descrevendo os valores inicial e final de cada objeto modificado, catalogando as mudanas de forma incremental. Podemos conceber o BD a nvel lgico como um conjunto de objetos de alguma forma interrelacionados. Da mesma forma, podemos visualizar a ata, logicamente, como uma seqncia semi-infinita de registros, cujos contedos sero especificados oportunamente. Do ponto de vista fsico, cada BD local ser entendido como composto por uma srie de pginas de memria. Cada pgina identificada por um endereo nico e todas as pginas so do mesmo tamanho. Os valores dos vrios objetos fsicos so codificados em campos internos a estas pginas. Suporemos que h espao suficiente em cada pgina para acomodar o valor de qualquer objeto fsico do BD, a qualquer tempo. Assim, a cada objeto fsico podemos tambm associar um nico endereo. Este endereo poderia ser tomado como um par ordenado contendo o endereo da pgina onde se localiza o objeto seguido de um endereo relativo ao comeo desta pgina, especificando completamente a posio deste particular objeto. Em acrscimo, outras informaes, tais como o nmero de "bits" reservado a este objeto, podem tambm fazer parte de seu endereo. Este esquema est em consonncia com o fato de que estamos operando a nvel de aes elementares, manipulando apenas objetos fsicos do BD. Mais ainda, esta viso forma uma interface natural com o sistema operacional local que, provavelmente, j implementa o conceito de paginao. Em vista desta ltima observao, nada mais natural que acomodar a prpria ata, fisicamente, tambm em pginas de memria. Imaginamos que as pginas de memria onde residem o BD e a ata localizem-se em memria secundria a salvo, portanto, de quaisquer danos causados por falhas primrias. Ocorre que o contedo de memria secundria no pode ser modificado "in loco". Para modificar o contedo de uma pgina, quer referente ao BD local ou ata, o sistema operacional local deve 1. ler a pgina em questo para a memria principal; 2. modificar seu contedo como desejado, na memria principal; 3. reescrever a pgina de volta na memria secundria, destruindo a cpia original

Durante instantes crticos, partes do BD ou da ata devem ser trazidos a memria principal para modificaes. No seria uma boa idia reescrever cada pgina de volta memria secundria aps cada modificao. Isto geraria trfego excessivo entre a memria principal e a memria secundria, o que poderia degradar sensivelmente o tempo de resposta do sistema, visto que acessos a memria secundria so relativamente lentos quando comparados a operaes em memria principal. desejvel, portanto, manter certas pginas em memria principal por perodos mais prolongados. Em conseqncia, pginas de memria principal podero sofrer muitas alteraes antes de ser reescritas em memria secundria, tanto por transaes em andamento como por outras transaes que j confirmaram ou cancelaram e mesmo j desapareceram do BD. Falhas primrias podero destruir o contedo destas pginas antes que tenham uma chance de serem reenviadas a memria secundria. Mesmo estando dispostos a pagar o preo de ter maior trfego entre memria principal e memria secundria, ainda no esta afastado o risco do sistema falhar em momentos crticos, destruindo o contedo de pginas que no puderam ser reescritas em memria secundria. Note que as pginas que descrevem a prpria ata so afetadas por este tipo de problema. O mecanismo de controle de integridade deve proteger no apenas o BD local como o contedo da prpria ata que usa para garantir a segurana do sistema todo. Enfatizamos que o processo de reescrita em memria secundria vai obliterar o contedo anterior da correspondente pgina em memria secundria. H mecanismos de controle de integridade que reescrevem a nova cpia em reas de trabalho na memria secundria de forma a no destruir a cpia original. Tais mecanismos sero alvo de discusso em sees posteriores. A memria secundria dispe de capacidade de armazenamento muito superior quela da memria principal. Na realidade, neste estgio inicial, estamos supondo que a memria secundria ilimitada, pois definimos que a prpria ata capaz de armazenar incontveis registros. De qualquer forma, necessrio que pginas sejam recolocadas em memria secundria, de tempos em tempos, para abrir espao para que novas pginas possam ser lidas para a memria principal. Suporemos que a memria principal contm uma rea especfica, que chamaremos de rea de trabalho, a qual pode conter um nmero finito, porm no especificado, de pginas de memria. O trnsito de pginas entre a rea de trabalho e a memria secundria controlado por um gerente de paginao. Este ltimo implementa protocolos para, por exemplo, escolher qual a prxima pgina que deve sair da rea de trabalho para que outra pgina, cuja leitura foi requisitada, seja colocada na rea de trabalho e posta a disposio do processo requisitante. O particular algoritmo de substituio de pginas na memria principal quando a rea de trabalho encontra-se saturada de responsabilidade do sistema operacional local. O mecanismo de controle de integridade poder interferir no comportamento do algoritmo de duas formas. Em primeiro lugar, ter poderes para forar com que pginas sejam recolocadas na memria secundria quando assim o determinar. Em segundo lugar, poder tambm decretar que pginas da rea de trabalho sejam mantidas na memria principal at segunda ordem. A menos destas interferncias, necessrias para que as aes de ambos os mdulos sejam sincronizadas apropriadamente, o mecanismo de atas permite que o gerenciador de paginao siga suas prprias estratgias de controle do trfego de pginas. Em particular, a ordem de entrada e sada de pginas na memria principal ou o tempo de permanncia de cada pgina na rea de trabalho, so de livre escolha do gerenciador de paginao local. Deve ficar claro, porm, que h dois mecanismos decidindo a respeito de quando e quais pginas so trazidas da memria secundria ou para l so enviadas: o gerenciador de paginao e o controle de integridade locais.

Em geral, teremos parte da rea de trabalho ocupada por pginas que representam objetos do BD e outro tanto tomado por pginas que descrevem partes da ata. Da mesma forma, na memria secundria haver pginas correspondentes ao BD e outras que completam a ata. O desafio encarado pelo controle de integridade est em orquestrar as idas e vindas de pginas entre a memria principal e a memria secundria, de tal sorte a garantir que, na eventualidade de uma falha primria, a parte da ata que no foi afetada contenha informao suficiente para reconstruir um estado consistente do BD e tambm recuperar a prpria ata. Lembre que falhas primrias destrem o contedo da memria principal e, em conseqncia, inutilizam tambm o contedo da rea de trabalho. A seqncia dos acontecimentos pode ser de tal ordem que pginas com modificaes relativas a transaes que j confirmaram, desaparecendo do BD, ainda se encontravam na rea de trabalho no instante da falha. Tambm, apenas parte das pginas envolvidas com transaes que cancelaram podem ter sido reenviadas para a memria secundria, consolidando a operao de desfazer os efeitos da transao. Entretanto, outras pginas afetadas por esta transao podem ainda no ter sido reescritas em memria secundria no intervalo compreendido entre o instante em que o efeito das aes elementares foram invertidos at o momento da falha. Assim, a operao de desfazer os efeitos da transao ainda no teve chance de ser registrada a salvo, estando aquela pgina inconsistente. H tambm a preocupao em torno da eficincia do processo de recuperao e, ainda, cuidados devem ser tomados para que a manipulao da ata no degrade o sistema de forma significativa. 9.1.1.2 Incio, Migrao e Trmino de Transaes Quando do incio de uma transao, antes de entrar na execuo de sua primeira ao elementar, o agente local da transao instala em lugar seguro, isto na ata, um registro descrevendo este fato. Chamaremos este registro de registro de incio de transao ou simplesmente registro de incio. Conforme exposto no Captulo 7, o contedo deste registro varia segundo este o n de origem da transao ou no. Esta diferena, no entanto, explorada apenas na fase de migrao da transao, sendo, neste ponto, imaterial para a discusso que segue. O importante que cada transao ativa num dado n dispe de um nico registro de incio instalado na ata. Durante a fase de migrao, um registro de execuo lanado na ata para cada ao elementar invocada em favor desta transao e cuja invocao resulte na modificao do valor do objeto. Alm do endereo do objeto modificado, o registro de execuo contm tambm os valores iniciais e finais do objeto. Se a transao for forada a cancelar localmente, a ata deve receber um registro de cancelamento local da transao ou registro de cancelamento local. Na fase de trmino, h todo um ritual que deve ser observado para confirmar e cancelar transaes, j descrito no Captulo 7. Transaes s so consideradas confirmadas em um dado n quando, ao executar a segunda fase do protocolo bifsico, o sistema local instala na ata um registro de confirmao da transao ou simplesmente registro de confirmao. Por outro lado, transaes so canceladas num particular n quando o sistema lana na ata um registro de cancelamento da transao ou, de forma curta, um registro de cancelamento. importante relembrar que antes de escrever o registro de cancelamento, o protocolo bifsico cuida para que todas as aes elementares desta transao sejam invertidas, isto , seus efeitos so removidos. S aps o sucesso desta operao o registro de cancelamento instalado. Observe que as aes elementares invocadas para inverter os efeitos das aes normais da transao no deixam traos de sua invocao na ata. Esta contm apenas os registros referentes as aes elementares invocadas antes do ponto em que o cancelamento foi decidido.

T1 T2 T3 T4

T7

T6

T5

incio
Figura 9.1 - Transaes Executando

falha

Tempo

O ltimo tipo de registro de que necessitamos so registros de trmino de transao, ou simplesmente registros de trmino. So precisamente aqueles registros lanados na ata pelo protocolo bifsico durante a fase de trmino da transao, conforme previsto na descrio deste protocolo no Captulo 7. Descrevem os estados por que passa o protocolo ao executar localmente em favor de determinada transao, quer seja este o n coordenador ou apenas um n participante. 9.1.1.3 O Controle de Concorrncia Lembre que as aes elementares de todas as transaes ativas em um dado momento devem ser serializadas pelo mecanismo de controle de concorrncia. Esta serializao obtida sem se levar em conta possveis aes elementares que venham a anular os efeitos de aes anteriores, como requerido quando devemos desfazer os efeitos de transaes. Refazer e desfazer os efeitos de aes elementares para que transaes tenham seus efeitos reconfirmados ou recancelados, cria a expectativa de que certas aes elementares sero executadas contra o BD revelia dos mecanismos de controle de concorrncia. Em princpio isto poderia configurar cenrios onde houvesse violao da consistncia do BD devido a serializaes estranhas. Lembre, porm, que a tarefa fundamental dos mdulos de controle de concorrncia propiciar uma serializao das aes elementares de tal sorte que uma transao no tem como acessar objetos modificados por outra transao que ainda no tenha completado. Assim, num dado instante, o uso de cada objeto do BD privativo da transao ativa naquele instante que ir modificar o seu valor. Um mesmo objeto pode ser lido por vrias transaes, desde que nenhuma outra transao em andamento venha a modificar seu valor. Neste ltimo caso, claro, no h mal em assim se proceder pois que a operao de leitura no altera o valor do objeto. Tome como exemplo a situao ilustrada na Figura 9.1, onde T4 e T5 estariam incompletas no instante da falha. Digamos que T2 e T6 hajam cancelado enquanto que as demais, T1, T3 e T7 tenham confirmado. Neste exemplo, T3 e T6 no poderiam estar modificando o valor de um mesmo objeto. O mesmo pode ser dito quanto a T1 e T7, e assim por diante. J T1, T3 e T5 poderiam ter sido executadas envolvendo modificaes sobre o valor de um mesmo objeto.

O O

+ + + + o o o o o x x x x x (a) + + o o o o o + + x x x x x (b)

O1 O2

+ + + + + o o o o o + + + + + + + x x x
1 2

(c)

Tempo

+ = aes elementares de T1 o = aes elementares de T2 x = aes elementares de T3

Figura 9.2 - O Princpio da No Interferncia Suponha que agrupemos as aes elementares em classes, uma para cada objeto do BD, de tal sorte que aes pertencentes a mesma classe afetam o mesmo objeto. Ento podemos dizer que, se agrupadas por transaes, a seqncia de aes de uma mesma classe devem ocorrer em blocos completos de aes referentes a uma mesma transao. A Figura 9.2 ilustra este fato, onde as transaes T1, T2 e T3 so supostas pertencerem a uma mesma classe. A seqncia (a) seria vlida, pois as aes elementares no esto misturadas. Uma seqncia de aes de uma transao no interrompida por seqncias de aes de outras transaes. No caso da seqncia (b), o controle de concorrncia no operou de forma correta, pois aes da transao T2 foram enxertadas entre as aes de T1, o que pode levar a toda sorte de problemas, conforme discutido no Captulo 8. Mesmo que no haja problemas quando tomamos cada classe isoladamente, isto no suficiente para garantir que a mxima da no interferncia enunciada acima observada no conjunto. Na parte (c) da mesma figura, temos as seqncias correspondentes as classes de aes elementares que modificam os objetos O1 e O2. Tomadas separadamente, as seqncias relativas a O1 e O2 apresentam os blocos completos que desejamos. As setas 1 e 2 indicam um intervalo de tempo quando a transao T1 estava certamente ativa. A seta 3, porm, indica que T2 modificou o objeto O1, tambm modificado por T1, antes que T1 completasse. Este cenrio viola o princpio de que a uma transao no permitido modificar o valor de objetos que so modificados por uma segunda transao que ainda no completou.

Desta discusso podemos concluir que a ao de desfazer os efeitos locais de uma transao no requer que, em conseqncia deste ato, tenhamos que desfazer tambm os efeitos de outras transaes. A razo para isto se fixa exatamente no fato de que objetos modificados por uma transao so invisveis a outras transaes durante o perodo em que a primeira est ativa. Se este princpio no fosse observado, ao desfazer os efeitos de uma transao poderamos nos ver envolvidos em um processo em cascata, sendo forados a desfazer efeitos de outras transaes. Dentre estas poderiam estar transaes j confirmadas e eliminadas do BD. Mais ainda, sendo o BD distribudo, este processo de cascata poderia se alastrar para outros ns, com as conseqncias malficas usuais no tempo de resposta, entre outras. Estando os mecanismos de controle de concorrncia a operarem corretamente, porm, cada ao de desfazer os efeitos de aes elementares ficara contido ao n onde iniciado. 9.1.2 Um Mecanismo Simplificado Vamos iniciar o desenvolvimento dos mecanismos de controle de integridade com um modelo ainda irreal cujo objetivo apresentar as idias bsicas de forma simplificada. Subsees posteriores sofisticaro este modelo bsico de forma a torn-lo real e, tambm, mais eficiente. Suporemos nesta seo que as modificaes no contedo da ata possam ser escritas diretamente em memria secundria e de forma atmica. Por conseguinte, todas as pginas da ata residem sempre em memria secundria, mesmo durante os instantes em que so atualizadas, estando a salvo de falhas. A rea de trabalho em memria principal contm apenas pginas com dados do BD local. Para o gasto imediato, podemos tomar cada registro da ata como formado pelos seguintes campos, de acordo com seu tipo. Os registros de tipo INCIO, CONFIRMAO, CANCELAMENTO e CANC_LOCAL contm os campos identificao tipo Os registros de tipo TRMINO contm os campos identificao tipo estado de retorno Os registros de tipo EXECUO contm os campos identificao tipo endereo valor inicial valor final

O significado dos campos identificao e estado de retorno bvio: refletem, respectivamente, a identificao da transao que lanou este registro na ata ou um estado de retorno do protocolo bifsico. Os campos de tipo classificam os registros de acordo com sua utilidade ou funo. O tipo INCIO indica o ponto quando a transao foi, pela primeira vez, ativada neste n. Os tipos CANCELAMENTO e CONFIRMAO indicam tanto o instante quando a execuo do protocolo bifsico terminou, como tambm qual o destino global dado transao: se cancelada ou confirmada, respectivamente. Neste instante, a transao desaparece do BD e, claro, tambm eliminada da tabela de transaes ativas em poder do executor de transaes local. O tipo CANC_LOCAL reflete o fato de que esta transao foi cancelada localmente, porm o ritual previsto no protocolo bifsico ainda no foi, at este momento, completado no que diz respeito a esta transao. O executor de transaes local ainda mantm a transao na sua tabela de transaes ativas, indicando que sofreu cancelamento local. O tipo TRMINO indica registros que contm estados de retorno, relativos ao protocolo bifsico. Finalmente, o tipo EXECUO refere-se a registros que revelam os efeitos de aes elementares invocadas em favor desta transao. Seu campo de endereo contm o endereo completo do objeto modificado. Seus campos de valor inicial e valor final contm os valores deste objeto anterior e posterior invocao da ao elementar que originou o registro, respectivamente. medida que os algoritmos forem se tornando mais sofisticados, novos campos sero introduzidos e novos valores sero definidos para o contedo do campo de tipo. No presente nvel de detalhe, esta descrio ser satisfatria. Podemos observar desde j que, na prtica, cada registro poder conter mais informaes, tais como o tamanho do registro, necessrias para uma eficiente implementao dos registros da ata a nvel fsico. Para facilidade de discurso, vamos classificar as transaes de acordo com o seguinte esquema. Seja T uma transao qualquer. Diremos que em dado momento e em um dado n T uma transao cancelada se constar na ata um registro de CANCELAMENTO ou CANC_LOCAL com a identificao de T. Chamaremos T de uma transao confirmada se pudermos localizar na ata um registro tipo CONFIRMAO referente a T. Note que, em qualquer momento, T no pode ser classificada como cancelada ou confirmada, simultaneamente. O termo transao confirmando ser reservado quelas transaes que, no podendo ser classificadas como canceladas ou confirmadas num certo instante, contarem, neste instante, com um registro tipo TRMINO j lanado na ata em seu benefcio. Mais ainda, o campo de estado de retorno deste registro dever conter PRONTO_SIM ou CONFIRMANDO. Eventualmente, com o correr do tempo, transaes podem mudar de classe. Finalmente, chamaremos de transao incompleta quela transao que no se enquadra em nenhuma das trs classes definidas h pouco. Suponha que num certo instante inicial o BD est em um estado quiescente, isto , todas as transaes invocadas j confirmaram ou cancelaram globalmente. A partir deste momento, transaes passam a executar contra o BD, algumas confirmando, outras cancelando. Num dado ponto, ocorre uma falha, colhendo certas transaes antes que tenham cancelado ou confirmado. Seja I um ponteiro que indica, na ata, o registro correspondente ao incio da primeira transao que modificou o contedo de qualquer pgina do BD, desde que o sistema esteve quiescente pela ltima vez. Mais tarde, o problema de se obter I ser contornado. O mecanismo de controle de integridade dever

desfazer os efeitos de transaes incompletas desfazer os efeitos de transaes canceladas refazer os efeitos de transaes confirmadas refazer os efeitos de transaes confirmando determinar que transaes foram colhidas durante a execuo do protocolo bifsico Tomando a ata como uma seqncia que cresce da esquerda para a direita, I indica o registro tipo INCIO, situado mais esquerda na ata, cuja transao alterou o contedo de uma pgina do BD desde que esteve quiescente pela ltima vez. Uma primeira idia para se restaurar a consistncia do sistema aps uma falha primria descrita abaixo. So usadas trs listas, a saber: TC, TA e TR. A primeira acumular as transaes iniciadas aps o ponto I que foram colhidas pela falha como confirmadas ou confirmando. A segunda lista ser formada por transaes iniciadas aps I que, no momento da falha, seriam classificadas como canceladas ou incompletas. Cada transao em TA ser marcada como "local" ou "global" segundo tenha sido cancelada local ou globalmente, respectivamente. No curso do algoritmo, como veremos, transaes incompletas sero promovidas a canceladas localmente e, assim, tambm sero marcadas como "local". A ltima lista, TR, conter a identificao e estado de retorno daquelas transaes que so colhidas no instante da falha durante a execuo do protocolo bifsico. As trs listas agrupam aquelas classes de transaes que esperam o mesmo tipo de atitude por parte do controle de integridade durante a fase de recuperao. Repare que a lista TR pode ter elementos em comum com as listas TA e TC. No primeiro caso, por exemplo, poderamos ter uma transao que j iniciou a execuo do protocolo bifsico, tendo sido cancelada localmente durante a execuo da primeira fase. No segundo caso, a transao j lanou na ata um registro de tipo TRMINO, com campo de estado de retorno contendo PRONTO_SIM, porm ainda no finalizou a execuo do protocolo bifsico. Podemos, agora, detalhar um pouco mais as operaes do mecanismo de controle de integridade. Numa primeira fase, removemos efeitos de aes elementares. Andando na ata para a esquerda, desde o instante da falha at o ponto I, examine cada registro encontrado. Seja R o prximo registro a ser examinado. Se o campo de tipo de R contiver 1) CANCELAMENTO: a) ponha a identificao da transao na lista TA e marque-a como "global" ; 2) CONFIRMAO: a) ponha a identificao da transao na lista TC ; 3) CANC_LOCAL: a) se a transao no est em TA, ento ponha sua identificao em TA e marque-a como "local" ;

4) TRMINO: a) se campo de estado de retorno de R indicar PRONTO_SIM ou CONFIRMAO e a transao no est em TC ento ponha a transao na lista TC e na lista TR, junto com seu estado de retorno ; b) se campo de estado de retorno de R no indicar PRONTO_SIM nem CONFIRMAO e a transao no est em TC nem em TR ento ponha a transao na lista TR, junto com seu estado de retorno 5) EXECUO: a) se a transao est em TA, no importando sua marca, ento remova os efeitos desta ao elementar b) se a transao no est nem em TA nem em TC, ento remova os efeitos desta ao elementar c) caso contrrio, ignore este registro 6) INCIO: a) se a transao no est em TA nem em TC, ento i) envie uma mensagem de resposta, com campo de veredicto contendo CANCELADO, ao n coordenador da transao ii) construa um registro de ata tipo CANC_LOCAL para esta transao iii) lance este registro na ata iv) acrescente esta transao lista TA, marcando-a como "local" Numa segunda fase, reinstalamos os efeitos de aes elementares. Andando para a direita, desde I at o fim da ata, examine cada registro que encontrar. Seja R o prximo registro a ser examinado. Se o campo de tipo de R contiver 1) EXECUO: a) se esta transao est na lista TC, ento refaa os efeitos desta ao elementar b) caso contrrio, ignore este registro 2) EM QUALQUER OUTRO CASO: a) ignore este registro O algoritmo l a ata duas vezes. Na primeira vez, partimos do fim da ata e a percorremos at o ponto indicado por I. Note que os registros indicando se uma particular transao confirmou, cancelou ou j foi envolvida na execuo do protocolo bifsico s aparecem na ata aps todos os

registros de execuo da transao. Percorrendo a ata de trs para a frente passaremos pelos registros de tipo CONFIRMAO, CANCELAMENTO, CANC_LOCAL ou TRMINO antes de atingirmos qualquer registro de tipo EXECUO de uma mesma transao. Usando este fato, as listas TC, TA e TR so compiladas a medida que prosseguimos. Mantendo estas listas, teremos condies de determinar o estado de cada transao no instante da falha e, assim, tomar as medidas apropriadas quando os registros de EXECUO forem encontrados. Durante a primeira fase, todas as aes elementares invocadas em benefcio de transaes que estavam incompletas no instante da falha so desfeitas. Observe que isto feito na ordem inversa daquela em que estas mesmas aes elementares foram invocadas, como desejvel. O racional para se desfazer os efeitos de tais transaes baseado no fato de que o gerente de paginao local pode j ter enviado a memria secundria algumas das pginas modificadas por esta transao. As mudanas instaladas nestas pginas devem, portanto, ser removidas. Repare que, quando atingimos um registro tipo EXECUO para uma transao incompleta este fato pode ser determinado verificando-se se a transao no consta em TA nem em TC. Este trabalho de desfazer efeitos estar completo quando atingirmos o registro de tipo INCIO desta mesma transao. Neste ponto, devemos lanar na ata um registro de tipo CANC_LOCAL e, tambm, adicionar a transao, marcada como "local", na lista TA. O resultado provocado pela falha ser idntico a um cancelamento local da transao. Os efeitos de transaes que j haviam cancelado, localmente ou globalmente, devem tambm ser desfeitos nesta primeira fase. Este tipo de transaes so acumuladas na lista TA. A necessidade de remover os efeitos destas transaes advm do fato de que o gerente de paginao pode ainda no ter reenviado algumas pginas modificadas pela transao memria secundria desde o instante em que suas aes elementares foram desfeitas. Neste caso, a inverso destes efeitos ainda residia na memria principal no instante da falha e foram, portanto, perdidas. Lembre que sempre desfazemos os efeitos de todas as aes elementares de uma transao antes de lanar na ata registros tipo CANCELAMENTO ou CANC_LOCAL. Observe que, quando o algoritmo terminar, no mais haver transaes incompletas no sistema, neste momento. A segunda fase do algoritmo simplesmente percorre a ata desde o ponto indicado por I at seu fim. Ao examinar cada registro tipo EXECUO, a correspondente ao elementar ter seus efeitos reinstalados caso a respectiva transao conste da lista TC, de transaes que devem confirmar. A ao elementar que ser refeita, claro, est descrita pelos campos de valor inicial, valor final e endereo presentes no registro ora em exame. Em seguida, o controle de integridade informa ao executor de transaes local quais transaes estavam no estado de canceladas localmente. Esta informao ser necessria quando o executor de transaes local participar do ritual prescrito pelo protocolo bifsico, quando este executar em favor desta transao. De forma anloga, o executor de transaes local precisa saber a identidade e estado de retorno correspondente a cada transao que foi colhida pela falha quando o protocolo bifsico executava em seu benefcio. Neste ltimo caso, conforme discutimos no Captulo 7, o executor de transaes local no esperar o incio da execuo do protocolo bifsico pelo n de origem da transao. Em vez disso, retoma a execuo do protocolo a partir do estado de retorno que lhe informado pelo controle de integridade.

6 3 1
4,L 7,L

6 3

TC
4,L 7,L

TA VALOR

Refazendo
6 3 1
7 LX4 LX2 G

6 3

TC

7 LX4 L

7 LX4 L

7 LX4 L

7,L

7 LX5 G

7 LX5 G

TA
7,L

VALOR

Desfazendo

1 2

2 3

2 4

4 5

CL

4 6

CL

4 7

7 8

LOG

T1
Legenda:

T2
I = Incio F = Confirmao

T3

T4
valor inicial valor final

T5

T6

T7 falha Tempo

C = Cancelamento CL = Canc. Local

Figura 9.3 - Recuperando-se de Uma Falha Primria Considere a Figura 9.3. onde a execuo do algoritmo ilustrada. Para simplificar, estamos mostrando apenas o que ocorre com o valor de um objeto, O, afetado pelas transaes que detm registros na ata direita de I. A figura contm, na primeira coluna, uma fotografia do trecho da ata desde o registro apontado por I at o instante da falha. Esta coluna deve ser lida de cima para baixo. Cada transao foi limitada a um nico registro tipo EXECUO para manter o exemplo sob controle. A segunda coluna, lida de baixo para cima, reflete a fase de desfazer aes elementares. Esta coluna dividida em trs sub-colunas. Estas ltimas mostram o efeito do processamento de cada registro da ata sobre o valor do objeto e tambm sobre o contedo das listas TA e TC. Para no sobrecarregar a figura, adotamos a conveno de que, em cada coluna, um espao em branco indica o mesmo valor dos extremos verticais que o contm. Na coluna referente lista TA os elementos so indicados por pares, onde o primeiro componente refere-se a transao em questo e o segundo indica "L" ou "G", conforme a correspondente transao esteja marcada "local" ou "global" em TA, respectivamente. Note que no podemos ter, no intervalo de tempo ilustrado na referida figura, outras transaes que modificaram o valor deste mesmo objeto e que se encontrem, no instante da falha, envolvidas na execuo do protocolo bifsico. Isto se deve ao fato de que estamos analisando apenas um objeto e a mxima da no interferncia entre transaes fora este cenrio. Lembre que os recursos do sistema requisitados

por cada transao s so liberados quando o protocolo bifsico termina ou quando a transao cancelada localmente. A lista TR seria, portanto, iniciada como vazia e terminaria como tal. Devido a este fato, no a inclumos na figura. Quando mais de um objeto esto envolvidos poderemos ter, num dado momento, vrios elementos em TR. A terceira coluna da Figura 9.3, lida de cima para baixo, mostra a fase quando aes elementares so refeitas. Valem os mesmos comentrios colocados a respeito da segunda coluna. Dadas as descries de cada registro da ata fcil ver que todos os passo do algoritmo so exeqveis. Por exemplo, cada registro tipo EXECUO contm o endereo mais os valores iniciais e finais do objeto a que se refere seu campo de identificao. Assim, podemos refazer/desfazer os efeitos daquela ao elementar a que corresponde o registro. Um aspecto importante a notar que o algoritmo apresenta imunidade contra falhas em cascata, isto , quando o sistema torna a falhar durante a execuo do prprio algoritmo de recuperao. Observe que as operaes de refazer/desfazer os efeitos de aes elementares podem ser repetidas vontade, sem introduzirem valores estranhos por estarmos refazendo/desfazendo a mesma ao vrias vezes. Isto porque a ao de desfazer limita-se a substituir o valor do objeto pelo contedo do campo de valor inicial obtido do registro da ata que estamos a examinar naquele instante. O mesmo se d, em sentido inverso, para a ao de refazer. O que pode variar no caso de falhas em cascata o contedo da lista TA, visto que a primeira tentativa de recuperao pode ter introduzido na ata registros de tipo CANC_LOCAL para transaes que antes eram tidas como incompletas. Isto, porm, no influir no resultado final do algoritmo. A hiptese de perdermos parte da ata, junto com o contedo da memria principal, est afastada neste modelo simplificado. Assim, o contedo da ata, tomado a partir do ponteiro I, sempre suficiente para restaurar o BD local a um estado quase-quiescente, quer ocorram ou no falhas em cascata. Referimo-nos ao estado de retorno como quase-quiescente devido ao fato de que as transaes em TR ainda no confirmaram ou cancelaram globalmente. Entretanto, aps a recuperao do sistema local, no h qualquer transao, ativa localmente, que ainda esteja na fase de migrao. 9.1.3 Um Mecanismo Mais Elaborado O modelo simplificado da seo anterior apresentava um algoritmo para controle de integridade bastante ineficiente. Tudo se passava como se estivssemos repetindo, um tanto s avessas, todas as aes elementares que foram invocadas desde o instante em que se deu a ltima falha. Como desejaramos que os intervalos entre falhas fossem os mais longos possveis, este particular esquema incorpora muita ineficincia. Nesta seo, vamos descrever novas tcnicas que nos permitiro agilizar o mtodo bsico. Ainda manteremos a hiptese de que podemos escrever diretamente na ata em memria secundria. Uma das fontes de ineficincia do algoritmo anterior reside no fato de que uma determinada ao elementar refeita, ou desfeita, independentemente da pgina correspondente j ter sido reenviada memria secundria aps esta ao ter sido invocada. Para obtermos uma idia, do tipo de economia que se pode conseguir, examinemos a Figura 9.4, onde so indicados trs casos possveis. Para cada caso, esto assinaladas na ata as posies de todos os registros referentes a uma mesma transao T que modificou o contedo de uma pgina P do BD. O ponto marcado por Y mostra o ltimo instante em que P veio para a memria principal.

I
Y

ATA

(A) Tempo

falha

I
Y

ATA

(B) Tempo

falha

I
Y

ATA

(C) Tempo

falha
C = Cancelamento CL = Canc. Local valor inicial valor final

Legenda:

I = Incio F = Confirmao

Figura 9.4 - Que Aes Desfazer/Refazer No caso (a), T confirmou. esquerda de Y est o registro de INCIO correspondente a T, seguido pelos registros de EXECUO de T e, direita de Y, encontra-se o registro de CONFIRMAO de T. Neste caso, apenas as aes elementares de T cujos registros foram instalados na ata aps o instante Y devem ter seus efeitos reinstalados no BD. So os registros assinalados na figura. Se T fosse classificada como confirmando em vez de confirmada, o esquema seria anlogo, apenas que teramos um registro tipo PRONTO_SIM ou CONFIRMANDO no lugar do registro de CONFIRMAO. O caso (b) indica uma transao incompleta. Neste ltimo caso, todas as suas aes elementares correspondentes a registros de T que ocorrem aps Y j foram desfeitos com a perda do contedo da memria principal. Logo, apenas os registros que ocorreram antes do ponto Y devem ser usados para desfazer efeitos j instalados no BD. Finalmente, a parte (c) ilustra uma transao cancelada. O raciocnio anlogo quele para transaes incompletas, ou seja, devemos desfazer os efeitos de aes cujos registros aparecem na ata antes do ponto Y.

Partimos agora para uma descrio mais precisa. Novos tipos de registros sero necessrios e, tambm, alguns campos adicionais sero introduzidos em certos tipos de registros j definidos. Como ficou claro da discusso acima, temos que indicar no s os instantes em que pginas so trazidas para a rea de trabalho, como tambm os instantes em que so enviadas para a memria secundria. Registros de tipos LIDA e ESCRITA vo assinalar estes pontos. Alm disso, para melhorar a busca de registros na ata, estes formaro agora duas cadeias independentes. Uma delas ligar os registros que pertencem a uma mesma transao. Esta cadeia segue da direita para a esquerda, isto , o ponteiro de um registro localiza a posio na ata do registro imediatamente anterior a este, referente a mesma transao. Os ponteiros que ligam os vrios elementos desta cadeia sero chamados de ponteiros de transao. A segunda cadeia liga, de forma similar, todos os registros que afetam uma mesma pgina. Estes ltimos sero conhecidos como ponteiros de pgina. Refletindo isto, os vrios registros da ata podem ter, agora, os seguintes valores em seus campos de tipo INCIO CONFIRMAO CANC_LOCAL LIDA TRMINO CANCELAMENTO EXECUO ESCRITA

Um registro tipo LIDA ou ESCRITA formado pelos campos de tipo identificao de pgina Um registro tipo INCIO, CONFIRMAO, CANCELAMENTO ou CANC_LOCAL formado pelos campos de tipo identificao de transao ponteiro de transao ponteiro de pgina Um registro tipo TRMINO formado pelos campos de tipo identificao de transao ponteiro de transao ponteiro de pgina estado de retorno Um registro tipo EXECUO formado pelos campos de tipo identificao de transao ponteiro de transao ponteiro de pgina endereo do objeto manipulado valor inicial do objeto manipulado valor final do objeto manipulado

Cada pgina do BD tambm conter um ponteiro para a ata. Este ponteiro dever indicar o ltimo registro da ata que modificou valor de algum objeto desta pgina. Chamaremos este ltimo ponteiro de ponteiro de ata. Antes de descrever o novo algoritmo, preciso deixar claro quais os passos seguidos durante a fase de migrao que tero influncia no comportamento do algoritmo. Para este fim, as fases de incio, migrao e trmino de transaes so revistas abaixo. Em cada caso so indicados os pontos que devem ser observados quando adotamos a nova estrutura de registros da ata. Tambm so descritas as condies que devem ser satisfeitas pelo gerente de paginao quando este instala uma pgina na rea de trabalho da memria principal, ou remete-a memria secundria. QUANDO DO INCIO DA TRANSAO 1) o local de origem da transao inicia sua execuo; a) o executor de transaes instala na ata um registro tipo INCIO cujos campos de ponteiros de pgina e ponteiro de transao so nulos. O respectivo campo de identificao contm, claro, a identificao da transao; b) o executor de transaes instala a transao em sua tabela de transaes que esto ativas neste n; c) o executor de transaes tambm anota nesta tabela o endereo, na ata, onde foi instalado este registro de INCIO; d) o executor de transaes instrui o SGBD local para que este crie um agente local para esta transao; 2) um n remoto recebe uma mensagem requisitando trabalho em favor de uma transao a) o executor de transaes verifica se a transao consta em sua tabela de transaes ativas neste n. i) em caso afirmativo, apenas instrui o SGBD local para criar outro agente local para esta transao. ii) em caso negativo, os mesmos passos previstos no tem 1 so executados QUANDO DA INVOCAO DE UMA AO ELEMENTAR 1) se a pgina que contm o objeto a ser modificado ainda no est na rea de trabalho da memria principal, requisite-a ao sistema operacional local; 2) aps satisfeita a requisio, a pgina "fixada" na rea de trabalho da memria principal; 3) a mudana desejada efetivada nesta pgina; 4) lanando o registro na ata: a) um registro para ata, de tipo EXECUO, e construdo na memria principal. Seus campos contm i) identificao: recebe a identificao da transao; ii) endereo: recebe o endereo desta pgina seguido do endereo do objeto relativo a esta pgina; iii) valor inicial: conter o valor do objeto antes de alterado pela ao em questo;

iv) valor final: conter o valor do objeto depois de alterado por esta mesma ao elementar; v) ponteiro de pgina: recebe o valor do ponteiro de ata presente nesta pgina; vi) ponteiro da transao: recebe o endereo do ltimo registro que foi instalado na ata em favor desta transao. Este endereo est em poder do executor de transaes local. b) registro assim construdo lanado na ata. 5) O valor do ponteiro de ata desta pgina que foi modificada recebe o endereo da ata onde este registro foi instalado; 6) em sua tabela de transaes ativas neste n, o executor de transaes substitui o endereo relativo a esta transao pelo endereo onde este registro foi instalado na ata; 7) a condio de "fixada", relativa a esta pgina, relaxada. QUANDO DA CONFIRMAO DA TRANSAO 1) um registro tipo CONFIRMAO lanado na ata. Os passos so os mesmos previstos no item 4 do grupo de aes referentes a execuo de uma ao elementar, descritos acima. claro que o tipo do registro ser CONFIRMAO e os passos envolvidos na construo dos campos de valor inicial, valor final e endereo devem ser ignorados. QUANDO DO CANCELAMENTO, GLOBAL OU LOCAL, DE UMA TRANSAO 1) obtenha do executor de transaes o endereo, na ata, do ltimo registro instalado at agora para esta transao. Este o registro que o executor de transaes mantinha, em sua tabela de transaes ativas neste n, junto a identidade desta transao. Seja R este endereo; 2) Desfazendo efeitos de aes elementares desta transao. Caminhe, a partir de R, atravs da cadeia formada pelos ponteiros de transao at encontrar um registro de tipo INCIO. Seja Z o prximo registro a ser examinado. a) se este registro no do tipo EXECUO, ignore-o; b) caso contrrio, seja P a pgina do BD indicada pelo ponteiro de pgina deste registro: i) se P no est na rea de trabalho da memria principal, requisite-a ao sistema operacional local; ii) aps satisfeita esta requisio, a pgina "fixada" na rea de trabalho da memria principal; iii) desfaa o efeito desta ao elementar sobre esta pgina; iv) o ponteiro de ata desta pgina deve receber o valor do ponteiro de pgina deste registro; v) a condio de "fixada", relativa a esta pgina, relaxada; c) caminhe pelo ponteiro de transao deste registro. Seja Z o novo registro encontrado. Volte ao passo 2a.

3) Instalando um registro na ata. Tambm agora efetuamos as mesmas operaes descritas sob o item 4 do grupo de aes expostas acima que cobrem os passos relativos a execuo de aes elementares, ignorando-se os mesmos campos de valor inicial, valor final e endereo. O campo de tipo preenchido com CANC_LOCAL ou CANCELAMENTO segundo estejamos, respectivamente, na presena de um cancelamento local imposto a este n por agentes externos, ou estejamos a finalizar o protocolo bifsico, cancelando a transao globalmente. QUANDO DA LEITURA DE PGINA PARA A REA DE TRABALHO 1) gerente de paginao requisita a pgina ao sistema operacional local; 2) se a operao de leitura bem sucedida, o gerente de paginao constri um registro de tipo LIDA. Seu campo de identificao de pgina contm o endereo da pgina cuja leitura foi solicitada; 3) gerente de paginao lana o registro na ata. QUANDO DA ESCRITA DE PGINA EM MEMRIA SECUNDRIA 1) gerente de paginao solicita ao sistema operacional local que esta pgina seja escrita na memria secundria; 2) se a operao bem sucedida, o gerente de paginao constri um registro de tipo ESCRITA em cujo campo de identificao de pgina coloca o endereo desta pgina; 3) gerente de paginao lana o registro na ata.

As operaes acima so simples o suficiente para dispensarem maiores explicaes no sentido de convencer o leitor de que constrem as cadeias desejadas. Alguns pontos, porm, devem ser observados. Em primeiro lugar, a operao de "fixar" a pgina na rea de trabalho tem por objetivo proibir que o gerente de paginao, ao executar seu algoritmo de substituio de pginas, envie para memria secundria uma pgina que estava no processo de ter seu contedo modificado. Desta forma, evitamos que pginas inconsistentes sejam lanadas em memria secundria. Em segundo lugar, estamos adotando uma pgina como o objeto de granularidade bsica para controle de integridade. Em outras palavras, a cadeia de ponteiros de pginas poderia ser refinada no sentido de que cada cadeia representasse aes que alteraram o valor de um simples objeto e no de uma pgina toda. Isto traz o inconveniente de que uma mesma pgina teria vrios ponteiros para a ata, um para cada objeto que acomodasse. De outra forma, no teramos acesso diretamente a partir da pgina modificada ao incio da cadeia de registros relativos a cada objeto, individualmente. Alm disto, sendo cada pgina a unidade bsica usada pelo sistema operacional local para trafegar entre a memria principal e a memria secundria, ao tentarmos seguir a cadeia de um objeto particular estaramos, na realidade, caminhando tambm pela cadeia de pginas correspondentes. Um terceiro ponto diz respeito a figura do executor de transaes. Lembre que, sendo o banco distribudo, uma mesma transao pode dar origem, durante sua fase de migrao, a vrios agentes locais em um mesmo n. Ao encadearem os registros de uma mesma transao, estes agentes devem ter um meio de se comunicar. S desta forma um particular agente pode ter notcia de onde se encontra o ltimo registro da ata instalado pelos demais, informao esta essencial se todos devem construir uma cadeia nica

para os registros desta transao. Estando no controle de todos os agentes locais da transao, o executor de transaes se apresenta como um veculo natural para distribuir esta informao. Um quarto aspecto diz respeito a operao de cancelar transaes. Note que as aes invocadas para inverter efeitos j instalados no BD no geram qualquer registro que vai para a ata. Note tambm como os ponteiros de ata referentes a cada pgina onde os efeitos da transao so removidos regridem a seus antecessores at que, eventualmente, voltam ao estado em que estavam antes da transao ter sido iniciada. Tambm vale um comentrio a respeito do protocolo bifsico para confirmar intenes. Quando um n responde ao coordenador com a mensagem de PREPARADO, deve garantir que os efeitos locais da transao podero ser confirmados ou cancelados de acordo com veredicto posterior que o coordenador enviar. Como estamos supondo que permitido escrever diretamente na ata em memria secundria, esta garantia automtica, uma vez que a ata registra tudo que se passa com cada transao. Finalmente, observe o ritual seguido pelo gerente de paginao durante as operaes de leitura e escrita de pginas. Ao execut-lo, este ltimo garante que os intervalos em que cada pgina estava na rea de trabalho estaro bem documentados na ata. Desnecessrio dizer que, uma vez iniciadas as operaes de escrita e leitura, o gerente de paginao probe que qualquer outro mdulo tenha acesso a pgina em questo antes que o respectivo registro seja instalado na ata e a pgina liberada. Danos causados s pginas em memria secundria durante as operaes de leitura e escrita configuram falhas secundrias e, portanto, esto fora da discusso, no momento. De posse destas novas capacidades, podemos iniciar a exposio do algoritmo principal. Antes de descrev-lo, porm, comentaremos a respeito das vrias facetas e sutilezas afetas ao problema de efetivar-se o controle de integridade no presente cenrio. A cada passo, a questo analisada e as aes do algoritmo justificadas, preparando ao leitor para aceitar seu posterior detalhamento. A Figura 9.5 ilustra alguns dos casos possveis. Os nmeros entre I e o instante da falha, este ltimo indicado por F, mostram a ordem temporal de ocorrncia dos vrios eventos. No instante I dispomos das seguintes informaes: 1) a identidade de cada transao que estava classificada como incompleta; 2) a identidade de cada transao que havia cancelado localmente, porm no globalmente; 3) a identidade de todas as transaes, junto com o respectivo estado de retorno, que estavam envolvidas na execuo do protocolo bifsico; 4) o endereo de toda pgina que estava na rea de trabalho da memria principal O processo todo , agora, precedido de uma nova fase preparatria. Em seguida embarcamos nas fases que j conhecemos, quais sejam: desfazer efeitos de aes elementares, refazer efeitos de aes elementares e, finalmente, instalar transaes junto ao executor de transaes local. Os pargrafos seguintes discutem cada uma destas fases em separado. Iniciamos com a nova fase preparatria onde buscamos dois resultados: 1) obter as listas TA, TC e TR, definidas como na subseo anterior; 2) construir uma lista PG que reflita as pginas que estavam na rea de trabalho da memria principal no instante da falha

T1 T2
3

canc-local
8

T3
10 14

T4

pronto-no canc-local canc-local

coletando T5
4

confirmando

confirmao

canc T6
1

T7
5

12

ativo
9

pronto-sim T8
11 13 15

coletando T9 pronto-sim

canc-local canc

canc

Tempo

I
Figura 9.5 - Transaes e o Instante da Falha

Nesta fase, as transaes incompletas precisaro ser acumuladas em TA. No esquema da subseo anterior isto no era necessrio, pois as transaes incompletas eram detectadas usando-se o fato de que no pertenciam as listas TA ou TC. Para diferenciar este tipo de transao em TA, vamos marc-las como "incompletas", em adio as marcas de "local" e "global" que j vnhamos usando. O segundo item que desejamos construir nesta fase muito fcil de ser obtido. Basta ler os registros da ata uma nica vez, desde I at F. Durante esta mesma passada, podemos construir as listas TA, TC e TR. Note que agora estamos construindo as listas TA, TC e TR a medida que caminhamos na ata da esquerda para a direita. Para ilustrar o processo, tome a ref refid=9e.. Suponha que, de posse das informaes iniciais a respeito das vrias transaes ativas no ponto I, as listas sejam iniciadas como segue:

TA = { (T1 , I ) , ( T2 , I ) , (T5 , L ) , ( T6 , L ) } TC = { T9 } TR = {T5 , T9 } Estamos adotando as seguintes simplificaes de notao. Em relao aos itens da lista TA, as marcas de "incompleta", "local" e "global" sero indicadas por I, L e G, respectivamente. Dispensamos a indicao do estado de retorno nos elementos de TR, pois so irrelevantes nesta fase. Observe que, de incio, no temos informao a respeito de quais transaes confirmaram em pontos anteriores a I. Assim, a lista TC iniciada apenas com transaes que, no ponto I, pertencem a classe de transaes confirmando. Toda a mecnica desta fase se resume na idia de que, medida que formos encontrando os vrios registros na ata, as listas mudam de "estado". Cada uma destas mudanas de "estado" acarretar alteraes no contedo das trs listas. Os dois primeiros eventos a considerar esto indicados pelos pontos 1 e 2 na figura. Nestes instantes, as transaes T7 e T4 iniciam suas execues locais. Este fato detectado quando os correspondentes registros tipo INCIO so encontrados na ata. A ao tomada incluir ambas as transaes em TA, marcadas como "incompletas", refletindo o novo "estado" das listas. Ficamos com TA = { (T1 , I ) , (T2 , I ) , (T5 , L ) , (T6 , L ) , ( T7 , I ), (T4 , I ) } TC = { T9 } TR = { T5 , T9 } Note que, neste ponto da ata, T4 e T7 so classificadas como transaes incompletas. Este fato refletido na ao de coloc-las em TA. Em seguida, T2 cancela localmente. Forosamente, deve estar em TA. Em conseqncia, sua marca mudada para "local". O prximo evento indica que T5 cancela globalmente. Portanto estava em TR e ainda em TA ou TC. Basta retirar T5 de TR e tambm de TC, se l estiver. Em adio, T5 deve ser colocada em TA. Se T5 j estiver em TA, basta trocar sua marca para "global". Caso contrrio, devemos inseri-la em TA, marcando-a como "global". As lista agora tem a forma: TA = { ( T1 , I ) , (T2 , L ) , (T5 , G ) , (T6 , L ) , (T7 , I ) , (T4 , I ) } TC = { T9 } TR = { T9 } Na marca do ponto 5, T8 colocada em TA, marcada como "incompleta". Nos pontos 6 e 7, T4 e T7 so inseridas em TR, uma vez que l no se encontravam. No ponto 8, T3 acrescentada a lista TA como "incompleta". Agora as listas seriam na forma: TA = { ( T1 , I ) , (T2 , L ) , (T5 , G ) , (T6 , L ) , (T7 , I ) , (T4 , I ) , (T3 , I ) , (T8 , I ) } TC = { T9 } TR = { T9 , T4 , T7 }

No ponto 9, T8 inserida em TR. O registro no ponto 10 indica que o estado de retorno de T4 deve ser alterado em TR. Mais ainda, T4 deve agora ir para a lista TC. No ponto 11, T9 eliminada de TC e de TR, sendo colocada em TA como "global". Neste momento, teramos : TA={( T1 , I ) , (T2 , L ) , (T5 , G ) , (T6 , L ) , (T7 , I ) , (T4 , I ) , (T3 , I ) , (T8 , I ) , (T9 ,G )} TC = { T4 } TR = { T9 , T4 , T7 , T8 } Confiamos que o leitor possa efetuar as mudanas indicadas pelos pontos 12, 13, 14 e 15, obtendo o resultado final: TA = { (T1 , I ) , (T2 , L ) , (T5 , G ) , (T6 , L ) , (T3 , I ) , (T8 , G ) , (T9 , G ) } TC = { T4 , T7 } TR = { T7 } A fase seguinte deve remover os efeitos de todas as transaes que no momento da falha eram classificadas como incompletas ou canceladas. Estas transaes j foram identificadas na fase preparatria e esto acumulada na lista TA. Tudo que temos a fazer, portanto, ler a ata do fim para o comeo. Sempre que encontrarmos um registro tipo EXECUO, referente a uma transao que est em TA, os efeitos da correspondente ao elementar invertido. O processo estar completo quando j analisamos os registros de todas as transaes em TA. Para detectar esta condio, cada elemento de TA receber uma segunda marca. Antes de iniciarmos, as transaes em TA so marcadas "no_examinadas" sem prejuzo da marca que j detinham. Transaes em TA so remarcadas "examinadas" quando atingimos os correspondentes registros tipo INCIO. Portanto, esta segunda fase estar completa quando todas as transaes em TA estiverem marcadas "examinadas". Vamos considerar, primeiro, o caso de transaes que, como T1 e T8 na figura anterior, so classificadas como incompletas no instante da falha. Seja T uma transao deste tipo e seja P uma pgina qualquer do BD de tal sorte que T invocou aes que modificaram objetos em P. Tudo que podemos contar com a cpia de P que residia na memria secundria no instante da falha e, por conseguinte, suporemos que P encarne esta cpia. Seja Y o endereo indicado pelo ponteiro de ata em P. Dependendo do instante em que P foi enviada para a memria secundria pela ltima vez, Y pode apontar para um ponto antes ou depois do marco I. A primeira situao mostrada na Figura 9.6. Os registros Z1 a Z7 representam os registros da ata que modificaram valores de objetos em P. O registro R1 indica o incio da transao T. A cadeia de ponteiros ligando os registros Zi aquela obtida a partir dos ponteiros de pgina. Formam, portanto, uma cadeia completa de registros que alteraram valores de objetos que residem em P. Se assumirmos que durante a fase de execuo no so bloqueados objetos internos a uma pgina ento, devido ao principio de no interferncia entre aes de transaes que ainda no completaram, todos os registros entre Z1 e Z7 teriam sido gerados por T. Se este no for o caso, aqueles registros poderiam corresponder a vrias transaes. A cadeia de ponteiros de transao de T pode, evidentemente, passar por outros registros alm daqueles indicados pelos Zi's.

R1

Z7

Z6
4 3

Z5
2

Z4
1

Z3

Z2

Z1

ATA

incio

Tempo

falha

Figura 9.6 - Desfazendo Aes de uma Transao Incompleta O valor inicial do ponteiro de ata de P aponta para Z4. Isto significa que o gerente de paginao elegeu por reescrever P na memria secundria entre os instantes marcados por Z4 e Z3. Como a transao no chegou a completar, os efeitos de Z1 a Z3 foram automaticamente desfeitos quando o contedo da memria principal foi perdido. Os efeitos de Z4 a Z7, porm, tm que ser desfeitos pois j foram registrados na memria secundria. Este objetivo fcil de ser alcanado percorrendo a ata da direita para a esquerda. Ao atingir Z1, comparamos o valor do endereo deste registro com o ponteiro da ata de P e descobrimos que Z1 est a direita daquele ltimo. Isto indica que Z1 s foi lanado na ata aps a ltima vez que P foi reescrita na memria secundria. Podemos, portanto, ignorar Z1 uma vez que a ao elementar que descreve j est, automaticamente, desfeita. Ignorando Z1, passamos a analisar os registros entre Z1 e Z2. Estes dizem respeito a outras pginas, diferentes de P. Aps completarmos suas anlises, chegamos a Z2. O mesmo ritual se repete, sendo Z2 tambm ignorado. Prosseguindo, alcanamos Z3, ignorando-o. Ao chegarmos a Z4, porm, o ponteiro de ata de P indica o prprio Z4. Neste caso, o efeito da ao correspondente a Z4 desfeito. Em seguida, o ponteiro de ata de P modificado para Z5, o prximo registro que alterou valores em P, indicado pelo ponteiro de pgina do registro em Z4. Isto indicado pela seta na posio 2 na Figura 9.6. Aps processar os registros entre Z4 e Z5, chegamos a este ltimo. Os mesmos passos seriam repetidos, desfazendo-se os efeitos da ao correspondente a Z5 e colocando-se o ponteiro de P a apontar para Z6. Este ltimo, e em seguida Z7, sofreriam sorte igual, tendo os efeitos das respectivas aes elementares tambm removidos. Finalmente, quando alcanamos o ponto R1, o registro de INCIO de T analisado. Neste momento, o processamento relativo a transao T estaria completo. Em conseqncia, T marcada como "examinada" em TA. claro que os registros que aparecem na ata entre aqueles mostrados na figura estariam guiando processos similares, dependendo do estado da respectiva transao no instante da falha. Observe tambm que a posio de I imaterial para o desenrolar do algoritmo.

R1

Z7

Z6

Z5

Z4

Z3

Z2

Z1

R2

ATA

incio

cancelamento

Tempo

falha

Figura 9.7 - Desfazendo Aes de uma Transao Cancelada - I

A mecnica usada para desfazer aes elementares consiste em substituirmos o valor do objeto presente em P por aquele indicado pelo campo de valor final do registro na ata. Em vista disto, poderamos ser tentados a percorrer a ata e apenas inverter o efeito do ltimo registro de cada transao. Note, porm, que registros diferentes podem estar se referindo a objetos de P que so distintos. Desta forma, no obteramos o mesmo resultado se ignorssemos Z4, Z5 e Z6, desfazendo apenas os efeitos relativos a ao de Z7. Isto seria satisfatrio unicamente no caso em que a noo de pgina e objeto do BD coincidissem. Mas, nesta hiptese, seramos forados a manter campos de valor inicial e valor final de tamanhos avantajados em todo registro tipo EXECUO. Sendo este tipo de registro o mais comum, o estratagema poderia custar bastante caro em termos de espao disponvel na ata. A alternativa, j mencionada, de termos um ponteiro de ata para cada objeto da pgina implica em menos espao disponvel para dados em cada pgina do BD, em troca de alguma economia durante a fase de recuperao de falhas. Em contrapartida, esperamos, falhas devem ocorrer apenas raramente. Em resumo, o esquema de um ponteiro por pgina parece acomodar uma boa soluo de compromisso. Ainda nesta fase de remover efeitos, vamos considerar o caso de transaes canceladas, tanto local quanto globalmente. No faremos distino entre estes dois tipos de transaes, pois ambas apresentam a caracterstica comum de j terem tido seus efeitos removidos no passado. A Figura 9.7 repete o cenrio para este tipo de transao. As nicas diferenas residem nos fatos de que h um registro de tipo CANCELAMENTO, ou CANC_LOCAL, indicado pelo ponto R2 e podem haver, tambm, outros registros que manipulam objetos de P direita de R2. Estamos assumindo que P foi reescrita para a memria secundria antes de ser lanado em ata o registro de cancelamento da transao. Assim, o cenrio ilustrado na ltima figura pode ter ocorrido de dois modos:

R1

Z7

Z6

Z5

Z4

Z3

Z2

Z1

R2

ATA

incio

cancelamento

Tempo

falha

Figura 9.8 - Desfazendo Aes de uma Transao Cancelada - II gerente de paginao elegeu por reescrever P para a memria secundria em algum instante entre o lanamento na ata dos registros Z4 e Z3 isto , antes que a deciso de cancelar T fosse tomada; o gerente de paginao resolveu reenviar P para a memria secundria aps a deciso de cancelamento ter sido adotada, isto , quando o agente local de T estava desfazendo os efeitos de suas aes elementares. Mais precisamente, no instante em que estvamos lendo a ata, da direita para a esquerda, entre os registros Z3 e Z4, no af de percorrer a cadeia de ponteiros de transaes de T e desfazer seus efeitos.

Em ambos os casos, o gerente de paginao enviou P para a memria secundria pela ltima vez antes do lanamento na ata do registro tipo CANCELAMENTO ou CANC_LOCAL. Na primeira hiptese, Z1 a Z3 caracterizariam modificaes referentes a uma transao que foi cancelada e que no foram tornadas permanentes em memria secundria. Podem, portanto, ser ignoradas. J Z4 a Z7 indicariam aes cujos efeitos teriam que ser removidos. Na segunda hiptese, temos situao semelhante. Apenas que o trabalho de instalar e remover os efeitos das aes indicadas por Z1 a Z3 foi efetuado em memria principal, sendo, portanto, desperdiado. De qualquer forma, os efeitos dos registros correspondentes de Z4 at Z7 so os nicos que precisam ser desfeitos, exatamente como no caso de transaes incompletas. O procedimento, portanto, inteiramente anlogo. Vale a pena, ainda com relao a transaes canceladas, examinar a Figura 9.8 onde ilustrada a situao que se configuraria quando o gerente de paginao envia P a memria secundria aps o registro de tipo CANCELAMENTO, ou CANC_LOCAL, ter sido lanado na ata. Ao desfazermos os efeitos das aes referentes a T, os ponteiros de pgina regridem na ata, produzindo o efeito indicado na figura. Durante a fase de recuperao, caminhamos da direita para a esquerda pela cadeia de ponteiros de pgina relativos a P. Em conseqncia, passaremos do ponto indicado por A diretamente para aquele indicado por B. Isto acarretar com que todos os registros relativos a T sejam ignorados como era de se esperar, uma vez que a operao de remover efeitos teve chance de completar e passar a memria secundria.

R1

Z4

Z3

Z2

Z1

R2

ATA

incio

lida

cancelamento

Tempo

min I falha

Figura 9.9 - Transaes que cancelaram antes do balizador. Observe que devemos analisar todos os registros da ata referentes a transaes de TA. Assim procedendo, poderemos ser forados a ler a ata at um ponto bem anterior aquele indicado por I. Este fato evidente na Figura 9.5. Entretanto, os problemas desta fase no findam aqui. Para visualizar que tipo de problemas podem surgir, considere a lista TA obtida ao final da fase preparatria. Suponha que MIN indique a posio da ata onde se situa o registro mais antigo dentre todos aqueles registros referentes a transaes presentes em TA. Lembre que o fim da segunda fase indicado quando em TA no mais podemos encontrar transaes marcadas "no_examinadas". Assim, MIN indica o ltimo registro da ata que ser analisado durante esta fase. Assuma que P uma pgina do BD que foi lida para a memria principal em um momento L, anterior aquele indicado por MIN. Assuma tambm que P no foi subsequentemente reescrita em memria secundria. Seja T uma transao que cancelou antes de I e aps L. Em conseqncia, se T invocou, antes de L, aes elementares que modificaram valores de objetos em P e estas aes tero que ser, portanto, invertidas. Mas T, tendo cancelado antes de I, no aparece em TA. Mais ainda, a segunda fase terminaria ao atingirmos o ponto MIN. Antes, portanto, de sequer atingirmos o ponto de cancelamento de T e, por razo mais forte, antes de invertermos os efeitos de qualquer de suas aes elementares. Considere a Figura 9.9, onde I, MIN e o instante da falha esto claramente indicados. A marca L indica a posio do registro tipo LIDA mais antigo relativamente a todas as pginas que estavam na rea de trabalho durante o instante da falha. Tambm esto marcadas as posies dos registros de uma transao T que iniciou e foi cancelada antes de MIN. Deveramos parar de regredir na ata ao alcanarmos o ponto indicado por MIN e, portanto, as aes relativas aos registros Z4 e Z3 no teriam seus efeitos removidos. No entanto, P foi lida para a memria principal no instante indicado por L e nunca mais foi reescrita em memria secundria. O trabalho de desfazer os efeitos das aes relativas aqueles registros foi perdido quando o contedo de P ficou inutilizado pela falha. Sanar esta situao, porm, fcil. Basta que continuemos a regredir na ata, mesmo aps a lista TA s conter transaes marcadas "examinadas", at que tenhamos alcanado o ponto

L. Assim procedendo, o registro R2 indicando o cancelamento de T seria atingido antes de chegarmos a L. Neste instante, T seria adicionada a TA garantindo, desta forma, que iremos ler a ata at, pelo menos, o ponto indicado por R1, ou seja, a posio na ata do primeiro registro referente a T. Resumindo, a condio de parada para esta fase dita que devemos interromper o processo apenas no caso de: 1. TA no mais conter transaes marcadas "no_examinadas" e 2. j termos passado o ponto onde a pgina mais antiga, dentre todas que estavam na rea de trabalho, foi lida para a memria principal pela ltima vez antes da falha. Observe que este processo pode nos levar a regredir na ata alm do ponto L. Entretanto o processo no ser cascateado indefinidamente. Uma vez que tenhamos passado pelo ponto L, no mais adicionaremos transaes a TA. Apenas remarcaremos transaes de "no_examinadas" para "examinadas". Desta forma, em algum ponto, chegaremos a situao onde TA contm apenas transaes marcadas "examinadas", terminando a segunda fase. Durante a terceira fase, devemos refazer efeitos de todas as transaes que devem confirmar isto , que esto na lista TC, j compilada na fase preparatria. A primeira pergunta que surge diz respeito ao ponto da ata onde devemos iniciar esta fase. Note que s so perdidos os contedos das pginas que estavam na rea de trabalho quando do instante da falha. Assim, nada mais justo que iniciar a operao de refazer efeitos a partir do momento em que foi lida a pgina mais antiga que permanecia na rea de trabalho no instante da falha. Mais ainda, podemos ignorar todos os registros de EXECUO que indiquem pginas que no estavam na rea de trabalho neste instante. E as pginas que estavam na rea de trabalho so conhecidas pois foram determinadas na fase preparatria. Todo efeito sobre pginas que residiam na memria secundria no instante da falha est automaticamente garantido. Usando os mesmos personagens que das vezes anteriores, uma situao tpica mostrada na Figura 9.10. A nica diferena est no fato de termos substitudo a marca I pela marca L. Lembre que L indica onde se situa o registro tipo LIDA mais antigo relativamente a todas as pginas que estavam na rea de trabalho no instante da falha. Na figura, a ltima vez que o gerente de paginao remeteu a pgina P para a memria secundria foi em algum ponto entre Z4 e Z3. Assim, os efeitos de Z3 a Z1 foram perdidos e devem ser recuperados. J os efeitos de Z7 a Z4 foram conservados e no precisam ser refeitos. Lembre, outrossim, que nesta fase estamos lendo a ata da esquerda para a direita, em sentido inverso, portanto, que quando da fase anterior. Caminhando a partir de L em direo ao final da ata, ignoramos os registros Z6 a Z4. O primeiro registro que encontraremos e que no pode ser ignorado Z3. Esta condio detectada quando o ponteiro de ata em P e o ponteiro de pgina do registro em exame apontam para o mesmo local da ata, no caso Z4. O efeito da ao elementar correspondente reinstalado em P e, em seguida, o ponteiro de ata de P deslocado para este mesmo registro ora em considerao, Z3 no caso. Isto indicado na figura pela seta nmero 2. Prosseguindo, leramos os registros entre Z3 e Z4 tomando as medidas cabveis em cada caso. Quando chegssemos a Z2, a situao anterior se repetiria. Os efeitos da ao indicada em Z2 seriam refeitos e o ponteiro de pgina de P passaria a indicar Z2. Em seguida, viria Z1 e, finalmente, atingiramos R2 quando registros desta transao deixariam de aparecer na ata. Neste ponto, as aes elementares de T teriam sido reinstaladas no BD.

R1

Z7

Z6

Z5

Z4
1

Z3
2

Z2
3 4

Z1

R2

ATA

incio

confirmao

Tempo

falha

Figura 9.10 - Refazendo Aes de uma Transao Que Deve Confirmar A fase final reinstala as transaes de TR junto ao executor de transaes local e no demanda maiores comentrios. Antes de detalhar a descrio do algoritmo, valem aqui algumas observaes que permitiro agilizar ainda mais sua execuo. Considere a fase onde so reinstalados os efeitos de transaes que devem confirmar. Seja T uma destas transaes. Suponha que estamos examinando um registro de T tipo EXECUO e cuja posio indicada por Z. A pgina indicada por Z, seja P, deve estar na lista de pginas compiladas na primeira fase, do contrrio o registro indicado por Z seria ignorado. De acordo com o que foi exposto anteriormente, precisamos comparar Z com o ponteiro de ata de P. Para este fim, se P no estiver neste momento na rea de trabalho, deve ser obtida a partir da memria secundria. Podemos, em certos casos, economizar esta eventual operao de leitura. Seja PG a lista de pginas que esto na rea de trabalho da memria principal no instante da falha. Assuma que, junto com a indicao de que P est em PG, disponhamos tambm de uma indicao, X, do local na ata onde se encontra o registro tipo LIDA referente a P. Comparamos X e Z. Se concluirmos que Z indica uma posio anterior quela indicada por X, ento o registro referente a Z pode ser sumariamente ignorado. Est claro que, quando ocorreu a falha, o efeito relativo a ao indicada por Z estava a salvo em memria secundria. Mais ainda, determinamos este fato sem apelar para o contedo de P, evitando uma possvel leitura de pgina para a memria principal. Reconsidere agora a segunda fase, quando devemos desfazer os efeitos das transaes de TA. Vamos indicar em que situaes poderemos dispensar leituras suprfluas de pginas do BD. Seja T uma transao de TA que seria classificada como incompleta no instante da falha. Ainda denotaremos por Z a posio de um registro de T e por X a posio do registro tipo LIDA referente a P. Se X aparecer aqum de Z na ata, ento P no foi reescrita em memria secundria aps ter seu contedo modificado pela ao elementar descrita pelo registro Z. Poderemos, portanto, ignorar Z. Por fim, assuma que T uma das transaes de TA que cancelou, local ou

globalmente, antes da ocorrncia da falha. Lembre que, quando a deciso de cancelar T tomada, tambm feito um esforo no sentido de desfazer os efeitos de suas aes elementares. Seja Y a posio da ata onde se situa o registro tipo CANCELAMENTO, ou CANC_LOCAL, referente a T. Se Y estiver aqum de X na ata, ento P foi reescrita na memria secundria aps desfazermos todos os efeitos de T. Conclumos que Z pode, de novo, ser ignorado. Como uma ltima observao, note que, para completar as trs primeiras fases, percorremos a ata apenas trs vezes. Na primeira fase percorremos a ata da esquerda para a direita desde I at seu final. A segunda fase l a ata da direita para a esquerda comeando por seu fim e prosseguindo at um certo ponto aqum do local indicado por L. A terceira e ltima fase que usa a ata, varre-a da esquerda para a direita. Comea no ponto onde a fase anterior parou e procura o ponto L. De L, vai at o final da ata. Este sincronismo de direes especialmente til se a ata, ou parte dela, residem em fita magntica. Aps estas consideraes, podemos passar a descrio do algoritmo. Estamos assumindo que dispomos de: 1. um ponteiro para a ata, I ; 2. a identidade de cada transao que estava incompleta no ponto indicado por I ; 3. a identidade de cada transao que havia cancelado localmente, porm no globalmente, no instante mostrado por I. Alm disto, sabemos em que posio da ata est o registro de CANC_LOCAL de cada uma destas transaes; 4. a identidade de todas as transaes, junto com o respectivo estado de retorno, que estavam envolvidas na execuo do protocolo bifsico, no momento apontado por I ; 5. o endereo de toda pgina que estava na rea de trabalho da memria principal, no instante indicado por I. Tambm conhecemos a posio na ata onde est o registro tipo LIDA para cada uma destas pginas. Os elementos na lista TA podero receber dois tipos de marcas: "incompleta"/"local"/"global" ou "examinada"/"no_examinada". Os elementos da lista PG tero associado a si um ponteiro para a ata. O mesmo pode acontecer para os elementos de TA. No caso de falha primria os seguintes passos so executados FASE PREPARATRIA: 1) a partir das informaes presentes em I, inicie as listas TA, TC, TR e PG ; 2) marque toda transao em TA como "incompleta" ; 3) partindo do ponto indicado por I, examine cada registro at o fim da ata. Seja R o prximo registro a ser examinado. Se o tipo de R for a) INCIO: i) adicione esta transao a lista TA, marcando-a como "incompleta" ; b) CONFIRMAO: i) retire esta transao da lista TR ; ii) coloque esta transao na lista TC ;

c) CANCELAMENTO: i) retire esta transao de TR ; ii) se esta transao est em TC, retire-a desta lista ; iii) se esta transao (1) est em TA, remarque-a como "global" ; (2) est em TA, adicione-a a TA e marque-a como "global" ; (3) associe a mesma um ponteiro para a presente posio da ata ; d) CANC_LOCAL: i) remarque esta transao em TA como "local" ; ii) associe a esta transao um ponteiro para esta posio da ata ; e) TRMINO: i) se o estado de retorno de R for PRONTO_SIM ou CONFIRMANDO, inclua esta transao em TC junto com o respectivo estado de retorno; ii) em qualquer outro caso: (1) se esta transao no est em TR, deve ser l includa, junto com o estado de retorno indicado no registro R ; (2) se esta transao j est em TR, deve ter seu estado de retorno substitudo por aquele indicado por R ; f) LIDA: i) inclua esta pgina em PG, associando a esta pgina a posio do registro R ; g) ESCRITA: i) retire esta pgina da lista PG ; h) EXECUO: i) ignore este registro DESFAZENDO EFEITOS DE AES ELEMENTARES: 1) marque cada transao em TA como "no_examinada" ; 2) seja L o ponto da ata onde se situa o registro tipo LIDA mais antigo relativamente a todas as pginas em PG ; 3) partindo do fim da ata, caminhe em direo ao comeo da mesma, examinando cada registro que encontrar. Prossiga at que todas as transaes em TA estejam marcadas "examinada", e j tenha passado o ponto indicado por L. Seja Z o prximo registro a ser examinado, seja T a transao a que se refere o registro Z e seja P a pgina a que se refere a ao indicada pelo registro Z. Se o tipo de Z for: a) CONFIRMAO, TRMINO, LIDA ou ESCRITA: i) ignore este registro;

b) INCIO: i) se esta transao estiver em TA, remarque-a como "examinada" ; c) CANCELAMENTO: i) se j tivermos passado o ponto indicado por I e ainda no atingimos o ponto indicado por L, ento adicione esta transao a TA, marcando-a como "global" e "no_examinada" ; ii) em TA, associe o ponto da ata indicado pelo registro Z a esta transao ; d) CANC_LOCAL: i) se j tivermos passado o ponto indicado por I e ainda no atingimos o ponto indicado por L, ento adicione esta transao a TA, marcando-a como "local" e "no_examinada" ; ii) em TA, associe o ponto da ata indicado pelo registro Z a esta transao e) EXECUO: i) se T no est em TA, ignore Z ; ii) ignore Z se T est em TA e T no est marcada como "incompleta" e P no est em PG ; iii) se P est em PG, seja X o ponteiro associado a P em PG. Ignore este registro se T est em TA e (1) T est marcada "incompleta e X indica uma posio anterior aquela indicada por Z ou (2) T no est marcada "incompleta" e Y indica uma posio anterior aquela indicada por X, onde Y o ponteiro associado a T em TA iv) se este registro no foi ignorado e P no est na rea de trabalho, ento leia P para a memria principal. Seja W o valor do ponteiro de ata de P : (1) se W indicar uma posio anterior aquela assinalada por Z, ignore este registro; (2) caso contrrio: (a) desfaa em P os efeitos da ao elementar contida em Z (b) substitua em P o valor do ponteiro de ata por aquele indicado pelo ponteiro de pgina presente no registro Z . REFAZENDO EFEITOS DE AES ELEMENTARES: 1) A partir de L, caminhe em direo ao fim da ata examinando cada registro que encontrar. Seja Z o prximo registro a ser examinado, seja T a transao a que se refere o registro Z e seja P a pgina a que se refere a ao indicada pelo registro Z. Se o tipo de Z for a) INCIO, CONFIRMAO, CANCELAMENTO, CANC_LOCAL, TRMINO, LIDA, ESCRITA: ignore este registro ; b) EXECUO: i) se T no est em TC ou P no est em PG ento ignore este registro ;

ii) caso contrrio, seja X a posio da ata associada a P em PG : (1) se Z indicar uma posio de ata anterior a X, ento ignore este registro ; (2) caso contrrio, seja W a posio da ata indicada pelo ponteiro de ata de P. Prossiga como segue: (a) se W indicar uma posio da ata anterior aquela assinalada pelo ponteiro de pgina de Z, ento ignore este registro ; (b) se W indicar uma posio da ata idntica aquela assinalada pelo ponteiro de pgina de Z, ento : (i) reinstale em P os efeitos da ao elementar indicada em Z ; (ii) substitua o valor do ponteiro de ata de P pelo valor de Z ; INSTALANDO TRANSAES JUNTO AO EXECUTOR DE TRANSAES LOCAL: 1) para cada transao T da lista TA : a) se T est marcada como "global", ignore T ; b) se T est marcada como "incompleta" : i) envie uma mensagem de resposta ao no coordenador de T com campo de veredicto contendo CANCELADO ; ii) crie um registro tipo CANC_LOCAL para T e instale-o no final da ata ; iii) instale T na tabela do executor de transaes local com a ressalva de que T cancelou localmente ; 2) para cada transao T da lista TR : a) instale T na tabela do executor de transaes local indicando seu estado de retorno : b) informe ao executor de transaes local para reiniciar a execuo do protocolo bifsico em favor de T, partindo deste estado.

Os passos do algoritmo seguem fielmente a discusso anterior e, portanto, j esto devidamente comentados. 9.1.4 O Mecanismo Completo Na subseo anterior, fizemos duas hipteses que sero agora removidas. Em primeiro lugar, devemos relaxar a suposio irreal de que podemos inserir registros na ata diretamente em memria secundria, isto , sem que a respectiva pgina seja trazida para a rea de trabalho da memria principal. Em segundo lugar, devemos indicar como podemos obter informao suficiente para iniciar a fase preparatria. Isto pressupe conhecimento do ponto I, como discutido na seo anterior. Mais ainda, devemos obter tambm as demais informaes necessrias no que diz respeito ao estado de transaes e pginas no ponto I. Uma vez que estas duas hipteses sejam relaxadas, o processo se tornaria autnomo. Finalizaremos esta subseo com alguns comentrios cerca de falhas secundrias.

9.1.4.1 Pginas da Ata em Memria Principal Vamos agora relaxar a hiptese de que podemos escrever na ata, diretamente em memria secundria. O perigo, naturalmente, est em que parte da rea de trabalho ser ocupada pelas pginas mais recentes da ata. Uma falha primria no sistema destruiria, portanto, informao que faz parte da ata. Entretanto, no h como evitarmos a perda do contedo da memria principal. Resta-nos uma nica sada: evitar que sejam destrudas aquelas informaes que so vitais para o processo de recuperao. Para perceber claramente que tipo de informao crucial ou irrelevante no momento de recuperao, vamos analisar o caso, tpico, de uma transao que seria classificada como incompleta quando o sistema falhou. Ser necessrio desfazer os efeitos das aes elementares que j foram invocadas em benefcio desta transao. Antes, isto era sempre possvel pois a ata estava a salvo em memria secundria. Agora, no podemos ter como garantido que as informaes da ata de que necessitaremos estaro disponveis. Seja T uma transao nestas condies e considere seguinte seqncia de aes 1) T iniciada ; 2) aes elementares de T modificam o contedo de uma pgina de memria, P. Uma outra pgina, Q, recebe os registros referentes as mudanas efetivadas por T em P ; 3) o gerente de paginao decide reenviar P a memria secundria. 4) o sistema falha. Como T uma transao incompleta e a cpia da pgina P j foi enviada memria secundria, as modificaes instaladas por T em P devem ser removidas. Para efetivar esta mudana precisamos ler a verso da pgina Q onde esto os registros necessrios para desfazermos os efeitos de T sobre P. Acontece que o gerente de paginao local no reinstalou Q na memria secundria antes da falha e, portanto, a verso de Q que l reside est desatualizada. Em particular, os registros referentes a T de que necessitamos foram perdidos. Neste ponto no poderemos mais recuperar a consistncia do BD. Devemos, portanto, impedir que pginas do BD sejam enviadas a memria secundria antes de para l enviarmos as pginas da ata que contm os registros de modificaes que afetam o contedo destas mesmas pginas do BD. neste ponto que os mecanismos de controle de integridade usaro da prerrogativa de forar a escrita de pginas em memria secundria, revelia do algoritmo de substituio de pginas usado pelo gerente de paginao. O ponto crucial a observar que devemos garantir que todos os registros da ata, referentes a mudanas no contedo de uma particular pgina do BD, estejam a salvo em memria secundria antes de enviarmos para l esta pgina do BD. Note que no h mal algum em forarmos certas pginas da ata, como Q na discusso acima, para a memria secundria e o sistema venha a falhar antes de serem escritas as correspondentes pginas do BD, como P. Neste caso, ao se recuperar, o sistema simplesmente inverteria algumas aes elementares registradas em Q que nem chegaram a fazer parte do BD em memria secundria, pois o contedo mais recente de P onde foram instaladas estas modificaes destrudo pela falha. A rigor, no seria necessrio desfazer tais efeitos que nem chagaram a ser salvos. Por outro lado, no causa qualquer inconvenincia se assim o fizermos.

Considere agora o caso de uma transao que cancelou antes do instante em que ocorreu a falha. O problema o mesmo do caso anterior, ou seja, como garantir que informaes essenciais no se percam com as pginas da ata que esto na rea de trabalho no momento da falha. Por um raciocnio anlogo, ser suficiente que tenhamos o cuidado de forar para memria secundria todos os registros anteriores desta transao, antes de lanarmos na ata o registro de tipo CANCELAMENTO, ou CANC_LOCAL, da correspondente transao, Assim procedendo, garantimos que estas informaes podero ser recuperadas na eventualidade de falhas. Se o sistema falha quando estamos forando os registros da ata para a memria secundria, a transao tratada como incompleta pelo processo de recuperao, sem problemas. No caso de uma transao que j confirmou, devemos refazer os efeitos de suas aes elementares. Agora devemos garantir que todos os registros relativos a esta transao esto a salvo em memria secundria antes de lanarmos na ata o registro de tipo CONFIRMAO relativo a esta transao. Assim, sempre poderemos refazer seus efeitos aps uma falha primria. De novo no h dano se uma falha colhe o sistema no ato de forar estes registros para a memria secundria e antes de lanarmos o registro de tipo CONFIRMAO. Se esta eventualidade ocorrer, o sistema tratar esta transao como incompleta ao se recuperar. Como j vnhamos observando o protocolo de salvar na ata todos os registros referentes a mudanas em qualquer pgina do BD que enviada a memria secundria, sempre poderemos desfazer os efeitos de todas as aes elementares desta transao, agora tratada como incompleta, que porventura j tenham sido instalados em memria secundria pelo gerente de paginao. esta ao, de resguardar os registros essenciais desta transao, que cada n remoto deve efetuar ao receber a mensagem de PREPARE-SE vinda do coordenador durante e execuo do protocolo bifsico para confirmar intenes invocado quando do trmino da transao. S no caso de conseguir levar a cabo com sucesso esta operao que o n remoto deve responder PREPARADO e lanar na ata o registro correspondente, no caso PRONTO_SIM. Desta forma, estar apto a confirmar ou cancelar os efeitos da transao em qualquer circunstncia futura, dependendo do veredicto final do coordenador. No caso de falhar a operao de resguardar os registros na ata, relembrando, o n remoto enviaria mensagem de IMPOSSIBILITADO, registrando na ata PRONTO_NO. Observe que necessrio forar apenas as pginas da ata e no as pginas do BD que so tocadas pela transao. Estas ltimas podero sempre ser recuperadas se garantirmos a sade da ata a cada instante. Forar registros da ata para a memria secundria uma tentativa de nos aproximarmos da condio ideal onde podemos escrever na ata diretamente em memria secundria. Em resumo, o gerente de paginao e o gerente de transaes interagem de forma tal que 1) antes que o gerente de paginao remeta uma pgina do BD para a memria secundria, todos os registros da ata que modificaram valores de objetos contidos nesta pgina devem seguir para a memria secundria; 2) antes que seja lanado na ata um registro tipo CONFIRMAO, CANCELAMENTO ou CANC_LOCAL para uma dada transao, todos os registros anteriores da ata, referentes a esta mesma transao, devem ser forados a seguirem para a memria secundria. A seguir vamos indicar as mudanas que devem ser acomodadas quando do incio, migrao e trmino de transaes, bem como nas rotinas de leitura e escrita de pginas. O algoritmo bsico

para efetivar o controle de integridade, apresentado na subseo anterior, continua valendo. Apenas vamos, agora, garantir que as informaes da ata de que necessita estaro realmente disponveis conforme suposto. INCIO DE TRANSAO: 1) inalterado em relao ao processo descrito anteriormente; EXECUO DE TRANSAO: 1) inalterado em relao ao processo descrito anteriormente; CONFIRMAO DE TRANSAO 1) todas as pginas da rea de trabalho que contm registos relativos a esta transao e que ainda no foram salvas na memria secundria devem ser foradas para a memria secundria neste ponto; 2) um registro, tipo CONFIRMAO, construdo para esta transao em memria principal pelo seu agente local. Os campos deste registro contm: a) identificao: recebe a identificao da transao, b) endereo: ignore c) valor inicial: ignore d) valor final: ignore e) ponteiro de pgina: colocado o valor do ponteiro da ata presente nesta pgina f) ponteiro da transao: inserido o endereo do ltimo registro que o executor de transaes instalou na ata em favor desta transao; 3) este registro lanado na ata CANCELAMENTO DE TRANSAO 1) obtenha do executor de transaes o endereo da ata do ltimo registro instalado at agora para esta transao. Seja Z este endereo. Caminhando atravs da cadeia formada pelos ponteiros de transao, a partir de Z e at encontrar um registro de tipo INCIO ; a) se a pgina que contm o objeto a ser modificado ainda no esta na rea de trabalho da memria principal, requisite-a ao sistema operacional local. b) desfaa o efeito desta ao elementar; c) o ponteiro da ata desta pgina deve receber o valor do ponteiro de pgina deste registro; d) caminhe com Z pelo ponteiro de transao deste registro; 2) todas as pginas da rea de trabalho que contm registos relativos a esta transao e que ainda no foram salvas na memria secundria devem ser foradas para a memria secundria neste ponto. 3) um registro tipo CANCELAMENTO, ou CANC_LOCAL, construdo para esta transao em

memria principal pelo seu agente local. Os campos deste registro contm: a) identificao: recebe a identificao da transao, b) endereo: ignore c) valor inicial: ignore d) valor final: ignore e) ponteiro de pgina: colocado o valor do ponteiro da ata presente nesta pgina; f) ponteiro da transao: inserido o endereo do ltimo registro que o executor de transaes instalou na ata em favor desta transao; 4) este registro lanado na ata. LEITURA DE PGINA PARA A REA DE TRABALHO DA MEMRIA PRINCIPAL 1) gerente de paginao constri um registro de tipo LIDA. Seu campo de identificao de pgina contm o endereo da pgina cuja leitura foi solicitada; 2) o gerente de paginao requisita a pgina ao sistema operacional local; 3) se a operao de leitura e bem sucedida, o gerente de paginao lana o registro na ata; 4) o gerente de paginao fora este registro para a ata em memria secundria. ESCRITA DE PGINA PARA A MEMRIA SECUNDRIA 1) gerente de paginao constri um registro de tipo ESCRITA em cujo campo de identificao de pgina coloca o endereo desta pgina; 2) todas as pginas da ata que contm registros referentes a mudanas efetuadas em valores de objetos do BD que residem nesta pgina so foradas para a memria secundria; 3) o gerente de paginao solicita ao sistema operacional local que esta pgina seja escrita na memria secundria; 4) se a operao bem sucedida, o gerente de paginao instala na ata o registro tipo ESCRITA que acabou de construir.

Poderamos, se assim o desejssemos, forar registros da ata para a memria secundria aps cada movimento. Este esquema seria o que melhor aproximaria a condio ideal de escrever diretamente na ata em memria secundria. O custo seria um elevado ndice de trfego de pginas da memria secundria para a memria principal e vice-versa. Este fato poderia degradar significativamente o temo de resposta do sistema. O que se tentou atingir foi uma soluo de compromisso onde este tipo de trfego minimizado garantindo, porm, que a cada instante disporemos sempre das informaes necessrias para recuperar o sistema em caso de falha. Dentro deste esprito, no foramos os registros de tipo INCIO e EXECUO para a memria secundria. Na eventualidade de uma falha colher o sistema antes que este registros apaream na ata em memria secundria, simplesmente a transao no teria existido no que diz respeito ao mecanismo de controle de integridade. Observe, porm, que a rotina que deve ser seguida pelo gerenciador de paginao, ao substituir pginas da rea de trabalho, garante que no existiro registros tipo EXECUO sem que o correspondente registro tipo INCIO, bem como todos os

registros tipo EXECUO referentes a aes elementares anteriores, estejam devidamente protegidos na ata que reside em memria secundria. O mesmo raciocnio vale quando registramos em memria secundria os efeitos de uma transao ao l instalarmos a correspondente pgina do BD: a rotina a ser seguida pelo gerente de paginao garante que todos os registros da ata que modificaram valores de objetos residentes nesta pgina vo para a memria secundria antes de para l enviarmos esta particular pgina do BD. Com relao a registros tipo LIDA, devemos assumir uma soluo de compromisso. Forar o registro para a memria secundria traz a vantagem de podermos corretamente construir, durante a fase preparatria, a lista PG de pginas que estavam na rea de trabalho no instante da falha. No entanto, este procedimento implicar em forar pginas da ata para memria secundria sempre que o gerente de paginao resolver ler ou escrever uma pgina do BD para memria secundria aumentando, assim, o trnsito entre a memria secundria e a memria principal. A alternativa seria no forarmos os registros de tipo LIDA para a memria secundria. Neste cenrio, na fase 2 simplesmente supomos, conservativamente, que todas as pginas do BD estavam na rea de trabalho durante a falha. Este proceder, embora implicando em eventual trabalho desnecessrio, garantiria a correo do algoritmo, conforme discutido acima. Mais ainda, estaramos degradando o tempo de resposta durante a recuperao que, esperamos, seja um procedimento raro, em troca de melhorias durante a operao normal do sistema. O esquema postulado acima pressupe que sejamos capazes de identificar que pginas da ata ora residindo na memria principal j foram, alguma vez, enviadas a memria secundria. Se no formos capazes disto, a nica alternativa seria reescrever em memria secundria, sempre que preciso, todas as pginas da ata que esto na rea de trabalho. Identificar estas pginas, porm, no deve apresentar maiores dificuldades. Considere primeiro o caso quando foramos pginas da ata para a memria secundria antes de l lanar registros de CANCELAMENTO, CANC_LOCAL ou CONFIRMAO. Todas as pginas da ata que foram tocadas pela transao esto encadeadas atravs do ponteiro de transao, acessvel a partir do correspondente registro em poder do executor de transaes. Tudo que temos a fazer percorrer esta cadeia enviando para a memria secundria cada pgina visitada. De maneira anloga, toda a seqncia de registros da ata que modificaram valores de uma determinada pgina do BD encadeada atravs dos ponteiros de pgina destes registros. Desta forma, forar para a memria secundria as pginas da ata que tocaram certa pgina do BD corresponde a seguir esta cadeia, processando cada pgina encontrada. Note que o ponto inicial da cadeia est disponvel na prpria pgina em questo, atravs de seu ponteiro de ata. importante ressaltar que pginas da ata podem ser lidas para a memria principal de maneira no ordenada, isto , as pginas da ata que esto na rea de trabalho no necessariamente formam um bloco consecutivo de pginas da ata. Lembre que, durante o cancelamento de transaes, devemos consultar as pginas da ata que foram afetadas por aes elementares de cada transao cancelada. Em conseqncia, no podemos assumir que as pginas da ata na rea de trabalho obedeam qualquer ordem pr-especificada. possvel, portanto, que uma determinada cadeia de ponteiros envolvendo registros da ata contenha ns intermedirios cujas pginas j residiam em memria secundria. Ao percorrermos esta cadeia, seramos forados a consultar estas pginas da ata. Isto acarretaria o inconveniente de ler pginas para a memria principal, nico ponto onde podemos manipul-las. Este aumento de trfego entre a memria secundria e a memria principal traz todos os inconvenientes j conhecidos. Entretanto, estas dificuldades podem ser

facilmente contornadas atravs do seguinte estratagema. Lembre que a ata formada por uma seqncia de registros. Uma vez usado o espao disponvel em uma pgina fsica, passa-se a seguinte, o conceito de pgina sendo mera convenincia imposta pelos mecanismos de ler e escrever em memria secundria. Assim, o prprio uso da ata impe uma ordem natural nas pginas da mesma. Esta ordem dada pela seqncia temporal em que cada pgina foi usada pela primeira vez. Tendo estes fatos em mente, sempre que uma pgina P da ata for forada para a memria secundria, todas as pginas da ata anteriores a P tambm so enviadas a memria secundria, quer pertenam ou no a cadeia de ponteiros que nos levou a P. Estas pginas podem ser facilmente identificadas pelos seus endereos em memria secundria. Agora no mais precisamos consultar pginas da ata em memria secundria ao percorremos qualquer cadeia de ponteiros. Basta obtermos a primeira pgina da cadeia e acionarmos o gerente de paginao para que envie a memria secundria todas as pginas anteriores a esta. Note que, uma vez que certo espao da ata tenha sido ocupado por um registro, nunca mais ser tocado, pelo menos no cenrio que estamos assumindo agora onde o espao dedicado a ata em memria secundria tido como ilimitado. Assim, uma vez que certa pgina da ata j tenha sido instalada em memria secundria, esta pgina no mais ser alterada e, portanto, a verso em memria secundria permanente. Este fato d margem a que melhoremos ainda mais o trfego de pginas entre a memria principal e a memria secundria. Basta manter em cada pgina um "bit" indicando se esta pgina j foi escrita em memria secundria aps ter sido totalmente completada com registros da ata. Se tal for o caso, durante a operao de forar pginas para a memria secundria poderamos terminar o processo ao encontrarmos uma tal pgina, visto que suas antecessoras, pelo estratagema proposto, tambm estaro na mesma condio. Resumindo, dada uma cadeia de pginas a ser consultadas, basta examinar a primeira pgina, P. Se o "bit" indicativo de P for favorvel, nada feito. Se no o for, P e todas as suas antecessoras at a primeira pgina com "bit" indicativo favorvel, sero enviadas a memria secundria. Confiando que, aps esta discusso, o leitor poder implementar as correes necessrias no algoritmo apresentado, caso deseje usar a alternativa de no forar os registros tipo LIDA para a memria secundria, vamos evitar de faze-lo no texto. 9.1.4.2 Obtendo Balizadores No algoritmo de controle de integridade assumamos a existncia de um ponteiro para a ata, I, e tambm de informaes sobre transaes incompletas, transaes canceladas localmente e tambm transaes que j haviam entrado na execuo do protocolo bifsico. Tambm dispnhamos de informao cerca das pginas que estavam na rea de trabalho no instante da falha. Vamos agora indicar como obter tal ponteiro I e as informaes correspondentes. Estas ltimas sero escritas na ata em registros especiais, chamados balizadores, e I ser tido, portanto, como um endereo sobre a ata. Vamos introduzir mais um tipo de registro que pode ser lanado na ata. Um registro tipo BALIZADOR conter trs campos: TA: lista com a identidade de todas as transaes que no ponto I seriam classificadas como: i) incompletas ii) canceladas localmente. Neste caso, em adio, sabemos a posio na ata do respectivo registro de CANC_LOCAL.

TR: PG:

lista com a identidade de todas as transaes que j haviam iniciado o protocolo bifsico, junto com o respectivo estado de retorno; lista com o endereo de toda pgina do BD que estava na rea de trabalho no instante indicado por I, junto com a posio do respectivo registro tipo LIDA.

Seria interessante se logo aps uma falha primria pudssemos saber imediatamente onde se encontra o ltimo registro tipo BALIZADOR. Lembre que a partir deste ponto que deveremos iniciar a parte preparatria do algoritmo de controle de integridade. Embora no seja essencial, postularemos a existncia de um registrador de emergncia cujo contedo indicar sempre a posio do ltimo registrador tipo BALIZADOR que h na ata. Este registrador de emergncia suposto sobreviver a falhas primrias. A funo de um registro tipo BALIZADOR dupla: 1) prover informaes iniciais fase preparatria; 2) limitar at que ponto devemos regredir lendo registros da ata durante a fase 2 do algoritmo, quando estamos desfazendo aes elementares. Sabemos que o ponto mais remoto sobre a ata a que devemos nos referir, ao recuperarmos o sistema local, depende de dois fatores: 1) da posio do ltimo registro tipo BALIZADOR ; 2) da posio do registro tipo LIDA mais antigo relativamente a todos aqueles registros deste tipo que constam na lista PG no instante da falha. O primeiro item acima expe uma situao onde devemos assumir uma soluo de compromisso. De um lado, quanto mais freqentes os balizadores instalados na ata, tanto menos precisaremos regredir na ata quando da recuperao de falhas. De outro lado, tanto mais ser degradado o tempo de resposta do sistema devido a carga adicional de se obter os balizadores. A soluo final ser ditada pela tolerncia que devemos atingir no que tange ao tempo de resposta quando comparada freqncia de ocorrncia de falhas primrias e, tambm, de quo gil deva ser o mecanismo de controle de integridade ao recompor o sistema aps tais falhas. Quanto ao segundo fator, eliminado pelo prprio mecanismo de se obter os balizadores descrito em seguida: 1) LIMPANDO A REA DE TRABALHO: a) seja I o endereo na ata do ltimo registro tipo BALIZADOR ; b) para cada pgina P do BD que esteja na rea de trabalho da memria principal: i) seja Z o endereo na ata onde se situa o correspondente registro tipo LIDA para esta pgina; ii) se Z for anterior a I, envie esta pgina, atravs do gerenciador de paginao, para a memria secundria; iii) insira na ata um novo registro tipo LIDA para esta pgina, modificando tambm o valor do ponteiro para a ata a ela associado de modo a refletir esta nova posio de seu registro tipo LIDA;

2) OBTENDO TA, TR e PG : a) espere o BD atingir um estado consistente; b) consultando o executor de transaes local, construa o campo TA e o campo TC ; c) consultando o gerente de paginao local, construa o campo PG ; 3) construa um registro tipo BALIZADOR a partir das informaes coletadas na fase anterior; 4) lance este registro na ata; 5) atualize o contedo do registrador de emergncia de forma a conter uma indicao para esta posio na ata. Esperar por um estado consistente no significa que devemos aguardar at que todas as transaes confirmem ou cancelem. Apenas devemos ter cuidado em garantir que cada ao elementar solicitada j executou e nada mais poder modificar o estado do BD. Ressaltamos que o envio de pginas do BD a memria secundria, atravs do gerenciador de paginao, deve obedecer a todo o ritual descrito anteriormente e referente a este tipo de operao. Ento, a pgina deve ser "fixada" na rea de trabalho, o registros correspondentes da ata so forados para a memria secundria, etc. Inclusive, claro, lanado na ata um registro de ESCRITA para esta pgina. A insero do registro de LIDA para cada pgina enviada a memria secundria tem o efeito de transportar seu registro tipo LIDA anterior para a ltima posio da ata, minimizando, assim, a distncia que devemos retornar sobre a ata ao recuperarmos o sistema. 9.1.4.3 Atas com Espao Limitado evidente que supor que dispomos de espao ilimitado para acomodar a ata, como fizemos at agora, uma abstrao. H vrias alternativas possveis. Todas devem, entretanto, garantir que sempre haver meios de se registrar as atividades necessrias na ata, a qualquer momento. Se necessrio, transaes sero eleitas para serem canceladas ou partes da ata sero copiadas para memria secundria dormente. Em geral, atas podem ser gerenciadas como uma estrutura em anel, onde novos registros so adicionados de um lado e retirados de outro, at que no haja mais espao disponvel. Um certo registro da ata pode ser destrudo, ocupando-se seu espao para outros registros, quando 1) a correspondente transao j confirmou ou cancelou, local ou globalmente, e 2) a correspondente pgina j foi reenviada para a memria secundria. Em ltima instncia, pode-se recorrer a descargas da ata em memria secundria dormente. 9.1.4.4 Falhas Secundrias Toda a discusso desta seo est baseada no fato de que o meio onde se encontra a ata est imune a falhas. Esta mxima pode ser aproximada na medida em que a ata duplicada em dispositivos fsicos distintos. Desta forma, uma falha em um deles ainda poderia ser recuperada usando-se o segundo. O preo, claro, est no tempo extra gasto em gerenciar duas atas distintas. Em teoria, poderamos levar a situao adiante, triplicando, quadruplicando, etc., o nmero de dispositivos diferentes usados. Uma alternativa seria obtermos descargas em memria secundria dormente, usualmente localizadas em fita magntica.

H duas maneiras principais de obtermos descargas em memria dormente que se adaptam melhor ao mecanismo de atas. Em primeiro lugar, poderamos simplesmente deter as atividades do BD, no aceitando transaes por um certo perodo de tempo. Aps todas as transaes j submetidas terem terminado, cancelando ou confirmando, uma descarga de todas as pginas do BD seria lanada em memria dormente. Na eventualidade de uma falha secundria, esta cpia estaria pronta para ser usada. Se o preo de se impedir o uso do BD de tempos em tempos for muito elevado, poderemos obter descargas individuais de cada pgina do BD de forma dinmica, sem deter o sistema. Neste ltimo caso o prprio sistema submeteria "transaes" que consistiriam em copiar pginas do BD para memria dormente. Visto que os mecanismos de controle de concorrncia probem que uma transao inspecione o contedo de objetos que sero modificados por outras transaes, o prprio controle de concorrncia poderia ser utilizado para se obter descargas de pginas em estados aceitveis. O problema residiria no fato de que pginas diferentes refletiriam estados diferentes do BD no sentido de que as pginas mais recentes podem ter sido modificadas por transaes que nem existiam quando outras pginas mais antigas foram descarregadas. A situao remediada construindo-se tambm uma ata em memria dormente, contendo apenas os registros referentes a transaes que confirmaram. Note que no necessrio obtermos registros de ata para as transaes que cancelaram. Isto porque estamos obtendo imagens de pginas em um estado consistente em relao as transaes que executam no sistema. Suponha que uma transao T venha a cancelar. Ento, at que tenhamos lanado em ata o registro tipo CANCELAMENTO, ou CANC_LOCAL, para esta transao, os mecanismos de controle de concorrncia no permitiro que tenhamos acesso, atravs de outra transao, ao contedo de pginas modificadas pela transao que cancelou. Mas, aps termos lanado o referido registro na ata, j teremos invertido todos os efeitos desta transao, em todas as pginas onde alterou valores de objetos do BD. Este mecanismo parte integrante do processo de cancelar transaes. Logo, as transaes canceladas, aps termos lanado em ata o correspondente registro tipo CANCELAMENTO ou CANC_LOCAL, podem ser ignoradas no instante de obtermos a descarga em memria dormente. medida em que so obtidas cpias em memria dormente para cada pgina do BD precisamos, claro, obter tambm cpias em memria dormente dos registros de todas as transaes que vo confirmando. Estas ltimas podem ser obtidas regularmente como parte do processo de aliviar a rea disponvel para uso da ata em memria secundria ativa. A nica dificuldade estaria em decidirmos, medida que examinamos registros da ata, se a correspondente transao confirmou ou cancelou, visto que o registro de tipo apropriado est mais adiante na ata. Esta informao pode ser adquirida lendo-se, cada vez que encontramos um registro tipo INCIO, os prximos registros da ata at encontrarmos o registro de trmino da transao em questo. No caso desta ltima ainda no haver terminado, o mecanismo entra em compasso de espera at que se d o desenlace. No difcil imaginar que podemos, desta forma, manter uma lista de transaes que esto ativas, cada uma marcada apropriadamente, segundo tenha terminado ou cancelado. Assim, a medida que prosseguimos, podemos lanar em memria secundria dormente apenas os registros correspondentes a transaes que confirmaram. O processo de recuperao de uma falha que violasse a ata em memria secundria ativa consistiria, basicamente, em refazermos as aes elementares a partir da verso mais recente em memria dormente, de todas as transaes que houvessem confirmado. O preenchimento dos detalhes deixado a cargo do leitor.

9.2 IMAGENS TRANSIENTES

Nesta seo, uma outra tcnica de controle de integridade local abordada. Esta tcnica permitir recuperar o ltimo estado consistente do BD aps falhas primrias ou secundrias, ou seja, falhas que causem a perda do contedo da memria principal ou da memria secundria, respectivamente, bem como desfazer localmente os efeitos de uma transao incompleta durante a operao normal do sistema. Inicialmente, uma implementao do nvel fsico do subsistema de armazenamento, sem mecanismos de controle de integridade, descrita. Em seguida, a implementao modificada para permitir a recuperao de falhas primrias e a anulao dos efeitos de uma transao. A idia bsica consiste em manter, para cada pgina alterada por uma transao, uma imagem transiente refletindo as alteraes e uma imagem certificada com o contedo original da pgina. Quando a transao termina, as imagens transientes so efetivadas e as imagens certificadas descartadas. Isto feito para todas as pginas atravs de uma ao bem simples. Naturalmente, estruturas de dados auxiliares so necessrias para atingir este efeito. A implementao sofrer, ento, uma segunda modificao, incorporando um mecanismo de descargas incrementais dinmicas, que permitir a recuperao de falhas secundrias. Nestas trs implementaes supe-se que as transaes so executadas seqencialmente, evitando-se assim os problemas de controle de concorrncia. Por fim, apresenta-se uma ltima modificao incorporando controle de concorrncia. Todos os mecanismos aqui apresentados se referem-se a controle de integridade local. Rotinas adicionais so necessrias em um ambiente distribudo para suprir outras funes como, por exemplo, avisar o n coordenador de uma transao em caso de cancelamento local forado por uma falha. 9.2.1 Implementao Bsica Esta seo apresenta uma implementao do nvel fsico do subsistema de armazenamento sem considerar mecanismos de controle de integridade ou de controle de concorrncia. 9.2.1.1 Definio da Interface Nesta primeira implementao, e em todas as que se seguem, supe-se que a memria secundria disponvel dividida em M segmentos de igual tamanho e que cada segmento , por sua vez, dividido em N pginas de tamanho fixo. Os segmentos sero denotados por S1 ,..., SM por razes mneumnicas. J as pginas de um segmento sero simplesmente numeradas de 1 a N. A interface oferecida por esta implementao aos outros subsistemas consiste das seguintes operaes bsicas (onde S um conjunto de segmentos e T a identificao de uma transao): ABRA(S,T) Para cada Si S, torna Si disponvel para T. FECHE(S,T) Para cada Si S, assegura que todas as pginas de Si que esto na memria principal e que foram modificadas por T so gravadas na memria secundria, e torna Si no disponvel para T.

Vi

0 Vj

memria secundria 1 memria principal 2 3 S L

SETORES

MAP

Figura 9.11 - Mapeamento entre pginas e setores

LEIA(Si ,j,F,T) L a pgina j do segmento Si para a memria principal, retornando o endereo da rea da memria principal que ocupa. O contedo da pgina poder ser ou no atualizado pela transao T que executou a operao, caso F=1 ou F=0. GRAVE(Si ,j,k,T) Regrava a pgina j do segmento Si , que estava na memria principal na rea k, na memria secundria. 9.2.1.2 Implementao da Interface Os segmentos e pginas so ainda um conceito lgico, podendo ser mapeados na memria secundria de vrias formas. A mais simples seria alocar todas as pginas de um mesmo segmento em espao contguo da memria secundria. No entanto, contigidade fsica difcil de manter. Para evitar este problema e, principalmente, para facilitar a incorporao de mecanismos de controle de integridade, um segundo mapeamento ser adotado. Considere que a memria secundria est dividida em L setores de tamanho idntico ao das pginas. Os setores so numerados de 1 a L. O mapeamento das pginas para os setores feito atravs das seguintes estruturas de dados: Vi vetor de ponteiros para o segmento Si, de comprimento igual ao nmero de pginas por segmento, tal que Vi(j) contm o endereo do setor que mantm a pgina j de Si, ou Vi(j)= 0 se a pgina no est alocada. Vi est dividido em blocos de tamanho fixo para facilitar a sua gerncia. Reside na memria secundria e partilhado por todas as operaes.

MAP vetor de "bits", de comprimento igual ao nmero de setores, tal que MAP(s)=1, se o setor s contm uma pgina de algum segmento, e MAP(s)=0, se o setor s est livre. Reside na memria principal e partilhado por todas as operaes. A Figura 9.11 ilustra este mapeamento. A memria principal disponvel para o subsistema de armazenamento est dividida em K reas de trabalho, numeradas de 1 a K, do mesmo tamanho que as pginas dos segmentos. A gerncia das reas de trabalho no ser abordada aqui. H tambm um outro conjunto de reas de trabalho para conter os blocos dos vetores de ponteiros Vi. As operaes bsicas sero ento implementadas da seguinte forma: ABRA(S,T) Para cada Si S, localize onde esto armazenados os blocos de Si. LEIA(Si ,j,F,T) Leia o bloco de Vi contendo Vi(j), se j no estiver na memria principal. Obtenha uma rea de trabalho disponvel k. Se Vi(j) 0, leia o setor apontado por Vi(j) para a rea k, retornando o endereo de k. Se Vi(j) = 0, a pgina no est alocada; neste caso apenas retorne o endereo de k. GRAVE(Si ,j,k,T) Leia o bloco de Vi contendo Vi(j), se j no estiver na memria principal. Se a pgina j no estava alocada, ou seja, se Vi(j) = 0, pesquise em MAP um setor livre s, e faa MAP(s)=1 e Vi(j) = s. Caso contrrio, o setor s o prprio valor de Vi(j). Grave ento o contedo da rea de trabalho k no setor s. T a identificao da transao que invocou a operao, e no usada nesta implementao (mas sim nas modificaes descritas nas sees seguintes). FECHE(S,T) Para cada Si S, regrave na memria secundria os blocos e pginas de Si que foram modificados (um bloco poder ser modificado se uma das pginas que lhe corresponde foi alocada ou desalocada) e que se encontram ainda na memria principal. Para gravar a pgina j que se encontra na rea de trabalho k, utilize a operao GRAVE(Si ,j,k,T). As sees seguintes incorporaro mecanismos de controle de integridade a esta implementao, que bastante vulnervel a falhas. 9.2.2 Proteo contra Falhas Primrias Esta seo introduz modificaes na implementao bsica de tal forma a torn-la robusta a falhas primrias. Novamente, assume-se que no h controle de concorrncia e que, portanto, as transaes devem ser processadas seqencialmente em cada n. O objetivo bsico ser fornecer um mecanismo para retornar o banco de dados ao ltimo estado

consistente anterior a uma falha primria. Este estado consistente definido como aquele gerado pela execuo de todas as transaes que terminaram at o momento da falha (na mesma ordem). As modificaes introduzidas permitiro tambm desfazer os efeitos de uma transao parcialmente executada. A idia bsica para resguardar o banco de dados contra falhas primrias muito simples. Para cada pgina j de cada segmento Si acessado pela transao so mantidas, durante o processamento, uma imagem transiente refletindo as alteraes efetuadas pela transao em j, e uma imagem certificada com o contedo original de j. Quando a transao termina, as imagens transientes so efetivadas e as imagens certificadas descartadas, para todas as pginas de forma atmica, ou seja, ou todas as imagens transientes so efetivadas, ou nenhuma delas o . Este o ponto difcil de se atingir, requerendo uma duplexao das estruturas de dados usadas na implementao bsica, conforme descrito de forma geral a seguir. 9.2.2.1 Como Atingir Atomicidade Considere o seguinte problema genrico. Seja D uma tabela (ordenada) armazenada na memria secundria. Registros desta tabela so trazidas para a memria principal por processos, atualizados e regravados novamente na memria secundria, vrias vezes. Em presena de falhas primrias, um processo pode ser interrompido deixando a tabela em um estado inconsistente. Este problema decorre essencialmente do fato de que a execuo de um processo no pode ser considerada como atmica. Para resolver este problema e atingir atomicidade, introduz-se uma tcnica de duplexao, que pode ser abstrada da seguinte forma: 1) Substitua a tabela D por duas outras, D(0) e D(1) e por uma varivel C, todas armazenadas na memria secundria. Cada processo, ao iniciar, recebe um nmero de senha monotonicamente crescente. A senha do ltimo processo que terminou corretamente sempre armazenada em C, de forma incorruptvel. Cada registro de D(0) e D(1) agora um par (d,r) onde d o nmero de senha do processo que criou o registro r. Assume-se que cada registro tambm gravado de forma incorruptvel, de tal forma que a afirmao acima sobre d e r seja sempre verdade, mesmo em presena de falhas. Ou seja, a regravao de um par (d,r) suposta atmica. 2) Antes de usar a tabela, um processo recebe uma senha d tal que d > C. 3) O processo l, atualiza e regrava livremente D(0) durante seu processamento normal. Para cada registro gravado, o valor de senha mudado para d. 4) Quando o processo termina, execute as seguintes operaes: a) Grave todos os registros atualizados que ainda esto na memria principal em D(0). b) Aps terminar corretamente a gravao, leia C, faa C := d, e regrave C. Estas operaes sinalizam que o processo com senha d terminou de atualizar D(0) corretamente. c) Se a gravao de C foi correta, copie todas as modificaes feitas pelo processo em D(1). 5) Se houver uma falha, recupere o ltimo estado consistente de D(0) e D(1) da seguinte forma: a) Sejam D(0)[j]=(d0 ,r0) e D(1)[j]=(d1 ,r1) as j-simas entradas de D(0) e D(1), respectivamente.

b) se d0 > C, ento faa D(0)[j]:=D(1)[j] pois a j-sima entrada de D(0) foi criada por um processo que no terminou corretamente. c) se d0 = C e d1 < C, ento faa D(1)[j]:=D(0)[j] , pois a j-sima entrada de D(1) no reflete as atualizaes do ltimo processo que terminou corretamente, mas D(0) reflete. Note que a gravao de C tem que ser considerada indivisvel, o que bastante razovel. Alm disto, quando um par (d,r) for transferido para memria secundria, r deve ser gravado antes de d. Assim, se d=C ento r certamente ser o valor criado pela transao com senha d. Esta tcnica pode ser estendida para que n estruturas de dados D1 ,...,Dn sejam sempre mantidas coerentes. Para tal, basta introduzir um vetor (C1 ,..., Cn), tal que Ci faz o papel de C para a estrutura Di. Se a regravao do vetor no for confivel, pode-se introduzir uma nova varivel CC e duplexar o vetor. Desta forma, reduzimos novamente o problema a gravar apenas uma varivel, CC, de forma indivisvel. Na verdade, "hardware" especial pode ser projetado para armazenar de forma confivel apenas esta varivel, ou o prprio vetor, evitando-se completamente o problema de gravao na memria secundria. 9.2.2.2 Estruturas de Dados da Implementao Modificada Voltemos agora ao problema de controle de integridade, comeando por uma classificao dos estgios por que passa o processamento de uma transao (supondo que o protocolo bifsico sempre invocado ao final): Estgio 0: Estgio 1: do incio at atingir a primeira fase do protocolo bifsico. aps passar pela primeira fase do protocolo bifsico at terminar.

Lembremos que a idia bsica do mecanismo de controle de integridade manter mais de uma verso, ou imagem, de uma pgina. Os estgios de uma transao induzem, ento, uma classificao para as imagens de uma pgina da seguinte forma: imagem certificada: imagem criada pela ltima transao que terminou corretamente; imagem em certificao: imagem criada por uma transao que passou pela primeira fase do protocolo bifsico mas ainda no terminou; imagem transiente: imagem criada por uma transao que est em processamento e que ainda no passou pela primeira fase do protocolo bifsico. Em um dado instante t, chamaremos ento de estado certificado do banco coleo das imagens certificadas das pginas no instante t, e chamaremos de estado transiente do banco coleo das imagens criadas por ltimo (independente de tipo). Dado que as transaes so executadas seqencialmente, por suposio, o estado certificado do banco ento aquele criado por todas as transaes que terminaram corretamente at t, e o estado transiente o estado real no instante t. Novas estruturas de dados sero introduzidas e a implementao das operaes ser alterada de tal forma que:

estado transiente, naturalmente, estar sempre disponvel, e estado certificado criado pela ltima transao que terminou corretamente estar sempre acessvel, de forma incorruptvel.

A tcnica de duplexao ser usada para atingir o segundo objetivo, o que exige associar senhas monotonicamente crescentes s transaes. As estruturas de dados sero modificadas da seguinte forma: Vi vetor definido de forma semelhante implementao bsica. Reside na memria secundria e tal que Vi(j) = (0,0) Vi(j) = (s,t) se a pgina j nunca foi alocada; ou se s o setor que contm a imagem da pgina j criada por ltimo, e t a senha da transao que criou esta imagem.

VCi

vetor duplexando Vi. Reside na memria secundria.

MAP definido de forma idntica implementao bsica. Reside na memria principal. Li lista de setores ocupados por pginas de Si que devero ser liberados quando Si for fechado. Reside na memria principal. (No caso de execuo concorrente, discutido no final da seo, existir uma encarnao de Li para cada transao T que usar Si). lista de blocos de Vi que foram alterados pela transao. Reside na memria principal. (No caso de execuo concorrente, discutido no final da seo, existir uma encarnao de Bi para cada transao T que usar Si).

Bi

CONTROLE estrutura de dados, residindo na memria principal, mas com uma cpia na memria secundria, usada para indicar qual a senha da ltima transao que terminou corretamente e qual o estado da transao corrente. Contm as seguintes variveis, nesta implementao: C D senha da ltima transao que terminou corretamente. D=1 D=0 indica que a transao corrente j passou pela primeira fase do protocolo bifsico mas ainda no terminou, e indica o contrrio.

Estas estruturas sero mantidas de tal forma que a assertiva P abaixo ser sempre verdadeira, mesmo em caso de falhas durante a execuo das operaes, supondo que P seja verdadeira no incio do processamento. Assume-se apenas que a gravao de CONTROLE no est sujeita a falhas. Alm disto, quando um par (s,t) for transferido para memria secundria, s deve ser gravado antes de t. Assim, se t=C ento s certamente ser o valor criado pela transao com senha t.

ASSERTIVA P Definio dos Estgios da Transao Corrente Suponha que a senha da transao corrente seja d. D=0 e d > C sse T ainda no passou pela primeira fase do protocolo bifsico. D=1 e d > C sse T passou pela primeira fase mas ainda no terminou. d=C sse T terminou.

Definio dos Estados de uma Imagem Suponha que Vi(j) = (s,t) e que VCi(j) = (s',t'). se D=0 e t > C ento s contm a imagem transiente da pgina j e s' contm a imagem certificada de j. se D=1 e t > C ento s contm a imagem em certificao da pgina j e s' contm a imagem certificada de j. se t = C ento s contm a imagem certificada da pgina j. Neste caso s' contm a imagem certificada de j, se t=t', ou uma imagem indefinida, caso t' t (pois pode ter havido uma falha na atualizao de VCi(j)). se t < C ento s' contm a imagem certificada da pgina j. Neste caso s contm a imagem certificada de j, se t=t', ou uma imagem indefinida, caso t' t (pois pode ter havido uma falha na atualizao de Vi(j)). Note que a assertiva P acima apenas resume a definio das estruturas. O fato importante que P ser um invariante das operaes, mesmo em presena de falhas, assumindo-se apenas a gravao incorruptvel de CONTROLE. Note ainda que o uso de vetores de ponteiros para definir os segmentos crucial neste ponto pois permite representar o estado transiente e o estado certificado de forma duplexada sem grande desperdcio de memria. 9.2.2.3 Implementao das Operaes Alm das operaes da implementao bsica, trs novas operaes so introduzidas para controle de integridade (S representa um conjunto de segmentos e T uma transao): SALVE(S,T) Salva atualizaes que se encontram ainda na memria principal para a memria secundria. RESTAURE(S,T) Retorna o contedo dos segmentos em S aos seus valores originais, descartando as modificaes feitas pela transao.

RECUPERE Retorna o banco de dados ao estado certificado que existia no momento da falha (primria). Suporemos que estas operaes e aquelas apresentadas na seo anterior so utilizadas para processar as transaes (distribudas) da seguinte forma. Assume-se inicialmente que cada transao recebe uma senha monotonicamente crescente. Lembremos ainda que a suposio de que as transaes so processadas seqencialmente em cada n ainda est em efeito. Localmente, um n l e grava pginas para uma transao atravs de LEIA / GRAVE. Cada segmento Si aberto para T ao primeiro acesso a alguma pgina do segmento. Ao final, T executa um FIM_DE_TRANSACAO, invocando o protocolo bifsico. Localmente em um n n, o processamento se d ento da seguinte forma. Antes de n votar PREPARADO, as atualizaes locais da transao T so salvas na memria no voltil atravs de SALVE(S,T), onde S o conjunto de segmentos usados localmente por T. Se n votar IMPOSSIBILITADO, as atualizaes so descartadas atravs de uma operao RESTAURE(S,T) Quando o n recebe a mensagem CONFIRME final, as atualizaes de T so tornadas visveis de forma atmica e recupervel atravs da execuo de uma operao FECHE(S,T) Se a transao no foi aceita, e uma mensagem CANCELE for recebida, basta executar uma operao RESTAURE(S,T) Durante o processamento da transao T, se for necessrio cancel-la basta executar RESTAURE(S,T) para descartar as suas atualizaes. Tendo em vista este modelo de processamento de transaes, a implementao das operaes ser modificada para que a assertiva P acima seja um invariante. Convm observar neste ponto que P implica em que a seguinte assertiva tambm ser um invariante: ASSERTIVA Q Para cada pgina j de cada segmento Si, seja Vi(j) = (s,t) e VCi(j) = (s',t'). A imagem certificada de j estar em s, caso t = C, ou em s', em caso contrrio. Desta forma, depois de uma falha que cause a perda do contedo da memria principal, ser sempre possvel recuperar o estado certificado no momento da queda: basta inspecionar os setores como indicado no enunciado de Q. Como este estado reflete exatamente a execuo de todas as transaes que terminaram corretamente at o momento da falha, pois Q tambm um invariante, pode-se dizer que a recuperao estar correta. Suponha que MAP seja iniciado corretamente para indicar quais setores esto ocupados. (Veja a descrio de RECUPERE abaixo). A implementao das operaes ser modificada da seguinte forma: ABRA(S,T) Para cada SiS, localize onde esto armazenados os blocos de Vi. Inicie uma lista Li para T como vazia. LEIA(Si ,j,F,T) A implementao desta operao no alterada. Ou seja, as transaes sempre lem do estado transiente.

VCi 2 0 1

0 VCj

Vi

0 Vj

memria secundria 1 memria principal 2 3 4 5 S L

SETORES

0
C

1
D

MAP

CONTROLE

Figura 9.12 - Estruturas aps GRAVE(Si ,j,k,T) GRAVE(Si,j,k,T) A implementao desta operao reflete a idia bsica de que uma pgina, ao ser modificada, no regravada no mesmo lugar. O setor que ocupa continuar contendo a imagem certificada da pgina, enquanto que um novo setor escolhido para conter a imagem transiente da pgina. Estas duas imagens coexistiro at que o segmento seja fechado.

Estas idias so implementadas da seguinte forma. Seja d a senha de T. Leia o bloco de Vi contendo a pgina j para a memria principal, se l j no estiver. Suponha inicialmente que Vi(j) = (s,t). Se a pgina j j foi modificada por T, temos que t=d. Logo, apenas copie a pgina j da rea k para o setor s. Se a pgina j ainda no foi modificada ou nunca foi alocada, temos td. Obtenha um novo setor s' no utilizado pesquisando MAP. Copie a pgina j da rea k para o setor s'. Em seguida, indique que agora s' contm a imagem transiente de j fazendo Vi(j) = (s',d). Devemos observar neste ponto que cada bloco de Vi lido ser regravado, se tiver sido modificado pela transao, quando for necessrio liberar espao para novos blocos. A identificao destes blocos modificados e regravados dever ser mantida na lista Bi da transao que os alterou at que T termine.

MAP deve ser ento atualizado. Os setores s e s' permanecero alocados para todos os efeitos at que a transao termine corretamente. Logo, apenas aloque o setor s' fazendo MAP(s')=1. Acrescente o setor s lista Li da transao T para ser liberado quando T terminar. O vetor VCi na memria secundria ser mantido intacto at que T termine corretamente. Assim sendo, esta operao tambm preserva, trivialmente, a propriedade P. A Figura 9.12 ilustra o resultado da operao GRAVE(Si,j,k,T), assumindo, digamos, j=1 e d=3. Inicialmente, um setor no utilizado, digamos s=4, obtido pesquisando-se MAP. O setor marcado como utilizado fazendo-se MAP(4)=1, conforme mostrado. Em seguida, o setor 4 alocado para a imagem transiente da pgina 1, fazendo-se Vi(1) = (4,3). O segundo argumento de Vi(j) no mostrado explicitamente. Note que VCi(j) permanece inalterado pois aponta para a imagem certificada de j. O setor 2 acrescentado lista Li (no mostrada) para ser desalocado quando a transao terminar. SALVE(S,T) Salve para a memria secundria as pginas atualizadas, atravs de GRAVE, e os blocos modificados de Vi que se encontram ainda na memria principal. Estes blocos so tambm acrescentados a Bi. Apenas aps a execuo correta destas atualizaes, leia CONTROLE, faa D := 1, e regrave CONTROLE efetivando a execuo de SALVE. O n poder ento votar PREPARADO, e esperar o coordenador enviar CONFIRME ou CANCELE. FECHE(S,T) FECHE dever instalar, de forma atmica, um novo estado certificado. Seguindo o modelo de processamento de transaes apresentado no incio desta subseo, supe-se que SALVE(S,T) j foi corretamente executada e que, portanto, todas as atualizaes feitas pela transao nas pginas e em Vi j se encontram salvas na memria secundria corretamente. Seja d a senha de T. Sinalize que T terminou corretamente. Leia CONTROLE, faa C := d e D := 0, regravando CONTROLE em seguida. O n poder ento enviar ao coordenador a resposta da mensagem CONFIRME, neste ponto. Aps a gravao de CONTROLE ter sido corretamente efetuada, os blocos de Vi atualizados, que se encontram na lista Bi, so tambm gravados em VCi. Desta forma, Vi e VCi ambos refletem as alteraes da transao, se esta terminou corretamente. Finalmente MAP modificado, efetivamente liberando os setores que continham imagem certificadas obsoletas, que so mantidas na lista Li. Assumindo-se que a regravao de CONTROLE atmica e que as transaes invocam FECHE apenas quando terminam corretamente, esta operao tambm preserva a assertiva P. Note que necessrio tambm lembrar que, localmente, as transaes so executadas seqencialmente. Logo, quando uma transao termina, o estado transiente mantido em Vi coincide com o novo estado certificado, o que no verdade em presena de execuo concorrente. Como o estado

certificado atualizado segundo a tcnica de duplexao, mesmo que uma falha interrompa a atualizao da definio do estado certificado, P no invalidado. Observe ainda que MAP no pode ser atualizado at que o vetor definindo o novo estado certificado tenha sido corretamente construdo e CONTROLE atualizado pois, de outra forma, o seguinte cenrio poderia ser criado: 1) Suponha que o setor s contm a imagem certificada da pgina j do segmento Si e que Vi(j) = VCi(j) = (s,t). Seja d a senha da transao T corrente. 1) T cria uma imagem transiente para j no setor s', fazendo Vi(j) " := " (s',d), e libera a imagem certificada em s, alterando MAP(s) para 0. 2) O setor s reusado para conter a imagem transiente da pgina k do segmento Sl . 3) Uma falha primria ocorre antes da transao terminar. 4) O sistema recuperado para o ltimo estado certificado. Como Vi(j) = (s',d) e d > C, faz-se Vi(j) := VCi(j). 5) Porm, VCi(j) = (s,t) indica que o setor s contm a imagem certificada da pgina j do segmento Si, o que no verdade, pois ele contm a imagem transiente da pgina k de Sl . Assim sendo crucial que MAP s seja atualizado depois que o novo estado certificado foi corretamente criado. RESTAURE(S,T) Esta operao mais ou menos o inverso de FECHE(S,T), no sentido de que as imagens transientes das pginas devero ser descartadas e as imagens certificadas mantidas. Novamente observe que VCi mantm ponteiros para as imagens certificadas das pginas modificadas por T. Seja d a senha de T. Para cada bloco b de Vi na lista Bi de T e para cada pgina j de Si no intervalo correspondente a b, se Vi(j) = (s,d), ento libere s fazendo MAP(s)=0 e copie VCi(j) para Vi(j). Sinalize que a transao foi cancelada. Leia CONTROLE, faa D := 0 e regrave CONTROLE. O n poder, ento, enviar ao coordenador a resposta da mensagem CANCELE recebida neste ponto. RECUPERE A ao de RECUPERE depende do estado atingido pela transao no momento da falha. Para determin-lo, leia inicialmente CONTROLE da memria secundria, obtendo os valores de C e D. Dependendo do valor de D temos os seguintes casos: Caso 1: Suponha que D=0. Ento a transao pode ter sido interrompida antes de entrar no protocolo bifsico, ou durante FECHE (depois de ter atualizado C e D, mas antes de completar a atualizao de VCi. Eis porque VCi(j) pode no apontar para a imagem certificada da pgina j). Estas duas situaes podem ser distinguidas pois, no primeiro caso, a

senha da transao maior do que C, enquanto que no segundo caso igual a C. O n local dever ento desfazer os efeitos da transao, retornando o banco de dados local ao ltimo estado certificado, no primeiro caso, ou terminar a atualizao de VCi, no segundo caso. Para cada pgina j de cada segmento Si, seja Vi(j) = (s,d): Caso 1.1: Suponha que d C. Faa Vi(j) := VCi (j) Caso 1.2: Suponha que d = C. Faa VCi(j) := Vi(j) Para recuperar MAP, proceda da seguinte forma. Inicialmente, zere MAP; em seguida percorra todos os vetores Vi, para cada pgina j de Si e, se Vi(j) = (s,t), faa MAP(s)=1. Como a assertiva P preservada por todas as operaes, RECUPERE recria o estado certificado no momento da falha (veja a definio de estado certificado e a descrio de P acima). Caso 2: Suponha que D=1. Ento a transao foi interrompida depois de SALVE ter sido executado e antes de FECHE ou RESTAURE terem terminado. Neste caso no h nada a fazer, pois o estado transiente criado ao final da transao j estava salvo na memria secundria. Apenas MAP deve ser reconstrudo. Zere MAP inicialmente e depois percorra todos os vetores Vi e VCi e, para cada pgina j de Si, se Vi(j) = (s,t) ou VCi(j) = (s,t'), faa MAP(s)=1. O n fica, ento, esperando o coordenador reenviar CONFIRME ou CANCELE novamente, para reexecutar RESTAURE ou FECHE. Isto conclui a descrio da implementao das operaes. Por fim, observamos que a recuperao de uma falha primria causando a perda do contedo da memria principal simples: basta executar RECUPERE, quando o n for reiniciado. 9.2.3 Proteo contra Falhas Secundrias Esta seo incorpora novas modificaes implementao bsica de tal forma a torn-la robusta tambm contra falhas secundrias, ou seja, a falhas no prprio meio que armazena o banco de dados. A soluo adotada segue a poltica de descarga incremental dinmica. Para efeitos desta discusso, suporemos que a descarga feita em fita. A descarga incremental ser executada periodicamente, digamos a cada n chamadas para FECHE ou SALVE, para um dado n fixo. Seja S o estado certificado no instante em que a descarga incremental foi iniciada pela ltima vez. Suponha que uma nova descarga incremental seja iniciada em um instante t' e que S' seja o estado certificado em t'. H quatro preocupaes bsicas na implementao da descarga:

1) necessrio marcar que imagens certificadas foram criadas depois da ltima descarga (e portanto no tm cpias). 2) o momento que a descarga inicia, uma descrio de S' dever ser congelada e cpias devero ser feitas apenas das imagens marcadas de S'. Se S' no for congelado, as transaes em andamento durante a descarga podero tornar as cpias inconsistentes. 3) Uma vez completada a descarga, as imagens copiadas devero ser desmarcadas. Caso contrrio, as imagens marcadas de S' poderiam ser novamente copiadas pela segunda descarga. 4) Alm disto, as transaes em andamento no podero liberar imagens certificadas sem cpia e que se tornaram obsoletas, que esto sendo copiadas pela descarga. Isto dever ser feito quando a descarga terminar. De fato, suponha que um setor s contenha uma imagem certificada sem cpia de uma pgina j. Suponha que uma transao T inicie e crie uma imagem transiente da pgina j. Suponha que a descarga executada concorrentemente com T e que, portanto, deva copiar o contedo de s. Quando T termina, a imagem certificada de j torna-se obsoleta e s dever ser desalocado. Porm, isto no pode ser feito at que a descarga termine corretamente. Estes problemas devero ser resolvidos prevendo-se, ainda, que falhas primrias possam ocorrer. No que segue, assumiremos que as transaes so processadas seqencialmente. Para se resolver o primeiro problema, basta guardar em uma varivel E a senha da ltima transao que terminou antes do incio da ltima descarga. De fato, se Vi(j) = (s,t) e E < t C, ento s contm uma imagem certificada sem cpia. O segundo problema resolvido criando-se na memria secundria uma nova cpia de VCi no momento em que a descarga iniciou. O terceiro problema resolvido adiando-se a transformao das imagens certificadas sem cpia em imagens com cpia para apenas quando a descarga terminar. Para tal, basta alterar o valor de E apenas quando a descarga terminar corretamente. O quarto problema exige que, quando inicie, a descarga sinalize para FECHE (a operao que descarta imagens certificadas obsoletas), quais so as imagens certificadas sem cpia que pertencem ao estado certificado S' naquele momento. Alm disto, necessrio que o processo de descarga desaloque os setores que continham imagens certificadas sem cpia de S', e que se tornaram obsoletas durante a execuo da descarga, apenas quando terminar corretamente. Para tal, novas estruturas so introduzidas indicando que setores sero copiados pela descarga e quais destes setores foram liberados pelas transaes durante a descarga. As estruturas so alteradas da seguinte forma: CONTROLE estrutura de dados, residindo na memria principal e com uma cpia na memria secundria para recuperao de falhas primrias. Contm as seguintes variveis, nesta implementao: C D (como anteriormente). (como anteriormente).

senha da ltima transao que terminou antes do incio da ltima descarga dinmica. DATIVA=1 indica que uma descarga est em progresso, DATIVA=0 indica o contrrio.

DATIVA

COPIANDO vetor de comprimento igual ao nmero de setores, em memria principal, tal que COPIANDO(s)=1 COPIANDO(s)=0 LA se s contm uma imagem certificada sem cpia que est sendo copiada. em caso contrrio.

lista dos setores contendo imagens certificadas sem cpia (no incio da descarga) que devero ser liberados ao final da descarga. Reside na memria principal.

O vetor COPIANDO, como MAP, reside na memria principal e durante o processamento usual est completamente zerado. Apenas quando a descarga inicia, os "bits" correspondentes aos setores com imagens certificadas sem cpia so levantados pela descarga. Em presena de descargas dinmicas, passamos a ter agora mais tipos de imagens: se t < C e D=0, ento a transao T no terminou ainda e s contm uma imagem transiente da pgina j; se t < C e D=1, ento a transao T passou pela primeira fase do protocolo bifsico mas ainda no terminou, e s contm uma imagem em certificao da pgina j; se E < t C, ento a transao T terminou depois da ltima descarga iniciar e s contm uma imagem certificada sem cpia da pgina j; se t < C e t E, ento a transao T terminou antes da ltima descarga iniciar e s contm uma imagem certificada com cpia da pgina j;

O processo de descarga incremental implementado como trs operaes: INICIALIZAO, CPIA e TERMINAO. Tanto INICIALIZAO quanto TERMINAO devero ser sincronizadas com as outras operaes executadas pelas transaes em progresso. Porm, CPIA poder ser executada sem nenhuma sincronizao adicional, alm daquela j embutida na prpria definio das novas estruturas, conforme discutido acima. Isto caracteriza, na verdade, o prprio fato da descarga incremental ser dinmica, ou seja, ser executada em conjunto com as transaes. A definio destas trs operaes a seguinte: INICIALIZAO Inicialmente, grave em fita uma marca, que ser usada em caso de falhas, indicando que a descarga foi iniciada. Congele, em seguida, o estado certificado corrente copiando o vetor VCi para um novo vetor VDi, para cada segmento Si. Os vetores VDi so criados na memria principal e a residem durante a execuo da descarga. Copie C para CD na memria principal tambm.

Crie COPIANDO a partir de VDi, para cada segmento Si, fazendo COPIANDO(s)=1 para cada setor s que contm uma imagem certificada sem cpia (ou seja, tal que VDi(j) = (s,t) e t > E para alguma pgina j de Si). Este vetor criado na memria principal. Finalmente, sinalize que a descarga iniciou. Leia CONTROLE, faa DATIVA = 1 e regrave CONTROLE. CPIA Para cada entrada j de cada vetor VDi, se VDi(j) = (s,t) e t > E, s contm uma imagem certificada sem cpia. A operao copia para fita a tripla (i,j,v), onde v o contedo do setor s. O processo de cpia pode ser interrompido e recomeado sem problemas, pois E ainda no foi alterada. TERMINAO Depois que o processo de cpia terminou corretamente, libere os setores contendo imagens certificadas obsoletas que esto contidos na lista LA. Assim, para cada s em LA, faa MAP(s)=0. Ao final, adicione uma marca fita indicando que o processo de descarga terminou. Sinalize que a descarga terminou corretamente. Leia CONTROLE, faa DATIVA:=0, E:=CD e regrave CONTROLE. As operaes FECHE e RECUPERE tm que ser modificadas em presena de descargas incrementais, como descrito abaixo. A correo destas novas implementaes obtida como anteriormente. FECHE(S,T) Apenas a atualizao de MAP agora diferente. A liberao de um setor no poder ser efetivada se o setor contm uma imagem certificada sem cpia que est sendo copiada por uma descarga em progresso. Portanto, se DATIVA=1, para cada setor s em Li, se COPIANDO(s)=1, ento adie a liberao de s at que a descarga termine, e acrescente s lista LA. Caso contrrio, libere s, fazendo MAP(s)=0. RECUPERE Recupere o banco para o ltimo estado certificado, como anteriormente. Se havia uma descarga em progresso, leia a fita, no sentido reverso, at encontrar uma marca de incio de descarga. Os registros da em diante podero ser ignorados pois representam parte de uma descarga incompleta. Estes registros poderiam ainda ser aproveitados, mas isto tornaria a recuperao mais lenta. Optou-se por desconsider-los, forando a reexecuo da descarga desde o incio. Por fim, inicia-se nova descarga se havia uma em progresso no momento da falha (DATIVA=1). Note que o estado certificado processado pela nova descarga no necessariamente aquele presente quando a descarga interrompida foi iniciada. Porm, todas as imagens certificadas sem cpia ainda so identificadas como anteriormente, pois

E s alterada depois da descarga terminar corretamente. Isto conclui a descrio do processo de descarga incremental dinmica e das modificaes das operaes. Por fim, observamos que possvel recuperar da fita o estado certificado do banco de dados no momento em que a ltima descarga foi feita, atravs da seguinte operao. RECUPERE2 Leia a fita para onde a descarga dinmica feita, do fim para o incio. O primeiro registro do tipo (i,j,v) encontrado contm o contedo v da pgina j do segmento Si do estado certificado do banco no momento do incio da ltima descarga. Se no houver um mecanismo de atas, em caso de falhas na memria secundria, s ser possvel recuperar o banco para este estado, com perda das atualizaes das transaes que terminaram depois da ltima descarga. 9.2.4 Incorporao de Controle de Concorrncia Inicialmente, uma discusso genrica sobre como controle de concorrncia pode ser acrescentado ao mecanismo de imagens transientes apresentada. Em seguida, a implementao da ltima seo sofre nova modificao, incorporando o protocolo de bloqueio em duas fases para controlar o acesso concorrente a um banco de dados local. 9.2.4.1 Discusso Preliminar A tarefa de introduzir controle de concorrncia no especialmente simples uma vez que a discusso do Captulo 8 razoavelmente abstrata quando comparada com o nvel de detalhe das implementaes descritas nesta seo. De fato, uma execuo concorrente era abstrada pelo conceito de escalonamento, ou seja, por uma coleo (no caso distribudo) de seqncias de aes elementares. Cada ao elementar afetava um conjunto de objetos, identificados por seus nomes, e conhecidos "a priori". Esta ltima suposio importante pois transforma o problema de verificar se duas operaes conflitam em simplesmente testar se possuem um nome de objeto em comum no conjunto de nomes de objetos que acessam (e uma delas uma atualizao). Se os objetos acessados fossem definidos por predicados, por exemplo, a deteco de conflitos recairia no problema de determinar se dois predicados so simultaneamente satisfatveis o que, dependendo do tipo de predicados, pode ser computacionalmente intratvel (ou mesmo indecidvel). Para aproveitar os resultados sobre controle de concorrncia, necessrio reinterpretar o conceito de escalonamento, identificando as aes elementares e os objetos nomeados. Esta reinterpretao recai no problema de determinar exatamente a que nvel feito o controle de concorrncia. Em termos da estrutura do subsistema de armazenamento (SAR), h essencialmente trs opes: 1) Controle de concorrncia a nvel lgico do SAR. 2) Controle de concorrncia a nvel fsico do SAR. 3) Controle de concorrncia a nvel de acessos fsicos a memria secundria.

A primeira opo imediatamente descartada pois as operaes oferecidas pela interface do nvel lgico do SAR manipulam conjuntos de registros definidos por predicados. Desta forma, a deteco de conflitos se torna invivel, como discutido anteriormente. A nica sada para se fazer controle de concorrncia a este nvel seria identificar os objetos com as prprias tabelas, ignorando os predicados. Porm, esta deciso foraria decretar que duas operaes conflitam quando acessam uma tabela em comum, mesmo que acessem registros diferentes da tabela. Portanto, no razovel. As duas ltimas opes so igualmente plausveis. Postularemos, ento, que controle de concorrncia ser feito a nvel fsico do SAR com o intuito de mostrar como pode ser incorporado discusso das sees anteriores. O resto desta subseo explora em mais detalhe esta alternativa. Inicialmente, definiremos que um escalonamento local representar uma seqncia de operaes oferecidas pela ltima implementao do nvel fsico discutida para o SAR. Ou seja, as aes elementares sero: ABRE , LEIA , GRAVE , FECHE , SALVE , RESTAURE e tambm aquelas implementando a descarga incremental: INICIALIZACAO , COPIA , TERMINACAO As operaes RECUPERE e RECUPERE2 no so consideradas pois representam excees durante o processamento (recuperao de falhas primrias ou secundrias). Cada ao elementar era implicitamente considerada como indivisvel no captulo de controle de concorrncia, o que claramente no verdade acerca das operaes acima. H duas formas de resolver este problema. Primeiro, podemos encarar cada operao como uma microtransao e implementar um segundo nvel de controle de concorrncia que force a serializao das execues concorrentes destas microtransaes. Porm, a serializao destas microtransaes tem que ser compatvel com aquela induzida para as transaes pelo controle de concorrncia do nvel superior. Ou seja, T precede T' na serializao das transaes se e somente se todas as operaes de T precedem todas as operaes de T' na serializao das operaes. Esta propriedade no fcil de se atingir, exigindo cuidados especiais. Adotaremos aqui uma soluo mais simples. Foraremos as operaes a serem executadas seqencialmente. Cada operao, ao iniciar, imediatamente tenta ativar um semforo, ATIVA, que controla o acesso a todas as estruturas da implementao. Aps terminar, a operao desativa o semforo. Desta forma, as operaes so executadas seqencialmente, mantendo a coerncia interna das estruturas. Note que isto no fora a execuo seqencial das transaes, mas apenas garante a atomicidade das operaes. A nica operao no sujeita a esta regra a operao de COPIA pois, de outra forma, a descarga no seria dinmica. Resta agora definir quem so os objetos. Consideraremos quatro opes: 1) Associar os objetos s prprias estruturas de dados (Vi, VCi, etc.). 2) Associar os objetos aos segmentos.

3) Associar os objetos a intervalos de pginas [ ji , ki ] tais que o i-simo bloco de Vi contm os valores de Vi(j), para j [ ji ,ki ] 4) Associar os objetos s pginas. Note que as trs ltimas opes determinam particionamentos diferentes do conjunto de pginas. As duas primeiras opes padecem do mesmo problema: induzem conflitos desnecessrios pois representam objetos grandes demais, por assim dizer, degradando a eficincia do controle de concorrncia. As duas ltimas opes so igualmente plausveis, em princpio, sendo a terceira explorada na subseo seguinte dentro do contexto do protocolo de bloqueio em duas fases. 9.2.4.2 Implementao do Protocolo de Bloqueio em Duas Fases Nesta subseo mostraremos como o algoritmo de bloqueio em duas fases distribudo pode ser incorporado ao mecanismo de controle de integridade descrito anteriormente. Apenas o mecanismo local mostrado, modificando-se a implementao das operaes. De acordo com a alternativa escolhida na subseo anterior, os objetos a serem bloqueados correspondem aos intervalos de pginas associados aos blocos de Vi. Em linhas gerais, a implementao do bloqueio em duas fases a seguinte: 1) Imediatamente antes de uma operao LEIA(Si ,j,k,T), o intervalo cobrindo a pgina j bloqueado para T. 2) Os intervalos bloqueados s sero desbloqueados quando a transao terminar e executar FECHE. Mais precisamente, as operaes executariam bloqueios da seguinte forma: ABRE LEIA GRAVE FECHE SALVE RESTAURE CPIA no executa bloqueios. bloqueia o intervalo cobrindo a pgina a ser lida para a transao. no executa bloqueios (LEIA j bloqueou os intervalos necessrios). libera os intervalos mantidos bloqueados. mantm os intervalos bloqueados. libera os intervalos mantidos bloqueados (supe-se que aps esta operao a transao reiniciada) no executa bloqueios.

INICIALIZAO implicitamente bloqueia todos os intervalos pois executada atomicamente (atravs do semforo ATIVA) com relao s outras transaes. TERMINACAO: mesma observao.

Alm do bloqueio aos dados, a implementao anterior tem que ser modificada para armazenar o estado corrente das vrias transaes em andamento (e no apenas de uma, como era o caso quando assumamos execuo seqencial). As variveis C e D devero ser substitudas por um mecanismo de atas, bem mais simples do que o descrito na Seo 9.1, apenas com o propsito de registrar de forma recupervel o estado das vrias transaes em andamento. A operao RECUPERE deve ser modificada para desfazer os efeitos das transaes que no atingiram a primeira fase do protocolo bifsico ou que esto sendo canceladas, e completar o processamento daquelas que estavam executando FECHE no momento da falha. As imagens criadas por transaes que atingiram a primeira fase do protocolo bifsico devero permanecer intactas. Alm disto, a operao RECUPERE dever reconstruir a tabela de bloqueios. Para tal, basta inspecionar qual transao criou a verso transiente de cada pgina. Se a transao atingiu a primeira fase do protocolo bifsico, ento a pgina dever ser rebloqueada para a transao. A descarga dinmica dever tambm ser modificada para armazenar em E a menor senha de alguma transao que estava em progresso quando a descarga foi iniciada. Para que esta alterao funcione corretamente, as senhas devero ser dadas baseadas na hora em que a transao iniciou. Assim, se VCi(j) = (s,t) e t > E, ento s conter uma imagem certificada sem cpia como no caso de execuo seqencial. Pode-se provar que esta implementao de bloqueio em duas fases local est correta. Os pontos mais importantes so os seguintes. Primeiramente, pode-se mostrar que toda execuo concorrente das transaes serializvel com relao aos blocos de Vi e aos setores, ou seja, com relao s estruturas que definem o estado transiente. Logo, anomalias de sincronizao no ocorrero com relao aos dados. O mecanismo de controle de integridade para recuperao de falhas primrias continua operando corretamente pois a assertiva P (vide Seo 9.2.3.3) continua sendo um invariante das operaes. No entanto, a noo de estado certificado tem que ser alterada da seguinte forma. Anteriormente, o estado certificado no instante t era definido como o estado do banco de dados criado pela ltima transao que terminou antes de t. Como as transaes eram executadas seqencialmente, este estado, na verdade, era aquele obtido pela execuo serial das transaes que terminaram corretamente at t, na ordem em que terminaram. Definiremos ento o estado certificado no instante t para uma execuo concorrente E como o estado do banco obtido pela execuo serial S/ das transaes que terminaram at o instante t na mesma ordem em que terminaram em E.

NOTAS BIBLIOGRFICAS
Attar, Bernstein e Goodman[1981] propem uma metodologia uniforme para tratar os problemas locais de iniciao, controle de integridade e obteno de cpias em memria dormente. Usam conceitos de serializao, atas e bloqueio em duas fases, apresentando uma anlise algo rigorosa da correo dos mtodos abordados. Gray[1980] tenta formalizar os vrios conceitos presentes nos mecanismos usados para manuteno de consistncia e tambm para recuperao do sistema em face de falhas primrias. Concentra-se em sistemas centralizados, na maior parte, apresentando algumas idias a respeito da probabilidade de bloqueios e eventos correlatos. Gray et all.[1979] um tutorial bem escrito. Cobre o mecanismo de recuperao do Sistema R, apresentando suas partes mais importantes e avaliando os custos, erros de concepo e as qualidades do sistema. Um refinamento possvel de ser incorporado ao mecanismo de atas descrito em Hadzilacos[1982]. A idia bsica consistiria em obter-se pontos de retorno para

transaes incompletas de modo que bastasse desfazer seus efeitos apenas at estes pontos de retorno. A idia formalizada e, em seguida, o problema de se escolher para que pontos de retorno devem as transaes incompletas ser revertidas analisado. O problema da escolha dos pontos de retorno se torna interessante quando h interdependncias entre as aes de vrias transaes que executam concorrentemente. Uma descrio muito boa dos paradigmas de cancelar/confirmar transaes aparece em Hammer e Shipman[1979]. A problemtica abordada no contexto do sistema SSD-1 e os mecanismos envolvidos so descritos em detalhe, incluindo o problema de se manter relgios globais sincronizados por todo o SGBD. Lindsay[1980] contm uma descrio, com algum detalhe, dos mecanismos de atas. J Kohler[1981] descreve e classifica vrias tcnicas usadas em controle de integridade, dedicando largo espao questo de como se construir funes internas que se mostrem seguras a usurios operando em camadas superiores do sistema. Stonebraker[1980] contm uma descrio dos algortmos usados para controle de integridade no sistema INGRES, bem como uma comparao destes algoritmos com outros descritos na literatura. Uma tentativa de formalizar o estudo da funo de controle de integridade aparece em Skeen e Stonebraker[1983]. A proposta usa mquinas de estados finitos para modelar o ambiente de um SGBDD, incluindo a rede de comunicao de dados. Apresenta alguns resultados negativos interessantes a respeito da robustez de classes de protocolos. O mtodo de imagens virtuais discutido na Seo 9.2 uma adaptao para um ambiente distribudo em que transaes so executadas concorrentemente do mtodo descrito por Lorie [1977]. Os problemas relativos a controle de concorrncia em dois nveis so abordados em Goodman e Lay [1983] e Lynch [1983].