RESUMO CAPTULO 16 OVERVIEW OF TRANSACTION MANAGEMENT

Prof.: Geovane Magalhes Alunos: Gabriela G. Martins Edmar R. S. de Rezende

NDICE ANALTICO

16.1 AS PROPRIEDADES ACID ......................................................................................................... 3 16.1.1 CONSISTNCIA E ISOLAMENTO ........................................................................................ 4 16.1.2 ATOMICIDADE E DURABILIDADE..................................................................................... 4 16.2 TRANSAES E AGENDAMENTOS......................................................................................... 4 16.3 EXECUO CONCORRENTE DE TRANSAES .................................................................... 5 16.3.1 MOTIVAO DE EXECUO CONCORRENTE ................................................................. 5 16.3.2 SERIALIZABILIDADE........................................................................................................... 5 16.3.3 IREGULARIDADES DEVIDO EXECUO PARALELA .................................................... 6 16.3.4 AGENDAS QUE ENVOLVEM TRANSAES FALHAS......................................................... 7 16.4 CONTROLE DE CONCORRNCIA LOCK-BASED.................................................................... 7 16.4.1 STRICT TWO-PHASE LOCKING .......................................................................................... 8 16.4.2 DEADLOCKS........................................................................................................................ 8 16.5 PERFORMACE DO MECANISMO DE LOCK............................................................................. 9 16.6 SUPORTE A TRANSAES EM SQL......................................................................................... 9 16.6.1 CRIANDO E TERMINANDO TRANSAES....................................................................... 10 16.6.2 O QUE DEVEMOS BLOQUEAR? ....................................................................................... 10 16.6.3 CARACTERSTICAS DAS TRANSAES EM SQL.............................................................. 11 16.7 INTRODUO RECUPERAO DE FALHAS..................................................................... 11 16.7.1 ROUBANDO FRAMES E FORANDO PGINAS ............................................................... 11 16.7.2 PASSOS RELACIONADOS RECUPERAO DURANTE UMA EXECUO NORMAL... 12 16.7.3 VISO GERAL DO ARIES................................................................................................... 12 16.7.4 ATOMICIDADE: IMPLEMENTANDO ROLLBACK ............................................................ 13

16 VISO

GERAL

SOBRE

GERENCIAMENTO

DE

TRANSAES
Neste captulo discutido o conceito sobre uma transao, que o ponto inicial para execuo concorrente e recuperao de falhas de sistemas em um SGBD. Uma transao definida como qualquer execuo de um programa usurio em um SGBD e difere da execuo de um programa ao lado de fora do SGBD em importantes aspectos. Por razes de performance, o SGBD deve paralelizar as aes de vrias transaes. Entretanto, para dar aos usurios uma maneira simples de entender a execuo de seus programas, a paralelizao feita cuidadosamente para garantir que o resultado da execuo concorrente de transaes equivalente a uma execuo serial do mesmo conjunto de transaes. O modo como o SGBD mantm execues concorrentes um aspecto importante do gerenciamento de transaes e ponto principal do controle de concorrncia. Um ponto atual como o SGBD mantm transaes parciais. O SGBD garante que as alteraes feitas por transaes parciais no so vistas por outras transaes. Esse o ponto principal para recuperao de falha. Na seo 16.1 so discutidas quatro propriedades fundamentais sobre transaes e como o SGBD as garante. Na seo 16.2 apresentada uma maneira abstrata para descrever a execuo concorrente de vrias transaes, chamada de escalonamento. Na seo 16.3 vrios problemas que podem surgir por causa da execuo concorrente so discutidos. O protocolo de controle de concorrncia lock-based introduzido na seo 16.4. Falhas de performance associadas ao protocolo lock-based so discutidas na seo 16.5. Bloqueio e propriedades das transaes no contexto SQL so considerados na seo 16.6. Finalmente, na seo 16.7 apresentada uma viso geral de como o sistema de banco de dados recupera-se de falhas e quais passos so tomados durante uma execuo normal para suportar recuperao de falhas.

16.1
escritas.

AS PROPRIEDADES ACID

Uma transao a execuo de um programa, vista pelo SGBD como uma srie de leituras e

Um SGBD deve garantir quatro propriedades de transao para manter os dados protegidos de acesso concorrente e de falhas de sistema: Atomicidade: A execuo de toda transao deve ser considerada atmica; ou

todas as aes so executadas ou nenhuma delas .; Consistncia: Cada transao deve preservar a consistncia do banco de dados; Isolamento: Toda transao isolada ou protegida das aes de outras transaes

concorrentes;

Durabilidade: Uma vez informada a concluso de uma transao de maneira

satisfatria, o SGBD deve persistir os resultados da transao mesmo que o sistema sofra uma queda antes que esses resultados sejam persistidos no disco. O acrnimo ACID utilizado para referncias das quatro propriedades citadas acima: atomicidade, consistncia, isolamento e durabilidade.

16.1.1

CONSISTNCIA E ISOLAMENTO

Os usurios so responsveis pela consistncia de uma transao. O SGBD no pode ser responsabilizado por erros de lgica no programa do usurio, os quais podem resultar em transaes que podero deixar o banco de dados em um estado inconsistente. O isolamento deve garantir que mesmo havendo aes de transaes concorrentes correndo em paralelo com as aes de uma determinada transao, o ltimo resultado deve ser o mesmo de quando as transaes so executadas de maneira serial.

16.1.2
1.

ATOMICIDADE E DURABILIDADE
uma transao pode ser interrompida, ou finalizada insatisfatoriamente, pelo SGBD

A causa de erros durante a execuo de transaes pode ser de trs tipos:

porque alguma anormalidade ocorreu durante sua execuo. Quando essa situao ocorre, a transao automaticamente reiniciada e re-executada. 2. o sistema pode sofrer uma queda enquanto uma ou mais transaes esto em

progresso; 3. prpria. O fato de uma transao poder ser interrompida ao meio pode deixar o banco de dados em um estado inconsistente. Por causa da propriedade de atomicidade, o SGBD deve garantir a retirada dos efeitos de transaes parciais do banco de dados. Para realizar isso, o SGBD mantm um registro, chamado log, de todos os dados que foram escritos no bando de dados. O log utilizado para garantir a propriedade de durabilidade se o sistema sofrer uma queda antes que as alteraes geradas por uma transao que foi executada satisfatoriamente forem persistidas em disco, o log utilizado para restaurar essas informaes quando o sistema for normalizado. uma transao pode encontrar uma situao inesperada e resolver interromper a si

16.2

TRANSAES E AGENDAMENTOS

Uma transao vista pelo SGBD como um conjunto de aes. Dentre as aes que podem ser executadas por uma transao temos a leitura e a escrita. Para mantermos uma notao simples, assumiremos que o objeto O sempre lido de uma varivel de programa de mesmo nome. Denotaremos, ento, a ao de uma transao T lendo o objeto O como RT(O). Similarmente,

denotaremos a escrita como W T(O). Na situao da transao T ser excluda do contexto, omitiremos o subscrito. Alm disso, toda transao deve especificar commit ou abort como ao final. Tais aes sero representadas por CT ou AT, respectivamente. Nesse ponto, faremos as seguintes consideraes: Transaes interagem entre si apenas via banco de dados; no permitida a troca de mensagens; Um banco de dados uma coleo fixa de objetos independentes.

Um escalonamento uma lista de aes vindas de um conjunto de transaes. A ordem dos elementos da lista de aes deve seguir a ordem desses elementos em suas transaes. Podemos considerar que um escalonamento uma seqncia de execuo.

16.3

EXECUO CONCORRENTE DE TRANSAES

O SGBD paraleliza as aes de transaes diferentes para melhoramento da performance, mas nem todo paralelismo deve ser permitido.

16.3.1

MOTIVAO DE EXECUO CONCORRENTE

Garantir o isolamento da transao enquanto cada execuo concorrente permitida difcil mas necessrio por razes de performance. Primeiramente, enquanto uma transao espera para ler uma pgina do disco, a CPU pode processar outra transao. Isso possvel porque a atividade de I/O pode ser feita em paralelo com a atividade da CPU. Alm disso, paralelizar a execuo de uma transao pequena com a execuo de uma transao mais complexa normalmente permite que a primeira seja finalizada rapidamente. Numa execuo serial, uma transao pequena poderia ser temporariamente bloqueada por uma transao complexa, levando a esperas no previstas no tempo de resposta ou aumentando o tempo gasto para completar uma transao.

16.3.2

SERIALIZABILIDADE

Um escalonamento serializvel aplicado sobre um conjunto S de transaes finalizadas satisfatoriamente um escalonamento cujo efeito sobre qualquer instncia de banco de dados consistente ser idntico a um escalonamento serial aplicado a S. Isto , a instncia do banco de dados resultante do escalonamento citado idntica instncia do banco de dados resultante da execuo de transaes em alguma ordem serial. A execuo de transaes de forma serial em ordens diferentes pode produzir resultados diferentes, porm, assume-se que todos sero aceitveis; o SGBD no d garantias de qual delas ser conseqncia de uma transao paralela.

Um SGBD deve executar as transaes, em algumas vezes, por caminhos no equivalentes a qualquer execuo serial; ou seja, utilizando um escalonamento que no serializvel. Isso pode acontecer por duas razes: 1. o SGBD deve utilizar um mtodo para controle de concorrncia que garanta o escalonamento utilizado; 2. SQL d aos programadores de aplicao a opo de instruir o SGBD a escolher escalonamentos no-serializveis.

16.3.3

IREGULARIDADES DEVIDO EXECUO PARALELA

Existem trs principais caminhos em que um escalonamento de transaes finalizadas satisfatoriamente poderiam ser aplicadas a uma base de dados consistente e deix-la em um estado inconsistente. Duas aes aplicadas a um mesmo objeto so conflitantes se, pelo menos uma delas, a ao de escrita. As trs situaes irregulares podem ser descritas em termos de quando as aes de duas transaes T1 e T2 so conflitantes: em uma escrita-leitura, T2 l um objeto antes do objeto ser escrito por T1; os conflitos de leitura-escrita e escrita-escrita so definidos de maneira semelhante. LENDO DADOS NO PERSISTIDOS (CONFLITOS DE ESCRITA-LEITURA) A primeira fonte de irregularidades que uma transao T2 poderia ler um objeto de banco de dados A que vm sendo modificado por uma outra transao T1 e que ainda no foi persistido. Tal leitura chamada leitura suja. T1 R(A) W(A) R(A) W(A) R(B) W(B) Commit R(B) W(B) Commit Tabela 1 - Leitura de Dados no Persistidos T2

LEITURAS NO-REPETVEIS (CONFLITOS DE LEITURA-ESCRITA)

O segundo caminho em que comportamentos irregulares poderiam resultar que uma transao T2 poderia alterar o valor de um objeto A que est sendo lido por uma transao T1, enquanto T1 ainda est em progresso. Se T1 tentar ler o valor de A novamente, ter um resultado diferente. Isso chamado de leitura no-repetvel. EXCESSO DE ESCRITAS EM DADOS NO PERSISTIDOS (CONFLITOS DE ESCRITAESCRITA) A terceira fonte de comportamento irregular que a transao T2 poderia reescrever o valor de um objeto A, o qual j havia sido alterado por uma transao T1, a qual ainda est em progresso. Esse tipo de leitura chamado de leitura cega.

16.3.4

AGENDAS QUE ENVOLVEM TRANSAES FALHAS

Intuitivamente, todas as aes de transaes falhas devem ser desfeitas. A definio de escalonamentos serializveis ser extendida como se segue: um escalonamento serializvel aplicada a um conjunto S de transaes uma agenda cujo efeito em qualquer instncia consistente de banco de dados idntico quele de uma agenda serial aplicada a um conjunto de transaes finalizadas em S. Essa definio tambm vlida para aes de transaes falhas, no caso de serem desfeitas completamente, o que pode ser impossvel em certas situaes. Supondo que uma transao T2 reescreva o valor do objeto A que est sendo modificado por uma transao T1, a qual est ainda em progresso, e T1 falha. Todas as mudanas de T1 so desfeitas, ou seja, todo objeto modificado por T1 ser restaurado com o valor que possua antes de sofrer a ao de T1. Sendo assim, as alteraes de T2 so perdidas, mesmo que T2 decida realizar o commit.

16.4

CONTROLE DE CONCORRNCIA LOCK-BASED

Um SGBD deve garantir que apenas escalonamentos serializveis e recuperveis sejam permitidos e que nenhuma ao de transaes finalizadas sejam perdidas enquanto transaes que falharam so desfeitas. O SGBD utiliza um protocolo de travamento para realizar isso. Um lock um pequeno objeto de histrico associado a um objeto de banco de dados. Um protocolo de travamento um conjunto de regras a serem seguidas por cada transao para garantir que, mesmo que as aes de vrias transaes forem paralelizadas, o resultado final idntico ao resultado de executar todas as transaes de maneira serial. Cada protocolo de travamento utiliza locks diferentes, como locks compartilhados ou locks exclusivos.

16.4.1
regras:

STRICT TWO-PHASE LOCKING

O protocolo de travamento mais utilizado, tambm denominado de STRICT 2PL, possui duas

1. Se uma transao T deseja ler um objeto, ela primeiramente efetua a requisio de um lock exclusivo para o objeto. Uma transao que possui um lock exclusivo pode tambm ler um objeto. Ao realizar a requisio a transao suspensa at que o SGBD esteja apto a conceder o lock requerido. Alm disso, uma pilha do lock mantida e existe a garantia de que se uma transao consegue um lock exclusivo ou compartilhado para um determinado objeto, nenhuma outra transao ir conseguir um lock exclusivo ou compartilhado para o mesmo objeto. 2. Todos os locks conseguidos por uma transao so liberados quando a transao completada. Os pedidos para adquirir ou libertar locks podem ser automaticamente inseridos nas transaes pelo SGBD. O protocolo de travamento fornece apenas segurana para transaes paralelizadas. Se duas transaes acessam partes do banco de dados completamente independentes, elas obtm os locks de forma concorrente e prosseguem. Por outro lado, se duas transaes acessam o mesmo objeto e uma delas deseja modific-lo, suas aes so ordenadas serialmente todas as aes de uma dessas transaes so completadas antes que outra transao possa prosseguir.

16.4.2

DEADLOCKS

Assumindo T1 e T2 como transaes, considere o exemplo a seguir transao T1 adquire um lock exclusivo para o objeto A; T2 adquire um lock exclusivo para o objeto B; T1 requisita um lock exclusivo para o objeto B e o pedido armazenado numa fila; T2 requisita um lock exclusivo para o objeto A e o pedido armazenado numa fila.

Desta forma, T1 est aguardando que T2 liberte o lock do objeto B e T2 est aguardando que T1 liberte o lock do objeto A. Tal ciclo de transaes aguardando a liberao de locks chamado de deadlock. Fica claro que essas transaes no tero progresso. Ou pior, podem estar solicitando locks que esto sendo requeridos por outras transaes. O SGBD deve prever ou detectar (e resolver) qualquer situao de deadlock. Uma maneira simples de detectar deadlocks utilizar um mecanismo de timeout. Se uma transao tem aguardado muito tempo por um pedido de lock, pode-se assumir que um ciclo de deadlock foi detectado e escolhe-se por abort-lo.

16.5

PERFORMACE DO MECANISMO DE LOCK

Esquemas baseados em lock so projetados para resolver conflitos entre transaes e usam dois mecanismos bsicos: bloqueio e aborto. Ambos os mecanismos acarretam em uma penalidade na performance: transaes bloqueadas podem obter locks que forcem outras transaes a esperar, causando o aborto e o reincio da transao, resultando obviamente na perda de todo o trabalho realizado pela transao. Um deadlock representa uma instncia extrema de um bloqueio no qual um conjunto de transaes fica bloqueado eternamente, a no ser que uma das transaes que faz parte do deadlock seja abortada pelo SGBD. Na prtica, pouco menos de 1% das transaes ficam envolvidas em um deadlock, resultando em relativamente poucos abortos. Contudo, o overhead dos locks devido principalmente aos atrasos causados pelos bloqueios. Analisando o impacto do mecanismo de bloqueio sobre as transaes, podemos perceber que em um primeiro momento existem poucas transaes com poucos conflitos. medida que o nmero de transaes ativas cresce o throughput tambm cresce na mesma proporo. Como mais e mais transaes so executadas concorrentemente sobre o mesmo nmero de objetos, os impactos do mecanismo de lock comeam a aparecer. O throughput comea a crescer de forma mais lenta, at o ponto em que comea a ser reduzido, devido ao crescimento do nmero de bloqueios causado pelo aumento do nmero de transaes ativas. Throughput pode ser aumentado de trs formas: Realizando o lock nas menores partes possveis dos objetos (minimizando a possibilidade de duas transaes necessitarem do mesmo lock). Reduzindo o tempo que uma transao permanece com o lock (assim outras transaes sero bloqueadas por perodos de tempo mais curtos). Reduzindo os hot spots. Um hot spot um objeto da base de dados que freqentemente acessado e modificado, causando um grande atraso em relao aos bloqueios. Hot spots podem afetar significativamente a performance.

16.6

SUPORTE A TRANSAES EM SQL

At o momento, as transaes e o gerenciamento de transaes tm sido estudados usando um modelo abstrato de uma transao como uma seqncia de leituras, escritas, e aes de abort / commit. Nesta seo ser considerado o suporte que o SQL prov para os usurios especificarem o comportamento no nvel de transao.

16.6.1

CRIANDO E TERMINANDO TRANSAES

Uma transao automaticamente iniciada quando um usurio executa uma instruo que acessa a base de dados ou os catlogos, tais como uma consulta SELECT, um comando UPDATE, ou uma instruo CREATE TABLE. Uma vez que uma transao foi iniciada, outras instrues podem ser executadas como parte desta transao at a transao terminar com um comando de COMMIT ou um comando de ROLLBACK (a palavra chave no SQL que faz o papel do abort). O SQL:1999 inclui duas novas funcionalidades para suportar aplicaes que envolvem transaes de longa durao. A primeira chamada de savepoint, que permite identificar um ponto seguro em uma transao para onde realizar operaes de rollback em caso de falha. Isto feito utilizando os comandos: SAVEPOINT <nome do savepoint> ROLLBACK TO SAVEPOINT <nome do savepoint> A segunda o mecanismo de transaes encadeadas, que permite realizar o commit ou o rollback em uma transao e imediatamente iniciar outra transao. Isto feito utilizando a expresso AND CHAIN em um COMMIT ou um ROLLBACK.

16.6.2

O QUE DEVEMOS BLOQUEAR?

Uma questo importante a considerar no contexto de SQL o que o SGBD deve tratar como um objeto durante a atribuio de locks para uma determinada expresso SQL? O SGBD pode conceder locks a objetos de diferentes granularidades: podemos ter o lock para uma tabela inteira ou apenas para uma linha da tabela. Esta ltima abordagem adotada nos sistemas atuais pelo fato de oferecer uma melhor performance. Na prtica, apesar do lock no nvel de linhas da tabela ser geralmente melhor, a escolha da granularidade do lock uma deciso complicada. Uma transao que examina vrias linhas e modifica aquelas que satisfazem uma determinada condio pode tirar proveito de um esquema onde locks compartilhados so atribudos toda a tabela e locks exclusivos so atribudos s linhas da tabela. Alm disso, dependendo de como os locks so atribudos, pode ocorrer o problema conhecido como o problema do fantasma. Esse problema pode fazer com que uma transao acesse um conjunto de tuplas duas vezes seguidas e encontre valores diferentes em cada uma delas, mesmo que no tenha modificado tais tuplas. Para evitar o problema do fantasma, o SGBD deve conceitualmente realizar o lock em todas as possveis linhas contendo o valor procurado. Uma forma de fazer isso realizando o lock de toda a tabela, diminuindo assim a concorrncia. Tambm possvel tirar proveito dos ndices para alcanar um melhor resultado, mas em geral a preveno do problema do fantasma impacta significativamente na concorrncia.

16.6.3

CARACTERSTICAS DAS TRANSAES EM SQL

Para permitir que o programador tenha controle sobre o overhead causado pelo mecanismo de lock sobre suas transaes, o SQL permite que sejam especificadas trs caractersticas de uma transao: modo de acesso, tamanho do diagnstico e nvel de isolamento. O tamanho do diagnstico determina o nmero de condies de erro que podem ser gravadas. J o modo de acesso pode ser READ ONLY ou READ WRITE. No modo de acesso READ ONLY no permitido transao modificar a base de dados. Assim, os comandos INSERT, DELETE, UPDATE e CREATE no podem ser executados. Caso esses comandos precisem ser executados, o modo de acesso READ WRITE deve ser utilizado. Com o modo de acesso READ ONLY, apenas locks compartilhados precisam ser obtidos, aumentando assim a concorrncia. O nvel de isolamento controla o quanto uma determinada transao est exposta ao de outras transaes executando concorrentemente. Optando por um dos quatro nveis de isolamento possveis, o usurio poder obter um alto grau de concorrncia, aumentando contudo o grau de exposio a modificaes ainda no efetivadas por transaes. As opes de nveis de isolamento so: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ e SERAILIZABLE. O mais alto grau de isolamento proporcionado pelo nvel SERIALIZABLE, onde a transao obtm os locks antes da leitura ou escrita de objetos e os libera apenas ao fim de sua execuo, de acordo com o protocolo Strict 2PL. Alm disso, este nvel de isolamento geralmente o mais seguro e recomendado para a maioria das transaes. Quando uma transao iniciada, por padro ela definida como SERIALIZABLE e READ WRITE.

16.7

INTRODUO RECUPERAO DE FALHAS

O gerenciador de falhas do SGBD responsvel por garantir a atomicidade e a durabilidade das transaes. Ele garante a atomicidade desfazendo as aes de transaes que no realizaram o commit, e a durabilidade garantindo que todas as aes de transaes que realizaram o commit sobrevivero a falhas do sistema. Quando um SGBD reinicia aps uma falha, o gerenciador de recuperao assume o controle e deve retornar a base de dados a um estado consistente. Comumente assumimos que as escritas em disco so operaes atmicas, ou seja, no possvel ocorrer falhas durante a operao de escrita. No entanto, tal hiptese no nada realista. Na prtica, as escritas em discos no possuem essa propriedade, e a alguns passos devem ser realizados durante a reinicializao aps uma falha, para verificar quais escritas mais recentes em uma determinada pgina foram bem sucedidas e para poder lidar com aquelas que no foram.

16.7.1

ROUBANDO FRAMES E FORANDO PGINAS

Com relao escrita de objetos, duas questes adicionais podem surgir:

As modificaes feitas em um objeto O no buffer pool por uma transao T pode ser escrita no disco antes de T realizar o commit? Tais escritas so executadas quando outra transao precisa carregar uma pgina e o gerenciador de buffer opta por substituir o frame contendo O. Obviamente, esta pgina deve ser salva por T. Se tal escrita permitida, dizemos que uma abordagem de roubar est sendo usada.

Quando uma transao realiza o commit, deve ser garantido que todas as transaes feitas sobre objetos no buffer pool sejam imediatamente escritas em disco? Se a resposta sim, ento dizemos que uma abordagem de forar est sendo utilizada.

Estas polticas possuem conseqncias importantes. Se uma abordagem de no roubar assume que todas as pginas modificadas pelas transaes em andamento podem ser acomodadas no buffer pool, na presena de grandes transaes essa hiptese no muito realista. J a abordagem de forar resulta em um nmero excessivo de operaes de entrada/sada. Por estas razes, muitos sistemas utilizam uma abordagem baseada em roubar e no forar.

16.7.2

PASSOS RELACIONADOS RECUPERAO DURANTE

UMA EXECUO NORMAL

O gerenciador de recuperao de um SGBD mantm algumas informaes durante uma execuo normal das transaes para permitir que ele consiga realizar sua tarefa durante uma falha. Em particular, um log de todas as modificaes realizadas na base de dados salvo em um meio de armazenamento estvel. importante garantir que todas as entradas no log descrevendo as modificaes na base de dados sejam escritas em um meio de armazenamento estvel antes das respectivas modificaes serem feitas. Caso contrrio, o sistema pode falhar imediatamente aps uma modificao na base de dados sem existir um registro correspondente no log. Este mtodo de escrita no log conhecido como Write-Ahead Log, ou simplesmente WAL. O log permite ao gerenciador de recuperao desfazer as aes de transaes abortadas ou no completadas e refazer as aes de transaes que realizaram o commit.

16.7.3

VISO GERAL DO ARIES

O ARIES um algoritmo de recuperao que projetado para trabalhar com uma abordagem de roubar e no forar. Quando o gerenciador de recuperao invocado aps uma falha, o reincio se procede em trs fases: Fase de Anlise: identifica pginas sujas no buffer pool e transaes ativas no momento da falha. Fase de Refazer: repete todas as aes, comeando do ponto apropriado no log e restaura o estado da base de dados idntico ao momento da falha.

Fase de Desfazer: desfaz as aes das transaes que no realizaram o commit, de forma que a base de dados reflita apenas as aes das transaes que realizaram o commit.

16.7.4

ATOMICIDADE: IMPLEMENTANDO ROLLBACK

importante destacar que o subsistema de recuperao tambm responsvel pela execuo do comando ROLLBACK, que aborta uma transao. De fato, a lgica envolvida em desfazer uma transao idntica lgica usada durante a fase de desfazer do mecanismo de recuperao de uma falha do sistema. Todos os registros de uma determinada transao so organizados em uma lista ligada e podem ser eficientemente acessados na ordem reversa para facilitar o rollback da transao.