0DUFR$QWRQLR&DVDQRYD

Departamento de Informatica
Pontificia Univeraidade CatIica do Rio de ]aneiro
$UQDOGR9LHLUD0RXUD
Inatituto de Computao
UNICAMP
3ULQFtSLRV
GH
6LVWHPDVGH*HUrQFLD
GH
%DQFRVGH'DGRV'LVWULEXtGRV
Edio reviaada diatribuio reatrita
1999, Marco Antonio Caaanova e ArnaIdo Vieira Moura
- 2 - 2
PREFCIO
Um banco de dados um repositrio integrado e compartilhado dos dados operacionais de
um empreendimento. Um sistema de gerncia de bancos de dados uma ferramenta destinada
a isolar os programas de aplicao dos detalhes de armazenamento do banco, controlando o
acesso ao banco e evitando inconsistncias ou acessos indevidos, entre outros requisitos
funcionais.
Com tal, nos ltimos 25 anos, sistemas de gerncia de bancos de dados tm representado um
papel fundamental para o desenvolvimento de sistemas de informao. Estes sistemas
adotaram nos primeiros anos uma arquitetura centralizada, no sentido de que o banco de
dados reside em um nico processador central, principalmente por razes de economia de
escala e controle dos dados. Por outro lado, o avano das tcnicas e o barateamento dos
servios de comunicao de dados tornaram possvel e atrativo migrar para sistemas de
informao com uma arquitetura distribuda. Esta evoluo levou naturalmente criao de
bancos de dados tambm distribudos, onde a responsabilidade de armazenamento,
atualizao e controle dos dados dividida entre vrios locais. A comunidade destes bancos
de dados locais deve ser interligada e coordenada por um sistema de gerncia de bancos de
dados distribudos (SGBDD) que permita acesso a dados remotos de forma transparente e
confivel, mas mantenha a autonomia dos bancos locais.
O desenvolvimento de SGBDDs de uso geral lanou um novo desafio em vrias reas, como
processamento de consultas, gerncia de transaes e, em especial, controle de integridade e
controle de concorrncia. O propsito deste livro reunir as tcnicas mais relevantes
resultantes de pesquisa nestas reas, de forma coerente e acessvel a profissionais e estudantes
com interesse em software de base para bancos de dados ou sistemas distribudos em geral.
ORGANIZAO DO LIVRO
A construo de um SGBDD de uso geral uma tarefa no trivial, comparvel criao de
um sistema operacional sofisticado. O Captulo 1 abre a discusso introduzindo uma
arquitetura genrica para estes sistemas, que acompanhada de uma lista de requisitos
funcionais para SGBDDs, e uma caracterizao das principais interfaces oferecidas por um
SGBDD aos usurios. Aps este trabalho preliminar, possivel enunciar claramente quais
so as principais funes de um SGBDD. Este primeiro captulo age, desta forma, como um
resumo conciso e estruturado do livro, servindo de guia para todo o material que se segue.
O segundo captulo entra em mais detalhes sobre o que so bancos de dados distribudos
(BDDs). Este captulo cobre resumidamente os aspectos relativos descrio, projeto, e
administrao de BDDs, indicando em que pontos diferem do caso centralizado.
Os Captulos 3 a 5 discutem em detalhe o processamento de comandos da linguagem de
manipulao de dados (LMD), o primeiro dos grandes problemas discutidos no livro. O
Captulo 3 contm um resumo dos outros dois, alm de definir a LMD e o subsistema de
armazenamento local
que sero usados como exemplo no transcorrer do livro. Estes dois fatores definem a misso
do processador de comandos da LMD: este dever compilar (ou interpretar) os comandos da
LMD em chamadas para o subsistema de armazenamento. O Captulo 3 termina com um
- 3 - 3
exemplo detalhado ilustrando as diversas fases por que passa o processamento de uma
consulta.
O Captulo 4 discute exaustivamente o processamento de comandos da LMD no caso
centralizado. A maior parte deste captulo investiga como desmembrar uma consulta
arbitrria em uma srie equivalente de consultas mais simples que possam ser convertidas em
chamadas para o subsistema de armazenamento. Como em geral h um enorme nmero de
possveis desmembramentos, o problema de escolher um desmembramento timo tambm
abordado em detalhe. O processamento de atualizaes deixado para o final, pois no
apresenta problemas substancialmente mais difceis do que aqueles encontrados ao se
processar consultas.
O Captulo 5 repete a mesma discusso para o caso distribudo. As vrias opes abertas para
processamento de consultas distribudas so inicialmente enumeradas. Em seguida, trs delas
so discutidas em detalhe, incluindo uma extenso direta da tcnica de desmembramento
usada no caso centralizado. A maior nfase recai, naturalmente, nos pontos em que o caso
distribudo mais complexo e exige solues novas, quando comparado com o caso
centralizado.
Os prximos quatro captulos so dedicados gerncia de transaes. O Captulo 6 introduz,
inicialmente, o conceito de transao. Em seguida, analisa os problemas que surgem quando
vrias transaes so processadas simultaneamente em um ambiente distribudo, em presena
de falhas de diversos tipos. A soluo destes problemas vital para assegurar o prprio
princpio de atomicidade em relao a cada transao submetida ao SGBDD. Ser necessrio
lanar-se mo de mecanismos especiais para controle de incio, migrao e trmino de
transaes distribudas, controle de concorrncia e controle de integridade. No Captulo 6 so
esboadas solues para cada um destes problemas. Os Captulos 7 a 9 dedicam-se tarefa de
detalhar, em profundidade, os principais mecanismos envolvidos nas solues propostas.
No Captulo 7 so estudados que mecanismos devem ser acionados quando do incio de uma
transao, a expor tcnicas para controlar a migrao de transaes e, finalmente, apresentar
algoritmos ou protocolos que, ao trmino da transao, garantem sua atomicidade, esta ltima
sendo de crucial importncia para o correto funcionamento do banco de dados. Inicialmente,
revisto o ambiente distribudo onde a transao opera. Em seguida, so examinados em
detalhe os mecanismos que atuam quando do nicio, migrao e trmino de transaes.
O Captulo 8 aborda o problema de controle de concorrncia. As principais anomalias que
surgem com execuo simultnea de transaes so ilustradas. Em seguida, os rudimentos da
teoria de serializao so elaborados, indicando-se clara e precisamente quando um
mecanismo de controle de concorrncia deve ser considerado correto. Dois mtodos para
construo de mecanismos de controle de concorrncia so ento discutidos: bloqueio e pr-
ordenao. Em primeiro lugar, o mtodo de bloqueio discutido detalhadamente para o caso
centralizado. Isto feito, uma famlia de mecanismos usando tcnicas de bloqueio distribudo
apresentada. Por fim, so definidos vrios mecanismos que seguem a metodologia de pr-
ordenao.
Finalmente, o Captulo 9 descreve duas tcnicas de controle de integridade. A primeira
tcnica baseia-se em um mecanismo de atas, armazenado todas as alteraes feitas em um
banco de dados local. Conquanto a idia bsica seja simples, devido ao fato de que operam
em ambientes complexos, atas enfrentam problemas de sincronismo, de eficincia e de
eficcia, que geram mecanismos de controle de integridade bastante sofisticados. A segunda
- 4 - 4
tcnica utiliza a idia de manter-se duas verses para cada pgina de dados: a verso
certificada, criada pela ltima transao que terminou corretamente, e a verso corrente. A
implementao desta tcnica apresentada de forma incremental at ser possvel abranger
tambm mecanismos de controle de concorrncia. Ambas as tcnicas implementam proteo
contra determinados tipos de falhas que ocasionam a perda do contedo da memria
principal, ou mesmo a perda de partes da memria secundria. Tambm permitem desfazer os
efeitos de uma transao executada parcialmente.
O texto est organizado em ordem crescente de complexidade. Aps o material introdutrio
dos Captulos 1 e 2, o Captulo 4 apresenta em uma viso do sistema onde h apenas um
usurio, em um ambiente centralizado e em presenca de um meio perfeito e sem falhas. O
Captulo 5 expande esta viso para um ambiente distribudo. Em seguida, os Captulos 7 e 8
introduzem mltiplos usurios. O cenrio completado com o Captulo 9 quando so
consideradas falhas. Os Captulos 1, 2, 3 e 6 apresentam uma viso simplificada, porm
completa, de todo este material.
POSSVEIS USOS PARA O LIVRO
O texto, como um todo, foi preparado tendo em vista um segundo curso na rea de Banco de
Dados, tanto a nvel de graduao quanto de ps-graduao. A durao tima do curso seria
em torno de 55 horas. Quando usado a nvel de graduao, as sees marcadas com asterisco
podero ser omitidas e os diversos mtodos ilustrados atravs de exemplos, mais do que
atravs de uma anlise dos algoritmos. A nvel de ps-graduao, o ritmo do curso pode ser
acelerado, deixando uma margem de tempo para cobrir material adicional referenciado nas
notas bibliogrficas.
Para facilitar outros usos do livro, alguma redundncia foi introduzida no texto. Os Captulos
1, 2, 3 e 6 podem ser cobertos independentemente dos outros e formam a base de um curso
para profissionais. Podero ser cobertos em 12 a 16 horas, dependendo naturalmente do nvel
de detalhe e do desenrolar pretendido para o curso.
O material dos dois primeiros captulos pode ser usado em um primeiro curso de banco de
dados para cobrir os conceitos e facilidades bsicas de sistemas de bancos de dados
distribudos. Dependendo do nvel de detalhe, o material pode ser coberto em menos de 8
horas de aula regular (menos de 4 horas se transparncias forem usadas).
O primeiro formato foi testado em um curso oferecido no Departamento de Matemtica da
UnB, no segundo semestre de 1983, como parte de um convnio firmado entre esta e o
Centro Cientfico da IBM. Tambm foi parcialmente testado por um dos autores no
Departamento de Informtica da PUC/RJ, no segundo semestre de 1981, enquando professor
daquele Instituio. Vrios cursos com o segundo formato foram oferecidos no Departamento
de Treinamento da Embratel, em 1981, e no Instituto Latino-Americano de Pesquisa em
Sistemas da IBM, em 1984.
O texto no inclui exerccios pois o material no se presta bem a este tipo de avaliao.
Sugere-se medir o desempenho dos alunos atravs de trabalhos de pesquisa, divididos
conforme os tpicos cobertos em cada captulo, e baseados na bibliografia fornecida.
- 5 - 5
AGRADECIMENTOS
A primeira verso deste texto foi preparada, como parte de um projeto interno dos autores,
para a Quarta Escola de Computao, realizada no Instituto de Matemtica e Estatstica da
USP de 12 a 20 de julho de 1984. Os autores gostariam de agradecer a gerncia do Centro
Cientfico da IBM, inicialmente na pessoa do Dr. Jean Paul Jacob e posteriormente na pessoa
do Sr. Jos Roberto Giannini de Freitas, por terem acolhido entusiasticamente esta iniciativa.
Os agradecimentos tambem so estendidos comisso organizadora da Quarta Escola e, em
especial, ao Prof. Routo Terada, coordenador do evento, pela oportunidade que nos foi dada
para escrever este texto.
Vrias pessoas contriburam para que o texto pudesse ser escrito no curto espao de tempo
que tivemos. As nossas esposas, Silvia e Vera, no escaparam de revisar partes do texto.
Vera, em especial, ajudou-nos a evitar anglicismos imperdoveis (o que no implica que os
que restaram sejam aceitveis). Aos doutores Lineu C. Barbosa e Glen Langdon, Jr., do
Laboratrio de Pesquisas da IBM em San Jose, California, fica um agradecimento especial
pela cooperao, de vrias formas, prestada durante a estada de um dos autores naquele
Laboratrio quando o texto foi impresso. Este rduo passo de formatao e finalizao no
teria sido possvel sem esta valiosa ajuda. A tarefa herclea de acentuar as centenas de
pginas do livro no seria concluda se no fosse a ajuda de Denise Carvalho de Morais e
Rosa Maria Correia Cabral. Denise, na verdade, acentuou quase metade do texto. Rosa
tambm cuidou para que a impresso inicial fosse feita a tempo.
Por fim, o texto foi formatado utilizando-se GML como linguagem de formatao. A verso
final do texto foi processada por JANUS e impressa diretamente em uma impressora IBM
6670/APA, de alta resoluo. JANUS um formatador experimental desenvolvido no
Laboratrio de Pesquisas da IBM em San Jose, California, por uma equipe liderada pelo Dr.
Donald D. Chamberlin. Agradecemos especialmente a ajuda prestada pelo Dr. Bradford W.
Wade na transformao da verso corrente de JANUS para que acomodasse as necessidades
de acentuao da lngua portuguesa. O uso de uma impressora de alta resoluo economizou-
nos a tediosa tarefa de datilografar o texto final, liberando-nos, pelo menos, mais 45 dias para
terminar a verso preliminar. Por outro lado, a flexibilidade alcanada pelo uso de um editor
de textos, levou-nos a cair na tentao de infinitas revises.
Marco A. Casanova
Arnaldo V. Moura
Braslia, junho de 1984
- 6 - 6
NDICE
PREFCIO
1 CONCEITOS BSICOS
1.1 INTRODUO
1.1.1 O que um Sistema de Gerncia de Bancos de Dados Distribudos
1.1.2 Por Que Bancos de Dados Distribudos?
1.1.3 Arquitetura Genrica para SGBDs Distribudos
1.1.4 Tipos de SGBDs Distribudos
1.1.5 Classes de Usurios de um SGBD Distribudo
1.2 REQUISITOS FUNCIONAIS DE UM SGBD DISTRIBUDO
1.2.1 Independncia Fsica de Dados
1.2.2 Independncia de Localizao e Replicao
1.2.3 Autonomia Local
1.2.4 Interfaces de Muito Alto Nvel
1.2.5 Otimizao Automtica
1.2.5 Reestruturao Lgica do Banco e Suporte a Vises
1.2.7 Segurana dos Dados
1.2.8 Suporte Administrao dos Dados
1.3 ESPECIFICAO DAS INTERFACES DE UM SGBD DISTRIBUDO
1.3.1 Interfaces Globais e Locais
1.3.2 Especificao das Interfaces
1.3.3 Influncia do Tipo de SGBD Distribudo sobre as Interfaces
1.4 Principais Funes de um SGBD Distribudo
1.4.1 Refinamento da Arquitetura de um SGBD Distribudo
1.4.2 Ciclo de Processamento em um SGBD Distribudo
1.4.3 Armazenamento do Diretrio de Dados
1.4.4 Armazenamento do Banco de Dados
1.4.5 Processamento de Comandos da Linguagem de Manipulao de Dados
1.4.5 Gerncia de Transaes
1.4.7 Controle de Integridade
1.4.8 Controle de Concorrncia
1.4.9 Controle de Acesso ao Banco
- 7 - 7
2. BANCOS DE DADOS DISTRIBUDOS
2.1 ESPECIFICAO DE BANCOS DE DADOS DISTRIBUDOS
2.1.1 Descrio de Bancos de Dados Centralizados
2.1.2 Descrio de Bancos de Dados Distribudos
2.1.3 Um Exemplo da Descrio de Bancos de Dados Distribudos
2.2 PROJETO DE BANCOS DE DADOS DISTRIBUDOS
2.3 ADMINISTRAO DE BANCOS DE DADOS DISTRIBUDOS
2.3.1 Organizao e Tarefas da Equipe de Administrao
2.3.2 Problemas que Afetam a Administrao
3. INTRODUO AO PROCESSAMENTO DE COMANDOS DA LMD
3.1 ETAPAS DO PROCESSAMENTO DE COMANDOS DA LMD
3.2 UMA LINGUAGEM DE DEFINICAO E MANIPULAO DE DADOS
RELACIONAL
3.2.1 Definio de Esquemas de Relao em SQL
3.2.2 Consultas em SQL
3.2.3 Atualizaes em SQL
3.2.4 Definio de Esquemas Externos e Mapeamentos em SQL
3.3 O SUBSISTEMA DE ARMAZENAMENTO
3.3.1 O Nvel Interno do SAR
3.3.3.1 Estruturas Internas
3.3.3.2 Operaes sobre Tabelas
3.3.2 O Nvel Fsico do SAR
3.3.3 Definio dos Esquemas Internos
3.4 EXEMPLO DO PROCESSAMENTO DE UMA CONSULTA
4. PROCESSAMENTO DE COMANDOS DA LMD - O CASO CENTRALIZADO
4.1 INTRODUO AO PROCESSAMENTO DE CONSULTAS
4.2 CLASSIFICAO DE CONSULTAS
4.3 TRADUO PARA O ESQUEMA CONCEITUAL
4.4 TRADUO PARA O ESQUEMA INTERNO
4.4.1 Processamento de Consultas Homogneas
4.4.2 Desmembramento de Consultas
4.4.3* Algoritmos de Desmembramento
- 8 - 8
4.4.4 Descrio Final da Soluo
4.5 OTIMIZAO
4.5.1 Pesquisa Exaustiva da Soluo tima
4.5.2 Desmembramento Controlado - Parte I
4.5.3* Desmembramento Controlado - Parte II
4.5.4* Estimativa de Custo
4.6 PROCESSAMENTO DE ATUALIZAES
5. PROCESSAMENTO DE COMANDOS DA LMD - O CASO DISTRIBUDO
5.1 INTRODUO AO PROCESSAMENTO DE CONSULTAS
5.1.1 Discusso Geral
5.1.2 Estratgias de Processamento
5.1.3 Interface com o Gerente de Transaes
5.2 PROCESSAMENTO CENTRALIZADO COM REDUO
5.2.1 Introduo
5.2.2 Envelopes, Redutores e Semi-junes
5.2.3 Otimizao
5.3 DESMEMBRAMENTO CONTROLADO DISTRIBUDO - PARTE I
5.3.1 Fases do Desmembramento
5.3.2 Tratamento de Fragmentos
5.3.3 Desmembramento Propriamente Dito
5.3.4 Processamento de Consultas Homogneas
5.4 DESMEMBRAMENTO CONTROLADO DISTRIBUDO - PARTE II
5.5 PROCESSAMENTO DE ATUALIZAES
6. INTRODUO GERNCIA DE TRANSAES
6.1 O CONCEITO DE TRANSAO
6.1.1 Noes Bsicas
6.1.2 Transaes
6.2 EXECUTANDO TRANSAES: INCIO, MIGRAO E TRMINO
6.3 FALHAS NO SISTEMA
6.3.1 Tipos de Falhas
6.3.2 Proteo Contra Falhas
6.3.3 Programas Restauradores
6.3.3.1 Descargas
6.3.3.2 Arquivos Diferenciais
- 9 - 9
6.3.3.3 Atas
6.3.3.4 Imagens Transientes
6.3.3.5 Resumo
6.4 CONTROLE DE CONCORRNCIA
6.4.1 Colocao do Problema
6.4.2 Mtodos de Controle de Concorrncia
6.4.3 Mtodos baseados em Bloqueios
6.4.4 Mtodos de Pr-Ordenao
8. CONTROLE DE CONCORRNCIA
8.1 INTRODUO
8.1.1 Anomalias de Sincronizao
8.1.2 Modelagem do Sistema
8.1.3 Critrios de Correo
8.2* TEORIA DA SERIALIZAO
8.2.1 Execues Seriais
8.2.2 Equivalncia de Execues
8.2.3 Execues Serializveis
8.2.4 Uma Condio Suficiente para Serializao
8.3 MTODOS BASEADOS EM BLOQUEIOS - PARTE I
8.3.1 Protocolo de Bloqueio/Liberao de Objetos
8.3.2 Tratamento de Bloqueios Mtuos
8.3.2.1 Caracterizao de Bloqueios Mtuos
8.3.2.2 Deteo/Resoluo de Bloqueios Mtuos
8.3.2.3 Preveno de Bloqueios Mtuos
8.3.3 Protocolo de Bloqueio em Duas Fases
8.3.4* Correo do Protocolo de Bloqueio em Duas Fases
8.3.5 Uma Implementao Centralizada do Protocolo de Bloqueio em Duas Fases
8.4 MTODOS BASEADOS EM BLOQUEIOS - PARTE II
8.4.1 Implementao Bsica
8.4.2 Implementao por Cpias Primrias
8.4.3 Implementao por Bloqueio Centralizado
8.4.4 Tratamento de Bloqueios Mtuos no Caso Distribudo
8.5 MTODOS BASEADOS EM PR-ORDENAO
8.5.1 Protocolo de Pr-Ordenao
8.5.2 Implementao Bsica
8.5.3 Implementao Conservativa
8.5.4 Implementao Baseada em Verses Mltiplas
- 10 - 10
8.5 COMPARAO ENTRE OS MTODOS
8.6.1 Resumo das Caractersticas
8.6.2 Comentrios sobre a Escolha de um Mecanismo de Controle de Concorrn
9.2 IMAGENS TRANSIENTES
9.2.1 Implementao Bsica
9.2.1.1 Definio da Interface
9.2.1.2 Implementao da Interface
9.2.2 Proteo contra Falhas Primrias
9.2.2.1 Como Atingir Atomicidade
9.2.2.2 Estruturas de Dados da Implementao Modificada
9.2.2.3 Implementao das Operaes
9.2.3 Proteo contra Falhas Secundrias
9.2.4 Incorporao de Controle de Concorrncia
9.2.4.1 Discusso Preliminar
9.2.4.2 Implementao do Protocolo de Bloqueio em Duas Fases
Biografia dos Autores
MARCO ANTONIO CASANOVA professor do Departamento de Informtica da PUC-
Rio. Formou-se em Engenharia Eletrnica pelo Instituto Militar de Engenharia em 1974,
obteve o grau e Mestre em Cincias pela Pontifcia Universidade Catlica do Rio de Janeiro
em 1976, e os graus de Mestre em Cincias (1977) e Doutor em Filosofia (1979), ambos em
Matemtica Aplicada, pela Universidade de Harvard. Seus interesses acadmicos incluem
sistemas de gerencia de bancos de dados e sistemas de gerncia de documentos hipermdia.
ARNALDO VIERA MOURA professor do Instituto de Computao da UNICAMP.
Formou-se em Engenharia Eletrnica pelo Instituto Tecnolgico de Aeronutica em 1973,
obteve o grau de Mestre em Cincias em Matemtica Aplicada pelo mesmo Instituto em
1976, e o grau de Doutor em Filosofia, rea de Cincia da Computao, pela Universidade da
Califrnia, Berkeley, em 1980. Suas principais reas de interesse incluem linguagens formais,
complexidade de algoritmos e projeto e anlise de algoritmos concorrentes.
- 1 -
CAPTULO 1. CONCEITOS BSICOS
Este captulo apresenta os conceitos bsicos e discute as principais funes de um sistema de
gerncia de bancos de dados distribudos. Desenvolve ainda argumentos indicando quando
bancos de dados distribudos so uma alternativa interessante.
1.1 INTRODUO
1.1.1 O que um Sistema de Gerncia de Bancos de Dados Distribudos
Sistemas de gerncia de bancos de dados distribudos (SGBDDs) estendem as facilidades
usuais de gerncia de dados de tal forma que o armazenamento de um banco de dados possa
ser dividido ao longo dos ns de uma rede de comunicao de dados, sem que com isto os
usurios percam uma viso integrada do banco.
A criao de SGBDDs contribui de forma significativa para o aumento da produtividade em
desenvolvimento de aplicaes, um fator importante desde longa data. De fato, tais sistemas
simplificam a tarefa de se definir aplicaes que requerem o compartilhamento de informao
entre usurios, programas ou organizaes onde os usurios da informao, ou mesmo as
fontes de informao, esto geograficamente dispersas. Aplicaes com estas caractersticas
incluem, por exemplo, sistemas de controle de inventrio, contabilidade ou pessoal de
grandes empresas, sistemas de consulta a saldos bancrios, outros sistemas voltados para
clientes e bancos de dados censitrios.
A idia de SGBDDs atrativa sob muitos aspectos. Sob ponto de vista administrativo, tais
sistemas permitem que cada setor de uma organizao geograficamente dispersa mantenha
controle de seus prprios dados, mesmo oferecendo compartilhamento a nvel global no uso
destes dados. Do ponto de vista econmico, SGBDDs podem diminuir os custos de
comunicaes, que hoje em dia tendem a ser maiores do que o prprio custo de equipamento,
com o tradicional declnio dos custos de "hardware". Finalmente, SGBDDs tambm so
atrativos de um ponto de vista tcnico pois facilitam o crescimento modular do sistema (em
contraste principalmente com um sistema centralizado de grande porte), aumentam a
confiabilidade atravs da replicao das partes crticas do banco em mais de um n, e podem
aumentar a eficincia atravs de um critrio judicioso de particionamento e replicao que
coloque os dados prximos do local onde so mais freqentemente usados (em contraste com
acesso remoto a um banco de dados centralizado).
Por outro lado, no difcil argumentar que sistemas com esta arquitetura levantam
problemas de implementao srios, tm um custo de desenvolvimento elevado, consomem
recursos e podem ter uma performance duvidosa.
Em todo o livro usaremos as seguintes abreviaes:
BDD - banco de dados distribudo;
SGBD - sistema de gerncia de bancos de dados (centralizado ou distribudo);
SGBDD - sistema de gerncia de bancos de dados distribudos.
- 2 -
1.1.2 Por Que Bancos de Dados Distribudos?
A arquitetura de sistemas utilizando banco de dados tem sido tradicionalmente centralizada.
Ou seja, o banco de dados reside em um nico computador onde so executados todos os
programas acessando o banco. Os usurios podem, por sua vez, estar ligados diretamente, ou
atravs de uma rede, ao computador onde o banco reside. Sistemas com esta arquitetura
amadureceram durante a dcada de 70.
Usualmente, alinham-se a favor de sistemas centralizados argumentos que incluem fatores de
economia de escala - o custo por unidade de trabalho decresce medida que o tamanho do
processador cresce (Lei de Grosch) - facilidade de controle de segurana, integridade e
implantao de padres, alm de disponibilidade de dados para a gerncia.
Estes argumentos precisam ser reavaliados, no entanto. Em primeiro lugar, a centralizao
dos dados e de responsabilidades choca-se com o objetivo de tornar os dados mais facilmente
disponveis ao usurio final em aplicaes geograficamente dispersas. A relao entre os
custos de processamento e de comunicaes alteraram-se com a queda acentuada do custo de
processadores, mas no do custo de transmisso de dados. Ou seja, a estratgia de trazer os
dados a um processador central pode ser mais cara do que trazer capacidade computacional
ao local de gerao ou uso dos dados. Finalmente, sistemas centralizados apresentam
vulnerabilidade maior a falhas e nem sempre permitem um crescimento gradativo da
capacidade computacional instalada de forma simples e adequada.
Invertendo-se a discusso acima obtm-se argumentos a favor de bancos de dados
distribudos (BDDs).
Em detalhe, os argumentos que tornam BDDs atrativos podem ser postos da seguinte forma.
BDDs podem refletir a estrutura organizacional ou geogrfica do empreendimento dando
maior autonomia e responsabilidade local ao usurio, mas preservando uma viso unificada
dos dados. Do lado tecnolgico, o desenvolvimento de redes de comunicao de dados
permitiu a interligao de um grande nmero de processadores independentes de forma
confivel e com custo previsvel. Do ponto de vista puramente econmico, o
preo/performance de equipamentos de menor porte tem melhorado substancialmente,
obliterando o argumento a favor de equipamentos de grande porte. Alm disto, BDDs podem
diminuir os custos de comunicao se a maior parte dos acessos gerados em um n puderem
ser resolvidos localmente, sem acesso a dados armazenados em ns remotos. Finalmente,
BDDs podem ser projetados de tal forma a melhorar a disponibilidade e confiabilidade do
sistema atravs da replicao de dados, alm de permitirem um crescimento modular da
aplicao simplesmente acrescentando-se novos processadores e novos mdulos do banco ao
sistema.
Em contrapartida, o desenvolvimento de SGBDDs de uso genrico no um problema
simples. Em um SGBDD, o conhecimento do estado global do sistema necessrio para se
processar consultas e para controle de concorrncia, enquanto que no s os dados mas
tambm o controle e informao sobre o estado do sistema esto distribudos. Portanto,
SGBDDs diferem significantemente de SGBDs centralizados do ponto de vista tcnico, e um
SGBDD no pode ser entendido como a simples replicao de SGBDs centralizados em
vrios ns.
- 3 -
1.1.3 Arquitetura Genrica para SGBDs Distribudos
De um ponto de vista bem geral, um SGBD distribudo pode ser visto como uma federao
de SGBDs centralizados, autnomos, chamados de SGBDs locais, que so interligados por
uma camada de software chamada de SGBD da rede ou SGBD global ("network data base
management system").
Um SGBD local , para todos os efeitos, um SGBD centralizado gerenciando de forma
autnoma o banco de dados local, exceto que poder receber comandos tanto de usurios
locais quanto da cpia local do SGBD global. O SGBD local faz uso do sistema operacional
local que prov as seguintes facilidades bsicas: mtodos de acesso, gerncia de processos e
gerncia de memria.
A coletividade dos bancos locais constitui, ento, uma implementao do banco distribudo.
O SGBD global roda como uma aplicao sob o sistema operacional da rede de comunicao
de dados e, portanto, pertence camada de aplicao na nomenclatura do modelo de
referncia da ISO. Isto significa que todos os problemas de comunicao de dados e
distribuio de recursos transparente ao SGBD global.
1.1.4 Tipos de SGBDs Distribudos
SGBDs distribudos podem ser classificados em dois grandes grupos. Um SGBD distribudo
ser hamado de homogneo (em "software") se os SGBDs locais so semelhantes, caso
contrrio ser chamado de heterogneo. (Uma classificao semelhante pode ser feita do
ponto de vista de hardware", mas no importante no contexto deste livro). Mais
precisamente, um SGBD distribudo homogneo se todos os seus SGBDs locais:
oferecem interfaces idnticas ou, pelo menos, da mesma famlia;
fornecem os mesmos servios aos usurios em diferentes ns.
SGBDs distribudos homogneos aparecem com mais freqncia quando a aplicao a que se
destinam no existia antes. Conversamente, SGBDs distribudos heterogneos surgem
usualmente quando h necessidade de integrar sistemas j existentes. A escolha entre uma
arquitetura ou outra influenciada pelo aproveitamento de "hardware" e "software" j
existentes e pelo prprio hbito e grau de cooperao esperado dos usurios em caso de uma
mudana para um sistema diferente. A alternativa bvia seria adotar uma arquitetura hbrida.
1.1.5 Classes de Usurios de um SGBD Distribudo
Para apresentao de certas caractersticas de SGBDs distribudos, convm classificar os seus
usurios da seguinte forma. Por um lado, os usurios de um SGBD distribudo podem ser
grupados em:
usurios globais, que observam o banco de dados distribudo como um todo e acessam os
dados atravs das interfaces do SGBD global;
usurios locais que tm contato apenas com o banco de dados local ao n onde residem e
interagem apenas com o SGBD local.
- 4 -
Ortogonalmente, os usurios de um SGBD (centralizado ou distribudo) podem ser
classificados em quatro grandes grupos:
o administrador do banco, ("database administrator") responsvel pela definio e
manuteno do banco (que naturalmente pode ser uma equipe; por tradio mantivemos
aqui o singular);
analistas e programadores de aplicao, responsveis pelo desenvolvimento de aplicaes
sobre o banco de dados;
usurios casuais, como gerentes, que usualmente no so programadores treinados e
fazem uso do banco irregularmente;
usurios paramtricos, como caixas de banco, que fazem uso do banco de dados atravs
de transaes paramtricas pr-programadas.
1.2 REQUISITOS FUNCIONAIS DE UM SGBD DISTRIBUDO
Do ponto de vista do usurio, um SGBD uma ferramenta de "software" para
armazenamento e acesso aos dados operacionais de um empreendimento. Um SGBD
distribudo utilizado quando a forma mais adequada de armazenamento dos dados ao
longo dos ns de uma rede. Um SGBD distribudo dever facilitar a gerncia dos dados em
si, o desenvolvimento de aplicaes relativas ao empreendimento, alm de facilitar a
utilizao dos dados para fins de planejamento gerencial.
Nesta seo sero apresentadas as caractersticas funcionais de um SGBD distribudo
necessrias para alcanar estes objetivos gerais. Os requisitos funcionais aqui apresentados
tero grande influncia no desenrolar dos captulos seguintes, aplicando-se tanto a SGBDs
centralizados, quanto a SGBDs distribudos, exceto em certos casos. Muitos dos requisitos
selecionados, embora originalmente introduzidos para SGBDs seguindo o modelo relacional
de dados, refletem preocupaes mais gerais e independentes do modelo usado.
1.2.1 Independncia Fsica de Dados
A forma como o banco de dados est armazenado no deve ser visvel aos programadores e
analistas de aplicao, muito menos aos usurios casuais, sendo responsabilidade exclusiva
do administrador do banco defin-la. Em outros termos, os detalhes de armazenamento do
banco devem ser transparentes (ou mesmo irrelevantes) ao desenvolvimento de programas de
aplicao e ao uso casual do banco, j que a este nvel apenas a forma com que os dados esto
logicamente estruturados importa. Alm disto, espera-se que um bom sistema de gerncia de
banco de dados permita mudar a forma de armazenar o banco sem alterar os programas de
aplicao. Ou seja, deve ser possvel alcanar o que se convencionou chamar de
independncia fsica de dados.
1.2.2 Independncia de Localizao e Replicao
Em um SGBD distribudo, independncia fsica de dados adquire um significado especial.
Este requisito exige que o fato do banco ser distribudo seja um problema de implementao
e, portanto, transparente aos usurios (exceto, claro, na variao do tempo de acesso). Isto
significa que devem ser transparentes aos usurios tanto a localizao das vrias partes do
banco de dados ("location transparency"), quanto ao fato destas partes estarem replicadas ou
- 5 -
no ("replication transparency"). O sistema deve, ento, ser responsvel por localizar os
dados e atualizar todas as cpias. Alm disto, se os arquivos forem movidos de um n para
outro, ou divididos, os usurios no devem tomar conhecimento do fato (estas so formas de
reestruturar um banco de dados distribudo).
Em resumo, os usurios globais devero ver o banco de dados distribudo como se fosse
centralizado. Chamaremos estas caractersticas de independncia de localizao e
replicao.
1.2.3 Autonomia Local
Este requisito est intrinsecamente ligado estruturao de um SGBD distribudo em uma
federao de SGBDs locais autnomos interligados pelo SGBD global. Mais precisamente,
na arquitetura genrica adotada exige-se que cada SGBD local mantenha sua autonomia, no
seguinte sentido:
cada SGBD local deve manter controle sobre seus prprios dados, pois uma das
motivaes para banco de dados distribudos era justamente a distribuio da
responsabilidade dos dados para os prprios usurios locais;
programas que acessem dados locais devem ser executados localmente, sem que seja
necessrio consultar outros ns. No deve haver, portanto, um controle central do banco,
nem os dados necessrios ao funcionamento do sistema devem ser centralizados (como
em um diretrio nico centralizado).
Como consequncia deste requisito, um usurio local dever acessar os dados locais como se
constitussem um banco de dados centralizado independente.
1.2.4 Interfaces de Muito Alto Nvel
A linguagem para acesso aos dados armazenados no banco deve ser de muito alto nvel, ou
seja, com as seguintes caractersticas:
a linguagem deve ser no-procedimental no sentido do usurio especificar que dados
devem ser acessados e no como eles devem ser acessados (isto problema do sistema);
os comandos de acesso ao banco, oferecidos pela linguagem, devem manipular conjuntos
de objetos e no apenas um objeto de cada vez;
os comandos devem ser completamente independentes dos detalhes de armazenamento do
banco e da existncia de caminhos de acesso pr-definidos.
Estas caractersticas so evidentemente importantes para usurios casuais, com pouco
treinamento em processamento de dados. Mas h duas outras razes de peso para se exigir
interfaces de alto nvel. Primeiro, a produtividade de analistas e programadores de aplicao
aumentar, pois podero se concentrar primordialmente na aplicao em si e no na sua
implementao (a situao a mesma quando linguagens de programao de alto nvel
comearam a aparecer). Segundo, linguagens de muito alto nvel podem potencialmente
aumentar a eficincia do sistema, no seguinte sentido. Cada comando para acesso ao banco
exige a interveno do SGBD, o que gera um custo adicional considervel. Se o comando
manipula conjuntos de objetos de cada vez, este custo adicional , portanto, diludo em um
volume maior de trabalho til. Este argumento especialmente importante quando o
comando gera acessos a dados remotos exigindo o envio de mensagens atravs da rede.
- 6 -
1.2.5 Otimizao Automtica
O uso de interfaces de alto nvel perderia o impacto se o processamento de comandos para
acesso aos dados fosse ineficiente. O SGBD deve, portanto, conter um otimizador para
selecionar os caminhos de menor custo para acessar os dados.
A construo de otimizadores eficientes foi, de fato, um dos principais problemas enfrentados
no projeto de SGBDs recentes, especialmente aqueles seguindo o modelo relacional. As
solues apresentadas provaram, no entanto, serem bastante satisfatrias, viabilizando assim
o uso de interfaces de alto nvel.
1.2.6 Reestruturao Lgica do Banco e Suporte a Vises
Os requisitos de independncia fsica de dados e independncia de localizao e replicao
implicam em que a forma de armazenamento do banco pode ser modificada sem que seja
necessrio alterar os programas de aplicao. No entanto, reestruturaes deste tipo so
necessrias para otimizar a forma de armazenamento quando o perfil de utilizao do banco
muda.
Por outro lado, modificaes nas estruturas lgicas do banco (ou seja, na forma como os
usurios vem a estruturao dos dados) so necessrias quando a aplicao muda
conceitualmente. O SGBD deve, ento, fornecer meios para modificar a estrutura lgica de
um banco j existente e criar a nova verso dos dados a partir da antiga.
Reestruturaes deste tipo podem causar impacto nos programas de aplicao. Uma estratgia
para minorar o impacto de tais mudanas seria criar vises atravs das quais os programas de
aplicao acessam o banco. Assim, se a estrutura lgica do banco mudar, em certos casos
basta adaptar a definio das vises, sem que com isto os programas de aplicao recebam o
impacto das mudanas. interessante ento que o SGBD suporte o mecanismo de vises em
complemento a reestruturaes no banco (ver Captulo 2 tambm sobre os conceitos de
estruturas lgicas e vises).
1.2.7 Segurana dos Dados
Uma aplicao baseada em um banco de dados facilita enormemente o acesso aos dados
operacionais do empreendimento, o que traz o efeito adverso de facilitar acessos no
autorizados a dados classificados. O SGBD dever, necessariamente, prover meios para
definir critrios de autorizao para acesso aos dados e meios para assegurar que as regras de
acesso sero cumpridas.
1.2.8 Suporte Administrao dos Dados
Um banco de dados , em geral, uma estrutura complexa com centenas de tipos de objetos
diferentes, armazenados de diversas formas. A tarefa de administrar um banco, especialmente
se distribudo, exige ferramentas especiais para ser efetivamente executada. O SGBD deve,
ento, fornecer um dicionrio ou diretrio, onde armazenada a descrio do banco,
ferramentas para acesso a este dicionrio, alm de utilitrios para manuteno do banco.
- 7 -
Em especial, o acesso ao dicionrio no dever ser exclusividade do administrador do banco,
j que importante que os usurios casuais, programadores e analistas de aplicao
conheam a definio dos tipos de objetos armazenados no banco.
1.3 ESPECIFICAO DAS INTERFACES DE UM SGBD DISTRIBUDO
Nesta seo sero estudadas as caractersticas das interfaces oferecidas tanto a usurios locais
quanto a usurios globais, e os efeitos sobre as interfaces resultantes do SGBD distribudo ser
homogneo ou heterogneo.
1.3.1 Interfaces Globais e Locais
Conforme visto, um SGBD distribudo constitudo de uma coleo de SGBDs locais
interligados por um SGBD global. Em cada n, os usurios locais so servidos pelo SGBD
local implementado naquele n, e os usurios globais (residentes naquele n) so servidos
pela cpia local do SGBD global. H, portanto, duas classes de interfaces em um SGBD
distribudo:
as interfaces globais, oferecidas pelo SGBD global aos usurios globais;
as interfaces locais, oferecidas pelos SGBDs locais aos usurios locais.
Como conseqncia de dois dentre os requisitos bsicos que SGBDs distribudos devem
satisfazer, a especificao destas duas classes de interfaces se confunde, no entanto, com a
descrio das interfaces de um SGBD centralizado. De fato, lembremos que o requisito de
Independncia de Localizao e Replicao implica em que os usurios globais de um SGBD
distribudo devero ver o banco de dados distribudo como se fosse centralizado. Logo, o
SGBD global dever se comportar como um SGBD centralizado perante estes usurios. J o
requisito de Autonomia Local implica em que um usurio local dever acessar os dados
locais como se constitussem um banco de dados centralizado independente. Ou seja, o
SGBD local , para efeito dos usurios locais, um SGBD centralizado autnomo.
Assim, para especificar as caractersticas das interfaces oferecidas tanto a usurios locais
quanto a usurios globais, basta estudar os tipos de interfaces comumente oferecidas por
SGBDs centralizados. Este ser o assunto do pargrafo seguinte.
1.3.2 Especificao das Interfaces
Recordemos que os usurios locais ou globais podem ser classificados em quatro grandes
grupos: o administrador do banco, analistas e programadores de aplicao, usurios casuais, e
usurios paramtricos. Para satisfazer as necessidades destas classes de usurios,
tradicionalmente um SGBD centralizado oferece:
uma linguagem de definio de dados (LDD) usada para definir novos bancos de dados;
uma ou mais linguagens de manipulao de dados (LMDs) usadas para recuperar e
modificar os dados armazenados no banco;
opcionalmente, uma linguagem de gerao de relatrios (LGR) que, como o nome
indica, apropriada para extrair relatrios do banco de dados;
utilitrios para manuteno do banco.
- 8 -
A LDD conter comandos para definir as estruturas lgicas do banco e indicar como estas
devero ser armazenadas fisicamente. A LDD poder tambm conter outros tipos de
comandos como, por exemplo, comandos para definir critrios de autorizao de acesso aos
dados. A LDD e os utilitrios so as ferramentas de que dispe o administrador do banco para
executar as suas tarefas.
Uma LMD pode ser oferecida como uma linguagem independente para acesso ao banco
atravs de terminais, ou ser oferecida como uma extenso de uma linguagem de programao
j existente, chamada de linguagem hospedeira. A primeira verso apropriada formulao
de acessos no antecipados em geral, tpicos de usurios casuais. A segunda verso
utilizada no desenvolvimento de programas de aplicao que implementam transaes
repetitivas, definidas a priori (como desconto de cheques, transferncia de fundos, ou
consulta a saldo).
Uma LMD, tipicamente, conter comandos para recuperar, inserir, remover e atualizar dados
armazenados no banco. Outros comandos de controle tambm existiro indicando ao sistema
quando comea e termina uma transao, quando os dados de uma transao podem se tornar
visveis a outros usurios, etc... A LDD e as LMDs oferecidas por um SGBD so baseadas no
mesmo modelo de dados, que fixa os tipos de estruturas lgicas, como rvores, tabelas, etc...
que sero usados para organizar o banco de dados do ponto de vista conceitual.
Um usurio paramtrico no utiliza diretamente as interfaces do SGBD, mas sim transaes
paramtricas pertencentes a uma aplicao desenvolvida sobre o banco de dados. Uma
transao por sua vez definida por um programa de aplicao (um procedimento com
parmetros de entrada) escrito em uma determinada linguagem hospedeira e contendo
comandos da LMD. Em geral o termo "transao" tem o sentido mais preciso de uma coleo
de comandos que deve ser processada pelo SGBD como se fosse atmica, ou seja, o banco
deve refletir o resultado de todos os seus comandos ou de nenhum deles.
Isto conclui a discusso sobre as interfaces de um SGBD.
1.3.3 Influncia do Tipo de SGBD Distribudo sobre as Interfaces
Como em um SGBD distribudo homogneo todos os SGBDs locais oferecem interfaces
idnticas, estes ltimos usam, ento, o mesmo modelo de dados, a mesma LDD e as mesmas
LMDs. Logo, uma vez fixadas as interfaces locais, natural que o SGBD global tambm
oferea estas mesmas interfaces. Assim, qualquer usurio, local ou global, poder acessar
tanto dados locais quanto dados remotos atravs da mesma linguagem de manipulao de
dados.
Este no o caso, porm, para sistemas heterogneos pois SGBDs locais potencialmente
usam modelos de dados e LMDs diferentes. Uma opo seria o SGBD da rede oferecer ao
usurio global, residente em um dado n, uma viso do banco de dados distribudo no mesmo
modelo de dados que o banco local, e permitir que este usurio acesse dados definidos nesta
viso atravs da prpria LMD local. Esta opo interessante pois no necessrio ensinar
uma nova LMD aos usurios residentes em um determinado n para que possam acessar
dados remotos.
Nesta opo, o SGBD global possui, na verdade, uma interface diferente para cada n. Isto
no quer dizer que o SGBD global no suporte uma LMD independente das LMDs oferecidas
pelos SGBDs locais, chamada LMD pivot, quer seja pela existncia de uma nova classe de
usurios globais, quer seja para simplificar a estruturao do sistema.
- 9 -
1.4 PRINCIPAIS FUNES DE UM SGBD DISTRIBUDO
As principais funes de um SGBD (centralizado ou distribudo) podem ser grupadas em
sete grandes mdulos:
Armazenamento do Diretrio de Dados
Armazenamento do Banco de Dados
Processamento de Comandos da Linguagem de Manipulao de Dados
Gerncia de Transaes
Controle de Integridade
Controle de Concorrncia
Controle de Acesso ao Banco
Este agrupamento de funes corresponde diretamente organizao do livro, sendo cada
funo discutida em um captulo separado.
Nesta seo, cada uma destas funes ser brevemente abordada, criando-se assim um guia
para leitura dos outros captulos. Como a discusso bastante genrica, aplica-se tanto a
SGBDs centralizados quanto distribudos, exceto em certos casos. Antes, porm, um
refinamento da arquitetura de SGBDs distribudos descrita na Seo 1.1.3, ser apresentado,
bem como um esquema simplificado do ciclo de acesso a um banco de dados distribudo.
1.4.1 Refinamento da Arquitetura de um SGBD Distribudo
De acordo com a arquitetura genrica adotada, um SGBD distribudo consiste de uma coleo
de SGBDs locais interligados pelo SGBD global. O SGBD global pode, por sua vez, ser
refinado em trs grandes componentes:
1. diretrio de dados global (DDG): contm a descrio do banco de dados distribudo. O
critrio usado para sua distribuio/duplicao crucial para a performance do sistema;
2. gerente de transaes (GT): interpreta e controla o processamento de consultas e
transaes acessando o BDD;
3. gerente de dados (GD): interface com o SGBD local, fazendo as tradues necessrias no
caso de sistemas heterogneos.
Cada SGBD local possui tambm um diretrio de dados local descrevendo o banco de dados
local.
Cada n da rede conter ento um SGBD local e uma cpia do SGBD global, caso armazene
parte do banco, ou apenas o gerente de transaes, caso no armazene parte do banco. Um n
poder conter ou no parte do diretrio global, j que a estratgia de alocao deste ltimo
no fixada "a priori" neste nosso cenrio.
- 10 -
Figura 1.1 - Ciclo de um Comando Distribudo
1.4.2 Ciclo de Processamento em um SGBD Distribudo
Um ciclo tpico de acesso ao banco de dados distribudo na arquitetura descrita na seo
anterior seria (ver Figura 1.1):
1. uma transao T operando no n i (ou usurio acessando o banco atravs do n i) executa
um comando para acessar o banco;
2. o gerente de transaes do n i intercepta o comando, acessa o diretrio global (que pode
estar em outro n) e cria um plano de acesso ao BDD para obter os dados necessrios, ou
seja, cria uma seqncia de comandos a serem enviados aos outros ns e para o prprio
banco local;
3. gerente de transaes do n i envia comandos aos ns envolvidos e coordena a sua
execuo;
4. o gerente de dados de um n j envolvido no processamento recebe comandos para o
banco local e se encarrega de chamar o SGBD local para execut-los (se for necessrio, o
gerente de dados traduz os comandos para a linguagem de manipulao de dados local);
5. gerente de dados do n j devolve os dados pedidos ao gerente de transaes do n i;
6. o gerente de transaes do n i completa o processamento do comando submetido,
passando os dados para a transao (ou para o usurio).
O acesso ao banco de dados local seguiria o seguinte ciclo esquematizado:
1. uma transao local executa um comando para acessar o banco local, ou o gerente de
dados repassa um comando remoto ao SGBD local;
2. SGBD local, por intermdio do sistema operacional, acessa o diretrio de dados local;
3. SGBD local analisa o comando;
4. SGBD local chama o sistema operacional para transferir dados do banco de dados local
para memria principal;
5. SGBD local extrai dos dados transferidos aqueles necessrios para responder ao
comando.
GTi GDj
SGBDLj
BDL
Rede GDi
SGBDLi
DD
T
BDL
- 11 -
O resto desta seo discute quais so as principais funes de um SGBD distribudo e como
elas so implementadas.
1.4.3 Armazenamento do Diretrio de Dados
O diretrio de dados, na sua forma mais simples, contm toda informao sobre o sistema e
sobre os bancos de dados e transaes j definidos. Esta informao armazenada sob forma
interna para ser usada pelos outros componentes do SGBD e, naturalmente, fundamental
para o funcionamento do sistema.
Este papel bsico do diretrio pode ser expandido com outras facilidades para que se torne a
principal ferramenta de administrao do banco e a principal fonte de informao sobre o
significado dos dados para os usurios.
Em um SGBD distribudo haver um diretrio de dados global, que descreve o banco de
dados distribudo e usado pelas cpias do SGBD global, e um diretrio local para cada
SGBD local, descrevendo o banco local. Independentemente do fato de ser global ou local, as
seguintes observaes podem ser feitas acerca do diretrio.
A linguagem de definio de dados (LDD) implementada pelo SGBD constitui-se na
principal interface com o dicionrio de dados, no seguinte sentido. O diretrio contm,
inicialmente, apenas informao sobre as suas prprias estruturas e outras transaes e
usurios especiais. A descrio de novos bancos de dados ento acrescentada ao diretrio
como resultado do processamento de comandos da LDD; novos usurios so catalogados
atravs de comandos de autorizao da LDD; e novas transaes so acrescentadas tambm
atravs de comandos especiais de catalogao.
H duas formas de implementar o diretrio. A rigor, o diretrio nada mais do que um banco
de dados e um conjunto de transaes e, portanto, pode ser implementado como um banco de
dados usando os mesmos mecanismos que os bancos comuns. Ganha-se com isto em
uniformidade de interfaces e em compartilhamento de cdigo, j que a prpria linguagem de
manipulao de dados do SGBD pode ser utilizada para manter o diretrio. Por outro lado,
perde-se em performance.
De fato, o diretrio, embora sendo um banco de dados, acessado com extrema freqncia.
Portanto merece tcnicas de armazenamento e acesso especiais. Com isto ganha-se em
performance, mas perde-se em complexidade. Estas ltimas observaes so especialmente
importantes no que se refere ao diretrio global. Como qualquer outro banco, ele poder ser
distribudo com replicao ou particionamento. No entanto, como acessos ao diretrio so
necessrios a cada consulta, a sua implementao deve ser cuidadosa para minimizar o
trfego adicional de mensagens gerado para acess-lo.
1.4.4 Armazenamento do Banco de Dados
A funo de armazenamento do banco de dados se refere s estruturas de arquivo, mtodos de
acesso, tcnicas de compresso, etc., oferecidas como opes para organizao fsica dos
dados em memria secundria. Esta uma funo dos SGBDs locais j que, uma vez
definidos os critrios de distribuio do banco, o problema de armazenamento fsico
puramente local.
- 12 -
As opes de armazenamento oferecidas pelo SGBD tornam-se aparentes sob forma de
comandos especiais da LDD usados para descrio da organizao fsica do banco de dados.
Esta parte da linguagem , s vezes, denominada de linguagem de definio interna de dados.
A implementao do subsistema de armazenamento interage fortemente com o subsistema
responsvel pelo processamento de comandos, considerando-se que o problema bsico de um
SGBD local consiste em receber um comando do usurio (local ou remoto) e traduz-lo em
acessos fsicos a registros armazenados em mmoria secundria. Este problema exacerbado
quando a linguagem de manipulao de dados usada de muito alto nvel, conforme um dos
requisitos funcionais impostos a SGBDs distribudos.
Neste contexto, a arquitetura do subsistema de armazenamento pode ser dividida em dois
nveis. O nvel mais baixo, que chamaremos de nvel fsico, consiste de uma coleo de
mtodos de acesso primrios cujas principais funes so:
esconder dos subsistemas superiores todos os detalhes de armazenamento referentes aos
perifricos;
oferecer alternativas bsicas para armazenamento e recuperao de registros fsicos,
atravs da definio de estruturas de dados e algoritmos para manipulao destas
estruturas.
Este primeiro nvel, na verdade, no costuma ser parte do SGDB. Ou seja, o SGBD aproveita
os prprios mtodos de acesso primrios do sistema operacional subjacente, talvez
complementando-os com outros mais sofisticados.
O segundo nvel do subsistema de armazenamento, que chamaremos de nvel interno ou
lgico, pode ser encarado como um SGBD independente, definido com os seguintes
objetivos:
oferecer aos subsistemas superiores uma interface melhor do que simplesmente chamadas
para as rotinas dos mtodos de acesso, mas bem mais simples do que a LMD do sistema
completo;
implementar a base de outras funes do sistema como, por exemplo, controle de
integridade.
Este segundo nvel oferece ento um passo intermedirio entre os comandos da LMD do
sistema e as rotinas dos mtodos de acesso.
1.4.5 Processamento de Comandos da Linguagem de Manipulao de Dados
Por processamento de comandos da linguagem de manipulao de dados (LMD)
entenderemos o problema de processar comandos tanto para recuperao de dados quanto
para atualizao do banco, formulados por um usurio de forma interativa, ou resultantes da
execuo de transaes. Mas excluiremos o problema de implementar o conceito de transao
como coleo atmica de comandos, que discutido na seo seguinte.
Independentemente do sistema ser centralizado ou distribudo, o processamento de comandos
poder ser feito de forma interpretativa, ou atravs de compilao. A estratgia de
compilao provou ser bastante mais eficiente, mas cria certas dificuldades adicionais. De
fato, considere o seguinte cenrio: um comando compilado, assumindo uma dada
organizao fsica do banco, e o cdigo objeto armazenado para posterior execuo; o banco
de dados tem sua organizao alterada; o cdigo objeto executado, resultando em erro (pois
a organizao do banco mudou). Para evitar este problema e manter a capacidade de
- 13 -
reestruturar dinamicamente o banco necessrio, ento, um mecanismo de validao em
tempo de execuo que recompile automaticamente o comando caso necessrio. Note que,
em uma estratgia interpretativa, este problema no ocorre.
Em um SGBD distribudo, o processamento de comandos subdividido nas seguintes fases:
1. anlise sinttica: inclui a traduo dos nomes das estruturas do banco de dados para uma
forma interna com auxlio do diretrio de dados;
2. otimizao: seleciona um plano de execuo para o comando;
3. distribuio do plano de execuo;
4. execuo dos subcomandos pelos SGBDs locais e criao do resultado final.
H trs tarefas particularmente difceis. A primeira, otimizao, requer escolher que cpias
dos dados devero ser usadas, fragmentar o comando original em subcomandos e definir a
estratgia de movimentao dos resultados parciais (um extremo seria, por exemplo, mover o
resultado de todos os subcomandos para um dado n, que no precisa ser o n em que o
usurio est, e a resolver a consulta).
A segunda tarefa, execuo dos subcomandos por cada SGBD local, coincide com o
problema de processar comandos em um SGBD centralizado. Como esta uma tarefa
complexa, o subsistema correspondente costuma ser estruturado em vrias camadas, ou
mquinas virtuais, cada uma implementando uma interface que se assemelha a uma LMD de
mais alto nvel que a anterior. Conjugando-se esta arquitetura com a discusso sobre
armazenamento de bancos, a mquina mais interna corresponderia ento ao nvel fsico do
subsistema de armazenamento, a mquina imediatamente superior corresponderia ao nvel
interno do subsistema de armazenamento, e assim por diante at a ltima mquina, que
ofereceria como interface a prpria LMD do sistema.
A terceira tarefa que merece comentrios nesta fase introdutria surge quando o SGBD
distribudo heterogneo e, em cada n, o SGBD global oferece a prpria LMD local como
interface. Isto significa que comandos para acessar o banco de dados distribudo podero ser
formulados em vrias LMDs diferentes. Cada um destes comandos dever, ento, ser
fragmentado em subcomandos que sero, por sua vez, traduzidos para a LMD do SGBD local
em que sero processados.
Esta tarefa de traduo funo do gerente de dados local. Supondo-se que o banco esteja
armazenado em n ns, sero necessrios n(n-1) tradutores, j que dever haver um tradutor
para cada par de LMDs locais diferentes.
Esta situao pode ser melhorada instituindo-se um modelo de dados e uma LMD pivots,
intermedirios e invisveis, em princpio, aos usurios. Um comando formulado contra o
banco distribudo seria ento traduzido para a LMD pivot e fragmentado em subcomandos
ainda na LMD pivot. Assim, seria necessrio a construo de apenas n tradutores.
Finalmente, note que quando atualizaes esto envolvidas, o problema recai na traduo de
atualizaes em vises, que extremamente difcil.
- 14 -
1.4.6 Gerncia de Transaes
As funes de gerncia de transaes so:
implementar o conceito de transao;
gerenciar as atividades e recursos do sistema;
monitorizar o incio e trmino das atividades do sistema.
Destas atividades, a mais importante a implementao do conceito de atomicidade. Esta
propriedade caracterizada por uma seqncia de comandos bem delimitada de tal sorte que
o sistema deve garantir que, ou todos os comandos na seqncia sejam completamente
executados, ou o banco no reflete o resultado da execuo de nenhum deles, mesmo que o
sistema falhe antes da completa execuo de todos os comandos da seqncia. O gerente de
transaes, portanto, transforma o produto final do processador de consultas em uma unidade
atmica de trabalho, implementando os comandos de iniciar, migrar, terminar, cancelar, e
reiniciar transaes.
Em um SGBD distribudo, a implementao destes comandos consideravelmente mais
difcil pois uma transao pode modificar dados armazenados em mais de um n, o que
significa que vrios ns tm que cooperar no processo. Por outro lado, por requisitos de
projeto, toda informao e mesmo o prprio controle do processo no devem estar
centralizados em um nico n.
Com relao aos outros componentes do SGBD, o gerente de transaes usa os subsistemas
de controle de concorrncia e de controle de integridade para executar as suas tarefas.
1.4.7 Controle de Concorrncia
Controle de concorrncia visa a garantir que, em toda execuo simultnea de um grupo de
transaes, cada uma seja executada como se fosse a nica do sistema. Isto significa que, em
uma execuo concorrente, transaes no devem gerar interferncias que levem a anomalias
de sincronizao. As anomalias mais comumente encontradas so perda de atualizaes,
perda de consistncia do banco e acesso a dados inconsistentes.
Mais precisamente, uma tcnica de controle de concorrncia deve garantir que toda execuo
concorrente de um conjunto de transaes seja serializvel, ou seja, equivalente a alguma
execuo das transaes em que cada transao completamente processada antes da
prxima comear (i.e., a execuo serial).
H trs classes bsicas de tcnicas de controle de concorrncia: tcnicas de bloqueio, pr-
ordenao ou mistas. As tcnicas de bloqueio exigem que um dado seja bloqueado pela
transao antes de ser lido ou modificado (embora isto no seja suficiente, conforme
veremos). Estas tcnicas em geral criam problemas de bloqueio mtuo ("deadlock") que so
especialmente difceis de resolver em um ambiente distribudo.
Nas tcnicas de pr-ordenao, a ordem das transaes escolhida "a priori" e as transaes
so executadas concorrentemente como se fossem processadas serialmente na ordem
escolhida. Em geral estas tcnicas evitam problemas de bloqueio mtuo, mas criam
problemas de reincio cclico de transaes e postergao indefinida de transaes ("cyclic
restart" e "indefinite postponement").
- 15 -
As tcnicas mistas, como o nome indica, tentam combinar as vantagens de bloqueio e pr-
ordenao.
1.4.8 Controle de Integridade
Controle de integridade enderea os seguintes problemas:
implementar o cancelamento, recuperao e trmino de transaes;
trazer o banco de dados, em caso de falhas, a um estado consistente que reflita apenas o
efeito de todas as transaes j concludas;
recuperar regies danificadas do banco de dados.
As funes de controle de integridade esto implementadas tanto como parte do SGBD
global, quanto como parte dos SGBDs locais. Por exemplo, a recuperao de regies do
banco danificadas por falhas nos perifricos uma funo do SGBD local. J as funes
relacionadas a transaes e a manter a consistncia do banco uma funo do SGBD global,
pois envolve o banco de dados distribudo como um todo.
Os tipos de falhas podem ser classificados em: falhas (de "hardware" ou "software") no
processador local, falhas nos perifricos que armazenam o banco e falhas na rede de
comunicao de dados.
No inclui a manuteno automtica dos critrios de consistncia lgica do banco que
porventura tenham sido definidos para o banco (critrios tais como "todo salrio deve ser
maior do que o mnimo").
1.4.9 Controle de Acesso ao Banco
O objetivo da funo de controle de acesso implementar mecanismos que garantam a
segurana dos dados armazenados no banco, permitindo que informao seja lida ou
modificada apenas por usurios autorizados.
O controle de acesso pode usar um mecanismo de definio de vises, restringindo a que
partes do banco de dados cada grupo de usurios pode ter acesso. Um usurio, ou transao,
acessaria o banco de dados atravs da sua viso. O sistema seria, ento, encarregado de
traduzir acessos viso em acessos aos objetos realmente armazenados pelo banco.
Independentemente do mecanismo de vises, o sistema deve oferecer um mecanismo de
autorizao de privilgios. Como parte da LDD, existiriam comandos de autorizao
indicando para cada usurio que privilgios (leitura, modificao, insero, etc.) possui e
como estes privilgios se relacionam com as estruturas lgicas do banco. Ao entrar no
sistema (ou comear a executar, no caso de transaes), haveria um mecanismo de
autenticao do usurio (ou transao) estabelecendo a sua identidade perante o sistema.
Finalmente, a cada acesso ao banco (ou outra unidade de trabalho mais conveniente,
principalmente no caso de transaes), o sistema verificaria se o usurio possui os privilgios
necessrios execuo do acesso.
- 16 -
NOTAS BIBLIOGRFICAS
O relatrio do CODASYL Systems Commitee [1982] contm uma anlise detalhada das
vantagens e desvantagens de BDDs. Gray [1979] tambm discute BDDs de um ponto de vista
bem geral. Rothnie e Goodman [1977] contm uma das primeiras discusses genricas sobre
SGBDDs. Mohan [1980] discute brevemente vrios problemas levantados pelo projeto de
SGBDDs. Draffan e Poole (eds.) [1980] forma uma boa coletnea de artigos. Procuram cobrir
todos os aspectos relativos a banco de dados distribudos, desde a fase de projeto lgico at
os mecanismos mais internos de controle de integridade. A nica desvantagem ter sido
escrito por um grupo de pessoas, com notao e modelos algo desencontrados. Date [1983]
contm tambm um captulo especfico sobre SGBDDs e discute vrios dos problemas
abordados neste livro, porm com bem menos detalhes. Draffan e Poole (eds.) [1980]
discutem os problemas de sistemas homogneos e heterogneos, sendo estes ltimos
analisados em detalhe em Spaccapietra [1980]. Lindsay e Selinger [1980] introduzem o
conceito de autonomia local. Vrios prottipos de SGBDDs esto operacionais hoje em dia.
Rothnie e Goodman [1977] e Rothnie et all. [1980] descrevem a arquitetura do SDD-1,
desenvolvido na "Computer Corporation of America", que muito influenciou a discusso
deste captulo. Williams et all. [1981] do uma viso geral do Sistema R*, desenvolvido no
Laboratrio de Pesquisas da IBM em San Jose, California, como continuao do projeto do
Sistema R (veja Astrahan et all. [1976] e Blasgen et all. [1979] para uma descrio do
Sistema R). Stonebraker e Neuhold [1977] esboam o que viria a ser o INGRES distribudo.
Adiba et all. [1980] descrevem o sistema POLIPHEME e Neuhold e Walter [1982] o sistema
POREL, ambos europeus. Smith et all. [1981] descrevem um sistema heterogneo chamado
MULTIBASE, tambm desenvolvido pela "Computer Corporation of America".
- 1 -
CAPTULO 2. BANCOS DE DADOS DISTRIBUDOS
Este captulo inicia com uma proposta para estruturao da descrio de bancos de dados
distribudos, que estende aquela sugerida pela ANSI/SPARC os centralizados. Em seguida, os
problemas de projeto e administrao de um banco de dados distribudo so discutidos.
2.1 ESPECIFICAO DE BANCOS DE DADOS DISTRIBUDOS
A forma usual adotada para descrio de bancos de dados centralizados inicialmente
apresentada e, em seguida, estendida para bancos distribudos. Um pequeno exemplo da
descrio de um banco de dados distribudo completa a seo.
2.1.1 Descrio de Bancos de Dados Centralizados
A descrio de um banco de dados centralizado usualmente est dividida em trs nveis:
conceitual ou lgico, interno ou fsico e externo (vide Figura 2.1).
A descrio a nvel lgico forma o esquema conceitual do banco de dados. O esquema
conceitual deve apresentar uma viso de alto nvel do banco, independente da forma de
armazenamento refletindo apenas a semntica do empreendimento que est sendo modelado.
O esquema conceitual consiste de um conjunto de estruturas de dados descrevendo como os
dados esto organizados do ponto de vista lgico, alm de um conjunto de restries de
integridade indicando que conjuntos de dados corretamente refletem situaes do mundo real.
A classe de estruturas de dados e restries de integridade permitidas so determinadas pelo
modelo de dados escolhido.
Ao nvel interno ou fsico, obtm-se uma representao eficiente do esquema conceitual em
termos dos mtodos de acesso e estruturas de arquivos oferecidas pelo sistema de gerncia de
banco de dados. O resultado chamado de esquema interno do banco. A existncia de um
esquema interno separado do esquema conceitual bastante importante pois os detalhes de
armazenamento do banco devem ser transparentes (ou mesmo irrelevantes) ao
desenvolvimento de programas de aplicao. O esquema interno no deve ser visvel aos
usurios ou analistas de aplicao, sendo responsabilidade do administrador do banco defin-
lo. Alm disto, espera-se de um bom sistema de gerncia de banco de dados que permita
mudar o esquema interno do banco sem alterar os programas de aplicao. Ou seja, o SGBD
deve permitir alcanar o que chamamos de independncia fsica de dados.
Finalmente, pode-se criar uma viso especializada do banco para cada grupo de usurios,
ainda do ponto de vista lgico, atravs da definio de um esquema externo para cada grupo.
Esquemas externos facilitam o desenvolvimento de aplicaes j que focalizam apenas a
parte do banco que interessa aplicao, escondendo parte da complexidade do banco.
Esquemas externos tambm so teis como uma forma de restringir o acesso a dados
classificados por parte de grupos de usurios.
- 2 -
Figura 2.1 - Um Banco de Dados Centralizado
2.1.2 Descrio de Bancos de Dados Distribudos
A descrio de um banco de dados distribudo, refletindo os requisitos de que a localizao e
replicao dos dados deve ser transparente aos usurios do BDD e de que o sistemas locais
devem manter sua autonomia, apresentada a seguir (vide Figura 2.2).
O requisito postulando que a distribuio do BDD deve ser transparente ao usurio pode ser
entendido como indicando que, a nvel lgico, um BDD deve ser visto como se fosse um
banco de dados centralizado. Desta forma, deve existir
um esquema conceitual global descrevendo o BDD a nvel lgico e ignorando o fato
deste ser distribudo e
vrios esquemas externos globais descrevendo vises do BDD para grupos de usurios.
Estes dois primeiros nveis so, portanto, idnticos para bancos de dados centralizados e
distribudos.
O esquema conceitual global no mapeado diretamente em esquemas internos nos diversos
ns onde residir o banco. Esta alternativa aglutinaria em um nico passo os problemas de se
definir tanto o critrio de distribuio do banco como tambm a estratgia de armazenamento
do banco em cada n. Para evitar este inconveniente, introduz-se para cada n onde uma
parte do banco estar armazenada um esquema conceitual local descrevendo o banco de
dados local. O mapeamento do esquema conceitual global para os vrios esquemas
conceituais locais define, ento, o critrio de distribuio usado.
A estratgia de armazenamento de cada banco de dados local definida mapeando-se o
esquema conceitual local que o define em um esquema interno local. Cada n possui,
portando, uma descrio completa, a nvel lgico e fsico, do banco ali armazenado.
Esquema
Conceitual
Esquema
Interno
Esquema
Externo
Esquema
Externo
- 3 -
Figura 2.2 - Um Banco de Dados Distribudo
O conceito de um banco de dados local mais facilmente justificado frente ao requisito
indicando que sistemas locais devem manter sua autonomia. Assim, faz sentido introduzir
tambm esquemas externos locais em cada n descrevendo vises do banco de dados local
para cada grupo de usurios locais (ver Figura 2.3).
A descrio de um banco de dados distribudo afetada pelo tipo de sistema da seguinte
forma. Se o SGBD for homogneo, todos os esquemas a nvel lgico utilizaro o mesmo
modelo de dados. J no caso de sistemas heterogneos, teremos a seguinte situao:
esquema conceitual global no modelo de dados pivot;
esquemas externos globais podem ser tanto no modelo de dados pivot, para usurios globais,
ou em um modelo de dados local, no caso de se desejar oferecer a
um usurio local uma viso do BDD no modelo que ele est
acostumado;
esquemas conceituais locais no modelo de dados local;
esquemas externos locais no modelo de dados local.
Esquema
Conceitual
Global
Esquema
Externo
Global
Esquema
Externo
Global
Esquema
Conceitual
Local
Esquema
Conceitual
Local
Esquema
Interno
Local
Esquema
Interno
Local
- 4 -
Figura 2.3 - Um Banco de Dados Local
2.1.3 Um Exemplo da Descrio de Bancos de Dados Distribudos
O banco de dados usado como exemplo refere-se a fornecedores, com nmero, nome e
cidade-sede; peas, com cdigo e nome; e fornecimentos relacionando um fornecedor a cada
pea que fornece e indicando a quantidade fornecida. Assumindo que o banco descrito no
modelo relacional, o esquema conceitual seria:
Esquema Conceitual Global
FORNECEDORES [ NUMERO,NOME,SEDE ]
PECAS [ CODIGO,NOME,COR,PESO ]
FORNECIMENTO [ NUMERO,CODIGO,QUANTIDADE ]
Poderamos definir dois esquemas externos globais da seguinte forma:
Esquema Externo Global A:
Esquema de relao:
FORN_PECA [ NUMERO,CODIGO,NOME ]
Definio:
FORN_PECA = (FORNECIMENTO * PECAS) [ NUMERO,CODIGO,NOME ]
Esquema
Conceitual
Local
Esquema
Externo
Local
Esquema
Externo
Local
Esquema
Interno
Local
- 5 -
Esquema Externo Global B:
Esquema de relao:
FORN_PECA [ NUMERO,CODIGO ]
Definio:
FORN_PECA = FORNECIMENTO [ NUMERO,CODIGO ]
Nota: lgebra relacional ser usada para indicar mapeamentos neste exemplo; a operao de
juno natural ser indicada pelo smbolo '*' e as operaes de projeo e seleo sero
denotadas da forma usual, ou seja, R[X] indicar a projeo de R na lista de atributos X e R[B],
onde B uma qualificao, indicar uma seleo das tuplas de R que satisfazem B.
Assumindo que o sistema homogneo e distribudo em apenas dois ns, os esquemas
conceituais locais e a distribuio do esquema conceitual global seriam ento descritos da
forma abaixo (o primeiro n conter todos os fornecedores com sede em Passa Trs, todos os
fornecimentos em que esto envolvidos e o nome e cdigo das peas; o segundo n conter o
resto dos fornecedores e seus fornecimentos, alm do cdigo, cor e peso das peas.
Esquemas Conceituais Locais:
Primeiro N:
FORNECEDORES1 [ NUMERO,NOME,SEDE ]
PECAS1 [ CODIGO,NOME ]
FORNECIMENTO1 [ NUMERO,CODIGO,QUANTIDADE ]
Segundo N:
FORNECEDORES2 [ NUMERO,NOME,SEDE ]
PECAS2 [ CODIGO,COR,PESO ]
FORNECIMENTO2 [ NUMERO,CODIGO,QUANTIDADE ]
Mapeamentos Definindo o Critrio de Distribuio:
Primeiro N:
FORNECEDORES1 = FORNECEDORES [ SEDE='PASSA TRES' ]
PECAS1 = PECAS [ CODIGO,NOME ]
FORNECIMENTO1 = FORNECIMENTO * (FORNECEDORES1 [ NUMERO]
Segundo N:
FORNECEDORES2 = FORNECEDORES [ SEDE 'PASSA TRES' ]
FORNECIMENTO2 = FORNECIMENTO * (FORNECEDORES2 [ NUMERO]
PECAS2 = PECAS [ CODIGO,COR,PESO ]
Como os esquemas internos locais dependem do SGBD local em questo, no faz sentido
apresent-los aqui. Esquemas externos locais tambm so omitidos.
- 6 -
2.2 PROJETO DE BANCOS DE DADOS DISTRIBUDOS
A breve discusso sobre o projeto de bancos de dados distribudos apresentada nesta seo
baseia-se em certas observaes simples. Em primeiro lugar, o projeto do esquema conceitual
global e o dos esquemas externos globais inteiramente semelhante ao caso centralizado, j
que o banco de dados distribudo dever se comportar como centralizado perante os usurios
globais. Alm disto, o projeto dos esquemas internos locais tambm idntico ao de bancos
centralizados, exceto que a carga imposta por acessos remotos aos dados locais tambm deve
ser levada em considerao. Portanto, o problema bsico de projeto de bancos de dados
distribudos reside no projeto dos esquemas conceituais locais, pois estes refletem a
estratgia de distribuio do banco.
As estratgias de distribuio so classificadas em particionamento e replicao. Seja D uma
estrutura (lgica) de dados do esquema conceitual global. Dizemos que D particionada
verticalmente (ou estruturalmente) quando D mapeada em duas ou mais estruturas (lgicas)
de dados que no so idnticas a D e que pertencem a diferentes esquemas conceituais locais.
Dizemos que D particionada horizontalmente (ou particionada por ocorrncia) quando D
mapeada em estruturas idnticas a D e pertencentes a dois ou mais esquemas conceituais
locais de tal forma que o mapeamento define um particionamento (no sentido matemtico) do
conjunto de dados associado a D.
No exemplo da seo anterior, FORNECEDORES foi particionada horizontalmente em
FORNECEDORES1 e FORNECEDORES2, o mesmo acontecendo com FORNECIMENTO. J PECAS
foi particionada verticalmente em PECAS1 e PECAS2.
Dizemos que D replicada quando D mapeada em duas ou mais estruturas (lgicas) de
dados idnticas a D e pertencentes a diferentes esquemas conceituais locais de tal forma que
o apeamento de D em cada uma destas estruturas sempre a identidade. Ou seja, existiro
cpias idnticas do conjunto de dados associado a D armazenadas em dois ou mais ns. A
replicao total quando cada banco de dados local contm uma cpia completa do banco.
Caso contrrio a replicao parcial.
A escolha da estratgia de distribuio do banco exige cuidados especiais pois se vier a gerar
um trfego de dados exagerado entre os vrios ns, o custo de comunicao tornar o projeto
anti-econmico.
Inicialmente, deve-se verificar se a soluo distribuda de fato uma opo vivel. Isto
significa, essencialmente, detetar se o banco fortemente integrado, ou se pode ser dividido
em partes mais ou menos independentes; se este for o caso, deve-se ento determinar qual a
vantagem de descentralizar o banco. Um estudo do perfil da populao de transaes
existentes no sistema centralizado em uso (se este for o caso) dever ser feito, tentando
determinar se possvel dividir o sistema - banco de dados e transaes - em subsistemas
mais ou menos independentes. Se este for o caso, o custo de transmisso de dados dever ser
reduzido, descentralizando-se o banco e suas funes. Acessos que cortem fronteiras
geogrficas ainda sero suportados, desde que no sejam muito freqentes.
Uma vez identificado que a soluo distribuda vivel, deve-se escolher a tcnica de
distribuio, levando-se em conta os seguintes fatores:
um BDD particionado no fica limitado memria secundria disponvel localmente e,
comparativamente a uma soluo centralizada (com acesso distribudo), aumenta a
confiabilidade e eficincia do sistema, se h um alto grau de localidade de referncia;
- 7 -
um BDD replicado aumenta a confiabilidade, disponibilidade e pode aumentar a rapidez
do sistema, mas por outro lado cria problemas de propagao de atualizaes nos dados e
exige mais memria secundria local.
Naturalmente, o grau de replicao do BDD traduz um compromisso entre o custo de acesso
a dados remotos e o custo de atualizar cpias mltiplas.
Um resumo desta discusso encontra-se na tabela abaixo:
RESUMO DAS ESTRATGIAS DE DISTRIBUIO
% de Excees Tamanho do Arquivo Mtodo de Distribuio
--
pequena
alta
pequeno
grande
grande
replicao
particionamento
centralizado
Nota: percentagem de excees refere-se freqncia com que uma transao necessita de
dados que no esto armazenados localmente.
Por fim, consideraes envolvendo "hardware" devem ser mencionadas com relao ao
projeto de BDDs. A anlise do equipamento necessrio dever responder, pelo menos, s
seguintes perguntas: Que processadores existem na organizao (ou precisam ser
adquiridos)? Qual a configurao mnima dos processadores para suportar o SGBDD? Que
perifricos so necessrios? Que equipamentos de comunicao de dados so necessrio para
interligar os processadores?
Isto encerra a nossa breve discusso sobre projeto de BDDs.
2.3 ADMINISTRAO DE BANCOS DE DADOS DISTRIBUDOS
Nesta seo so abordados os problemas, as tarefas e a organizao da equipe de
administrao de um banco de dadosdistribudo.
2.3.1 Organizao e Tarefas da Equipe de Administrao
A organizao da equipe de administrao, no caso distribudo, deve acompanhar a prpria
estratgia de descentralizao. Controle centralizado de um banco distribudo no faz sentido.
Uma organizao plausvel seria criar uma equipe local para cada n onde o banco reside
com autoridade para propor e implementar mudanas em detalhe no banco local e nos
esquemas externos locais. Haveria ainda uma equipe central com autoridade para coordenar
e vetar, se necessrio, mudanas no sistema (a serem implementadas pelas equipes locais).
As tarefas tradicionais da equipe de administrao de um banco de dados (centralizado)
incluem o projeto lgico e fsico do banco e sua documentao, definio dos vrios
esquemas externos em consulta com os analistas de aplicao, definio dos critrios de
autorizao, criao de rotinas de recuperao do banco, monitorao da utilizao do banco
e reestruturao do banco. No caso de bancos de dados distribudos, deve-se acrescentar
ainda a tarefa mais geral de garantir a cooperao entre os usurios em prol de uma
compartilhao efetiva dos dados.
- 8 -
Trs facetas da administrao de um BDD merecem especial ateno: documentao do
banco, administrao dos recursos locais de cada sistema e monitorao do sistema. (A tarefa
bsica de projeto lgico e fsico do banco j foi brevemente abordada na seo anterior).
A documentao do BDD deve tornar claro a todos os usurios o significado dos tens de
dados armazenados pelo banco. Isto requer regras para sistematizar a nomenclatura e a
descrio informal dos tens de dados, definio dos tipos de cada tem de dados e regras para
traduzir um tipo utilizado em uma mquina para o tipo equivalente de outra (e.g.,
representao e preciso de reais em mquinas diferentes).
A administrao da carga imposta a cada sistema que compe o BDD exige, antes de mais
nada, a definio de critrios de medio. Feito isto, necessrio criar regras que assegurem a
usurios remotos acesso a recursos locais e que atinjam um balanceamento entre a carga local
e a imposta por acessos remotos. Administrao da carga inclui, tambm, definir como ser
cobrado aos usurios locais e remotos a utilizao do sistema.
Finalmente, uma vez estabelecidas regras para administrao do banco, a equipe dever
auditar periodicamente o sistema para assegurar a aderncia a tais regras. A carga, tempo de
resposta e utilizao do sistema dever ser constantemente monitorada, prevendo-se
reestruturao do banco ou mudanas nas regras de administrao para corrigir
desequilbrios.
2.3.2 Problemas que Afetam a Administrao
Os problemas a serem enfrentados pela equipe de administrao para atingir os seus objetivos
podem ser compreendidos considerando-se trs cenrios bsicos para um banco de dados
distribudo.
Se o BDD resultou da interligao de sistemas existentes ento certamente aparecero
problemas devidos a: heterogeneidade do sistema global, introduo de padres globais sem
que seja comprometida a autonomia local, critrios de alocao de custos tendo em vista
acessos locais e remotos, alm do balanceamento do tempo de resposta de acessos locais e
remotos.
Se o cenrio admite a criao de novos bancos locais de forma semi-autnoma, aparecero
problemas relativos a: definio de regras e responsabilidades locais, descrio da semntica
dos dados definidos localmente, grau de cooperao entre os ncleos locais, principalmente
no que se refere alocao de recursos para processamento de acessos remotos.
Finalmente, em um cenrio onde o BDD foi criado pela distribuio em ns homogneos de
um sistema centralizado, haver o problema fundamental de definir uma estratgia de
distribuio que otimize o tempo de resposta global, sem penalizar demasiadamente grupos
de usurios.
NOTAS BIBLIOGRFICAS
O relatrio do CODASYL Systems Commitee [1982] discute extensivamente as principais
caractersticas, formas de organizao, problemas de administrao, etc. de BDDs. Gross et
all. [1980] contm uma discusso interessante dos problemas de administrao. Champine
[1978] apresenta vrios exemplos de BDDs. Shertock [1982] descreve o esforo da Philips
do Brasil na rea de sistemas distribudos. Schreiber, Baldissera e Ceri [1980] aborda, de um
ponto de vista genrico, aplicaes de BDDs. O problema de alocao de arquivos em um
- 9 -
sistema distribudo, assunto abordado muito superficialmente neste captulo, de primordial
importncia no projeto de BDDs. Este problema bastante semelhante ao problema clssico
de transporte em Pesquisa Operacional. Downy e Foster [1982] resume os principais modelos
e solues desenvolvidos para o problema de alocao de arquivos e Wah [1984] contm uma
introduo bastante interessante sobre o problema. Apers [1983] contm uma discusso longa
sobre o problema de alocao de arquivos em bancos de dados distribudos.
- 1 -
CAPTULO 3. INTRODUO AO PROCESSAMENTO DE CONSULTAS
O propsito deste captulo posicionar o leitor quanto ao problema de se processar consultas e
atualizaes em bancos de dados centralizados ou distribudos. Inicialmente, uma viso geral do
problema apresentada, indicando em linhas gerais todo o processo. Em seguida, a LMD
tomada como exemplo neste texto, SQL, definida. Por fim, o subsistema responsvel pelo
armazenamento interno do banco de dados descrito. Assim, o problema em questo fica
fixado em como traduzir comandos de SQL para operaes do subsistema de armazenamento.
Em toda discusso ser suposto que o SGBDD homogneo.
3.1 ETAPAS DO PROCESSAMENTO DE COMANDOS DA LMD
Processamento de consultas e atualizaes em um banco de dados distribudo corresponde
traduo de pedidos, formulados em uma linguagem de alto nvel, para seqncias de aes
elementares sobre os dados armazenados nos vrios bancos de dados locais. Mesmo abstraindo
os problemas de falhas no sistema e acessos concorrentes aos dados, este um problema difcil
e a LMD de alto nvel e no-procedimental.
O propsito desta seo indicar em linhas gerais como este problema pode ser subdividido em
problemas mais simples. O resultado ser uma arquitetura para o processador de comandos da
LMD. Todos os problemas referentes a falhas e acesso concorrente aos dados so supostos
resolvidos por camadas inferiores do SGBDD. Ou seja, para o processador de comandos tudo se
passa como se o sistema fosse perfeitamente confivel e monoprogramado.
A estrutura do processador de comandos da LMD induzida pela organizao imposta
descrio de bancos de dados distribudos. Lembremos que a descrio dividida em quatro
nveis: externo, conceitual global, conceitual local e interno local. A nvel externo, os diversos
grupos de usurios vem os dados que lhes interessam atravs de esquemas externos EE
1
, ... ,
EE
m
. Cada esquema externo EE
j
mapeado no esquema conceitual global, ECG, que define a
totalidade do banco a nvel conceitual global. A distribuio do banco definida em duas
etapas. Inicialmente, a distribuio definida a nvel lgico mapeando-se o esquema conceitual
global em uma coleo ECL
1
, ... , ECL
n
de esquemas conceituais locais, um para cada n onde
o banco ser armazenado, onde o esquema ECL
i
descreve o banco de dados local do n i a nvel
lgico. Como ltimo passo do processo, a estrutura interna de cada banco de dados local
definida por um esquema interno EI
i
(o esquema conceitual local ECL
i
, naturalmente, dever ser
mapeado no esquema interno local EI
i
).
Assim, um comando sobre um esquema externo sofrer as seguintes transformaes (ver Figura
3.1):
1. traduo para o esquema conceitual global;
2. traduo para os esquemas conceituais locais;
3. processamento local e transferncia de dados; e
4. ps-processamento global.
- 2 -
Figura 3.1 -Processamento de Comandos Distribudos
Consideremos inicialmente o caso mais simples de um sistema homogneo. A etapa inicial,
traduo para o esquema conceitual global, transforma o comando submetido pelo usurio,
como formulado em termos do esquema externo a que ele tem acesso, em um comando
equivalente, mas formulado em termos do esquema conceitual global. A etapa seguinte,
traduo para os esquemas conceituais locais, consiste da traduo do comando, formulado
agora em termos do esquema conceitual global, para uma seqncia de comandos locais e
transferncias de dados. Esta etapa inteiramente diferente do processamento de comandos em
um banco de dados centralizado e dever resolver os problemas inerentes distribuio do
banco. A fase de otimizao nesta etapa a parte crucial do processo. A terceira etapa,
processamento local e transferncia de dados, consiste em resolver comandos locais atravs do
SGBD local. A resoluo de um comando local poder, no entanto, envolver transferncia
prvia de dados.
O processamento de comandos locais idntico ao caso centralizado. Novamente, em termos
dos esquemas que compem a descrio do banco de dados local, podemos distinguir duas
etapas neste caso (ver Figura 3.2):
1. Traduo para o Esquema Interno.
2. Traduo para Acessos Fsicos.
Tradutor1
Tradutor2
SGBDL
BDL
Rede
comando expresso em termos
do esquema externo
comando expresso em termos
do esquema conceitual global
seqncia de comandos locais
e transferncias de dados
comando expresso em termos do
esquema conceitual local
seqncia de acessos fsicos
sobre o banco de dados local
Noi
Noj
(2)
(1)
(3)
- 3 -
Figura 3.2 - Fases do Processamento de Comandos Locais
A etapa de traduo para acessos fsicos ser estudada formulando-se uma mquina abstrata, ou
subsistema do SGBD, responsvel pelo armazenamento fsico do banco de dados. Chamaremos
esta mquina de subsistema de armazenamento (SAR). Este subsistema est dividido em dois
nveis:
nvel interno: define a interface oferecida por este subsistema ao processador de comandos. A
complexidade e eficincia do SGBD dependem em grande parte da variedade e
sofisticao das operaes oferecidas pelo SAR a este nvel.
nvel fsico: define as estruturas fsicas finais e os respectivos acessos fsicos a que esto
sujeitas.
A etapa de traduo para o esquema interno mapeia um comando formulado em termos do
esquema conceitual local para uma seqncia de operaes do SAR. Esta a etapa principal do
processo e, como em uma compilao tradicional, possui quatro fases distintas: anlise sinttica,
otimizao, gerao de cdigo e execuo.
Finalmente, a etapa de ps-processamento necessria pois o resultado de um comando poder
ser deixado sob forma de uma relao distribuda pelas etapas anteriores. Logo, necessrio
reunir os fragmentos do resultado em um nico n e entreg-lo ao usurio. Isto conclui a
discusso sobre SGBDDs homogneos. O caso heterogneo mais complicado na medida em
que os esquemas externos e os esquemas conceituais locais no necessariamente esto no
mesmo modelo de dados do esquema conceitual global. Isto torna a primeira e a ltima etapas
mais complexas e est fora do escopo deste texto.
O resto deste captulo define a LMD e o SAR a serem usados como exemplo no texto. Note que
ambos definem, respectivamente, a linguagem-fonte e a linguagem-objeto do processador de
comandos.
Tradutor1
SAR
BDL
comando expresso em termos
do esquema conceitual
seqncia de operaes do SAR
seqncia de acessos fsicos
sobre os dados armazenados
(2)
(1)
- 4 -
3.2 UMA LINGUAGEM DE DEFINIO E MANIPULAO DE DADOS
RELACIONAL
A base para discusso do problema de processamento de consultas e atualizaes ser uma
linguagem de manipulao de dados (LMD) relacional chamada SQL (ou SEQUEL, para
"Structured English Query Language"). A escolha justificada sob vrios aspectos. SQL uma
linguagem no-procedimental, da famlia do Clculo Relacional, de nvel bem mais alto que as
LMDs oferecidas pela maioria dos sistemas tradicionais. Portanto, um espectro bem maior de
problemas coberto ao se estudar como processar SQL do que seria possvel atendo-se apenas a
LMDs tradicionais. Por outro lado, SQL bastante representativa de uma nova gerao de
LMDs, sendo adotada por vrios sistemas recentes. Finalmente, a escolha de uma linguagem
especfica para servir de exemplo facilita a apresentao dos algoritmos de otimizao.
SQL inclui, ainda, uma linguagem de definio de dados (LDD) que permite a descrio de
esquemas conceituais e aspectos relativos a esquemas internos. Apenas a parte relativa ao
esquema conceitual ser abordada nesta seo.
3.2.1 Definio de Esquemas de Relao em SQL
Para definio de um esquema conceitual (global ou local) SQL oferece um comando para
descrio de esquemas de relao. Considere, por exemplo, um esquema conceitual (global ou
local) contendo os seguintes esquemas de relao:
FORNECEDOR [ NUMERO,NOME,SEDE ]
PRODUTO [ CODIGO,NOME,MELHOR_FORN ]
FORNECIMENTO [ NUMERO,CODIGO,QUANTIDADE,LOCAL ]
REGIAO [ NOME,ESTADO ]
Estes esquemas sero descritos em SQL da seguinte forma (j incluindo o tipo de cada atributo):
c reate table FORNECEDOR ( NUMERO (integer),
NOME (char(20)),
SEDE (char(5)) )
c reate table PRODUTO ( CODIGO (integer),
NOME (char(10)),
MELHOR_FORN (integer) )
c reate table FORNECIMENTO(NUMERO (integer),
CODIGO (integer),
QUANTIDADE (integer),
LOCAL (char(5)) )
create table REGIAO ( NOME (char(5)),
ESTADO (char(2)) )
Em geral, um esquema conceitual definido atravs de uma srie de comandos CREATE da
forma:
create table <nome de relao> <lista de atributos>
Embora no sejam descritos aqui, convm mencionar que, alm deste comando, SQL oferece
comandos para adicionar novos atributos a um esquema de relao e para retirar esquemas de
relao de um esquema relacional.
- 5 -
3.2.2 Consultas em SQL
As principais caractersticas de consultas em SQL sero apresentadas atravs de exemplos,
usando-se para tal o banco de dados relacional cujo esquema conceitual serviu de exemplo na
seo anterior. O estado deste banco de dados, apresentado abaixo, servir de base para
compreender o significado das consultas.
FORNECEDOR Nmero Nome Sede
10.329
22.345
41.738
5.938
Kopenhagen
Garoto
Nestle
Praline
SP
RJ
SP
DF
PRODUTO Cdigo Nome Melhor_Forn
342
2.580
34
Balas
Caramelos
Bombons
Garoto
Nestl
Praline
FORNECIMENTO Nmero Cdigo Quantidade Loc al
10.329
10.329
22.345
41.738
41.738
41.738
5.938
324
34
34
342
2.580
34
34
10.000
60.000
5.000
15.000
3.000
50.000
1.000
SP
SP
RJ
DF
RJ
MA
RJ
REGIO Nome Estado
Centro-Sul
Centro-Sul
SP
RJ
Uma consulta em SQL tem a forma genrica "SELECT-FROM-WHERE" indicando que campos
devem ser recuperados (SELECT) das tuplas daquelas relaes (FROM) que satisfazem a uma
determinada qualificao (WHERE). Por exemplo, a consulta "Obtenha o nome dos fornecedores
sediados em SP" seria formulada em SQL como:
selec t NOME
from FORNECEDOR
where SEDE = 'SP'
O resultado seria:
Nome
Kopenhagen
Nestl
Uma consulta envolvendo duas relaes seria "Obtenha o nome dos Fornecedores e a
quantidade fornecida relativos, ao produto 34", que em SQL ficaria na seguinte forma:
selec t F.NOME, FN.QUANTIDADE
from FORNECEDOR F, FORNECIMENTO FN
where F.NUMERO = FN.NUMERO
and FN.CODIGO = '34'
- 6 -
Neste exemplo, F e FN so variveis da consulta varrendo as relaes denotadas por
FORNECEDOR e FORNECIMENTO. Os atributos de cada relao so, ento, qualificados por estas
variveis. O resultado desta consulta seria:
Nome Quantidade
Kopenhagen
Garoto
Nestl
Praline
60.000
5.000
50.000
1.000
Duas ou mais variveis podem percorrer a mesma relao, como na consulta "Quais pares de
fornecedores tm sede no mesmo estado?":
selec t F1.NUMERO, F2.NUMERO
from FORNECEDOR F1, FORNECEDOR F2
where F1.SEDE = F2.SEDE
and F1.NUMERO < F2.NUMERO
A segunda clusula da qualificao foi adicionada para evitar que o mesmo par fosse
recuperado duas vezes apenas com a ordem invertida. O resultado da consulta seria:
Nmero Nmero
10.329 41.738
A qualificao de uma consulta , em geral, uma expresso booleana formada usando os
conectivos 'and', 'or' e 'not', aplicados a comparaes entre campos de tuplas ou entre um campo
de uma tupla e uma constante. Por exemplo, a consulta "Qual o nome dos fornecedores que no
esto sediados em SP e que fornecem ou o produto 34 ou o produto 45?" seria formulada como:
selec t F.NOME
from FORNECEDOR F, FORNECIMENTO FN
where not F.SEDE = 'SP'
and F.NUMERO = FN.NUMERO
and (FN.CODIGO = '34' or FN.CODIGO = '45')
O resultado seria:
Nome
Garoto
Praline
A forma genrica de uma consulta simples em SQL , ento:
selec t <lista resultante>
into <relao resultante>
from <lista de relaes>
where <qualificao>
onde
- 7 -
<lista de relaes>
uma lista de elementos, separados por vrgulas, da forma "R r", onde R
um nome de relao do banco de dados em questo e r uma varivel da
consulta varrendo R;
<lista resultante>
uma lista de elementos, separados por vrgulas, da forma "r . A", onde r
uma varivel da consulta e A um atributo do nome de relao varrido por r;
<rela o resultante>
um novo nome de relao que ter como atributos aqueles listados em
<lista resultante>
<qualific a o>
uma expresso booleana sobre comparaes, negadas ou no, da forma:
uma seleo da forma 'r.A <op><c onstante>', onde <op> um dos
operadores {<,,=,,>} e <c onstante> qualquer constante numrica ou
alfabtica;
uma restrio da forma 'r.A <op> r.B';
uma juno da forma 'r.A <op> s.B';
Nota: A clusula INTO no faz parte da sintaxe corrente de SQL e poder ser omitida. Foi
introduzida para facilitar a definio de consultas cujo resultado deve ser armazenado.
O resultado de uma consulta simples em um estado do banco de dados definido da seguinte
forma:
1. Forme o produto cartesiano P das relaes indicadas em <lista de rela es>;
2. Selecione as tuplas de P que satisfazem a <qualific a o>;
3. Projete estas tuplas nos atributos indicados em <lista resultante>. Este ser o resultado da
consulta.
Por fim SQL permite, ainda, formular a unio de duas consultas. Assim, se Q
1
e Q
2
so
consultas em SQL, e R
1
e R
2
so nomes de relaes, as expresses.
'Q
1
union Q
2
' e 'R
1
R
2
'
tambm so consideradas consultas em SQL, e so chamadas de consulta-unio.
SQL permite, ainda, a formulao de consultas mais sofisticadas, contendo subconsultas na
qualificao, bem como comparaes mais poderosas. No entanto, o processamento de
consultas mais complexas pode ser reduzido ao processamento de consultas simples atravs de
uma srie de transformaes.
3.2.3 Atualizaes em SQL
Atualizaes so formuladas em SQL de forma bem semelhante a consultas. Por exemplo, a
remoo "Elimine todos os fornecimentos do produto 34" seria formulada como:
delete FORNECIMENTO
where codigo=34
Inseres podem ser de apenas um registro como, por exemplo, "Adicione um novo produto
com cdigo '35' e nome 'Pirulito'", que seria indicada por:
insert into PRODUTO:
<'35','Pirulito'>
- 8 -
ou podem manipular vrios registros, como no seguinte caso: "Crie uma nova tabela contendo o
nome e nmero de todos os fornecedores do produto '34'":
insert into TEMP:
select F.NOME, F.NUMERO
from FORNECEDOR F, FORNECIMENTO FN
where F.NUMERO = FN.NUMERO
and FN.CODIGO = '34'
A insero de mltiplos registros difere da forma de consulta com clusula INTO apenas no
fato de poder referenciar relaes j existentes no banco.
Atualizaes tambm podem alterar apenas o valor de um ou mais campos de um grupo de
tuplas, como na seguinte operao "Mude todas as quantidades fornecidas para milhares de
unidades (ou seja, divida por mil todas as quantidades fornecidas)":
update FORNECIMENTO
set QUANTIDADE = QUANTIDADE / 1000
Isto conclui a nossa breve descrio de atualizaes em SQL.
3.2.4 Definio de Esquemas Externos e Mapeamentos em SQL
SQL permite definir esquemas externos atravs de um comando especial para introduzir novos
esquemas de relao por definio. Esquemas introduzidos desta forma sero chamados de
vises. Por exemplo, considere o seguinte esquema externo sobre o banco de dados usado como
exemplo nas duas sees anteriores:
Relao do esquema externo:
PRODUTO_NESTLE [ CODIGO,NOME,MELHOR_FORN ]
Mapeamento para o Esquema Conceitual:
A relao associada a PRODUTO_NESTLE conter triplas da forma (c,n,m), onde c o
cdigo de um produto fornecido pela Nestl, n o nome do produto e m/ o seu melhor
fornecedor.
O nico esquema de relao deste esquema externo e sua definio seriam descritos em SQL da
seguinte forma:
define view PRODUTO_NESTLE ( CODIGO,NOME,MELHOR_FORN )
as select P.CODIGO, P.NOME, P.MELHOR_FORN
from PRODUTO P, FORNECIMENTO F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
A forma geral do comando DEFINE VIEW descrevendo um esquema de relao introduzido
por definio ser, ento:
define view <esquema de relao> as <c onsulta>
- 9 -
Uma vez definidas, pode-se consultar vises como qualquer outra relao. No entanto,
atualizaes sobre vises criam certos problemas ao serem traduzidas para o esquema
conceitual e, usualmente, so restritas a classes bem especficas.
Note que o mapeamento definindo o novo esquema de relao em termos do esquema
conceitual descrito, no comando DEFINE VIEW, atravs de uma consulta. Da mesma forma,
os mapeamentos do esquema conceitual global para os esquemas conceituais locais podem ser
descritos por consultas em SQL, assumindo que todos os SGBDs locais so baseados no
modelo relacional. Esta observao validada pelo fato de ambos os tipos de esquemas
admitirem apenas relaes como estruturas de dados neste caso. Exemplos sero apresentados
na Seo 1.4.
J o mapeamento dos esquemas conceituais locais para os esquemas internos em geral no pode
ser descrito atravs desta tcnica, pois os esquemas internos no admitem apenas relaes como
estruturas de dados.
Isto conclui a nossa discusso sobre SQL.
3.3 O SUBSISTEMA DE ARMAZENAMENTO
Esta seo define o subsistema de armazenamento (SAR) que ser adotado como exemplo em
todos os captulos que tratam de processamento de comandos da LMD.
O SAR responsvel pelo armazenamento interno de bancos de dados, incluindo as estruturas
auxiliares de acesso, alm de oferecer uma interface consistindo de uma srie de operaes
sobre estas estruturas internas. A descrio do SAR clarifica, portanto, qual a linguagem-objeto
do tradutor de comandos da LMD e isola o otimizador dos detalhes de armazenamento, exceto
no que se refere computao da funo de custo. O SAR servir tambm como meio de se
abstrair os vrios mtodos de acesso e suas operaes (no estudado neste texto).
O SAR ser dividido em dois nveis:
nvel interno: define a interface com o processador da LMD;
nvel fsico: define as estruturas fsicas finais e os respectivos acessos fsicos.
Esta seo tratar de cada um destes nveis em separado. Lembremos, neste ponto, que o banco
de dados suposto relacional, o que significa que as estruturas lgica de dados so relaes.
3.3.1 O Nvel Interno do SAR
Esta subseo define as estruturas internas e operaes que compem a interface oferecida pelo
SAR ao processador de comandos da LMD.
3.3.1.1 Estruturas Internas
As estruturas internas sero tabelas definidas como seqncias de registros internos (ou
simplesmente registros) semelhantes. Um registro interno a menor unidade que o SAR
acessa. Cada registro possui um campo especial que o identifica univocamente na tabela. Este
campo chamado de identificador do registro e pertence a um tipo de dados especial, chamado
IDR.
- 10 -
Uma tabela descrita atravs de um esquema de tabela T[A
1
, ... , A
n
], onde T o nome da
tabela e A
1
, ... , A
n
so os atributos da tabela, ou seja, nomes para os campos dos registros da
tabela. Assume-se que cada atributo est associado a um tipo de dados, omitido da definio do
esquema por simplicidade.
Quatro tipos de tabelas sero considerados: tabelas externas, tabelas de inverso, tabelas
internas e tabelas transientes.
Tabelas externas residem em memria secundria e contero relaes do banco ou relaes
temporrias resultantes de comandos.
Tabelas de inverso (TINVs) so tabelas agindo como arquivos invertidos para tabelas externas.
Ou seja, cada TINV U est associada a uma tabela subjacente T e a uma lista L=( L
1
, ... ,L
n
) de
atributos de inverso de T (com relao a U). Alm disto, para cada valor v=(v
1
, ... , v
n
)
ocorrendo na projeo de T em L, h um registro <i,v
1
, ... ,v
n
,l> em U, onde i o identificador
do registro, e l a lista de todos os identificadores de registros t de T tais que t[L]=v. Neste
caso, assume-se que U descrita por um esquema da forma U[IDR,L
1
, ... , L
n
,P], onde o tipo
de dados de IDR IDR e este atributo corresponde ao campo contendo o identificador do
registro; L
1
, ... , L
n
a lista de atributos de T onde foi feita a inverso; o tipo de dados de P
lista de identificadores e este atributo corresponde lista de identificadores em cada registro.
Note que uma TINV pode ser implementada como uma rvore-B, uma tabela de "hashing" ou
outra estrutura adequada, mas a forma exata abstrada neste modelo.
Uma tabela interna idntica a uma tabela externa, exceto que reside em memria principal.
Tipicamente, conter resultados intermedirios de consultas que so suficientemente pequenos
para ocupar pouca memria.
Uma tabela transiente uma estrutura de dados usada como forma de comunicao entre
operaes do SAR que funcionam como um par produtor-consumidor. Consiste,
essencialmente, de uma area de memria e operaes para se acrescentar e retirar registros da
rea. Tal estrutura permite a uma operao passar gradualmente os registros de um resultado
intermedirio para a operao seguinte. usada quando o resultado intermedirio grande
demais para ser armazenado em uma tabela interna e a operao seguinte no necessita da
tabela completa para iniciar o processamento dos seus registros.
Isto conclui a descrio das estruturas internas. Deixaremos em aberto os detalhes de
implementao dos diversos tipos de tabelas, j que isto usualmente coberto em textos
versando sobre estruturas de dados.
3.3.1.2 Operaes sobre Tabelas
A interface do SAR oferece trs operaes para criao/eliminao de tabelas, teis ao
processamento de comandos da linguagem de definio de dados:
CRIA_TAB(T,X)
Cria uma tabela externa T com atributos X.
- 11 -
CRIA_INV(T,Y,U)
Cria uma tabela de inverso U invertendo T em Y. Os atributos de U so fixados "a
priori", como discutido anteriormente. T dever ser uma tabela externa.
Esta operao til tambm em certas estratgias para processamento de consultas, onde
inverses temporrias so criadas apenas para o processamento de uma consulta. Porm, neste
texto no ser descrita nenhuma estratgia que faa uso de inverses temporrias.
DESTROI(T)
Destroi a tabela T.
Para processamento especfico de comandos da linguagem de manipulao de dados, a interface
a nvel interno do SAR oferece quatro classes de operaes: unio, ordenao, pesquisa
seqencial, pesquisa direta e juno. Cada uma destas classes de operaes pode ter mais de
uma realizao no SAR e, em particular, as tabelas recebidas como entrada podem ser de vrios
tipos. As diferentes formas de realizao sero discutidas junto com a descrio das operaes.
Seja <op> um dos operadores {<,,=,,>}. Sejam T e U nomes de tabelas e X e Y listas de
atributos de T e U, respectivamente, do mesmo comprimento. Usaremos no que se segue P(T)
para indicar uma expresso booleana envolvendo comparaes, negadas ou no, da forma
T.X <op> T.Y ou T.X <op> <constante>. Usaremos ainda P(T,U) para representar uma
expresso booleana sobre comparaes da forma T.X <op> U.Y.
Sejam T[IDR, A
1
, ... , A
m
] e U[IDR , B
1
, ... , B
n
] e X, Y listas de atributos de T e U,
respectivamente. As operaes do SAR sero as seguintes:
ORD(T,X,tipo;V)
Uma ordenao de T sobre X cria uma nova tabela V com os registros de T ordenados
por X em ordem ascendente, se tipo for 'asc', ou em ordem descendente, se tipo for
'desc'. T no poder ser uma tabela transiente, neste caso.
UNIO(T,U;V)
Uma unio de T e U cria uma nova tabela V contendo todos os registros de T e U, sem
eliminar duplicatas.
PESQ_SEQ(T,X,P(T);V)
Uma pesquisa sequencial em T cria uma nova tabela V[IDR,X] contendo os registros de
T que satisfazem a P(T), com os campos que no esto em X eliminados. Duplicatas
resultantes do processo no so eliminadas e a identificao dos registros de V gerada
automaticamente.
Esta operao implementada atravs de uma pesquisa sequencial em T.
- 12 -
PESQ_DIR(T,X,P(T),U,Q(T);V)
Para uma pesquisa direta em T via U, necessrio que:
U seja uma tabela de inverso para T sobre uma lista de atributos Y;
T seja uma tabela externa ou uma tabela interna (so os nicos tipos para os quais
possvel criar uma inverso);
todos os atributos de T referenciados em Q(T) devem pertencer lista de inverso Y;
A definio desta operao idntica da anterior, exceto que as tuplas recuperadas de T
devem satisfazer a P(T)Q(T).
Quanto sua implementao, U acessada identificando-se cada registro u de U que satisfaz Q
(isto possivel pela terceira restrio acima). Em seguida, cada registro t em T, cujo
identificador ocorre na lista de identificadores em u, recuperado. Tais registros
necessariamente satisfazem Q. A projeo em X de cada registro t que satisfaz a P(T) forma,
ento, um registro da tabela resultante. Duplicatas no so eliminadas.
JUNO(T,U,X,Y,P(T,U),P(T),P(U);V)
De forma genrica, uma juno de T e U constri uma nova tabela V[IDR,X,Y] tal que v
um registro de V se e somente se existem registros t e u em T e V tais que (i) v[X] =
t[X], v[X]=u[Y] e v[IDR] um novo identificador; (ii) t satisfaz a P(T); (iii) u satisfaz a
P(U); (iv) t e u concatenadas satisfazem a P(T,U).
Esta operao coincide, portanto, com a operao tradicional de juno da lgebra relacional,
seguida de projees sobre X e Y. Dois algoritmos sero consideradas aqui: juno interativa e
juno por intercalao.
A juno interativa implementada da seguinte forma: os registros de T satisfazendo a P(T) so
recuperados um a um; para cada registro t recuperado, a tabela U pesquisada recuperando-se
um a um todos os registros u satisfazendo a P(U). A partir de t e u constri-se um registro v que
se satisfizer a P(T,U) acrescentado tabela resultante. Mais precisamente, temos a seguinte
definio em pseudo-cdigo:
JUNO_INTERATIVA(T,U,X,Y,P(T,U),P(T),P(U);V):
begin
inicie V como vazia;
foreach registro t de Tque satisfaz a P(T) do
begin
substitua t em P(T,U) criando Q(U);
foreach registro u de U
que satisfaz a P(U) e Q(U) do
begin
acrescente um registro v a V
criado a partir de t e u;
end
end
end
- 13 -
Refinamentos deste algoritmo so obtidos utilizando-se as operaes de pesquisa seqencial e
pesquisa direta para acessar os registros de T e U. O resultado da pesquisa em T (ou U), em
qualquer caso, passado sob forma de uma tabela transiente para o corpo do algoritmo de
juno. Se pesquisa direta for escolhida para T (ou U) ento T (ou U) pode ainda ser uma tabela
externa ou uma tabela interna; se pesquisa seqencial for adotada, T (ou U) pode ser uma tabela
externa, uma tabela interna ou uma tabela transiente. O resultado V tambm pode ser criado
como uma tabela externa, uma tabela interna ou uma tabela transiente.
Junes sobre tabelas de ndices tambm oferecem opes interessantes para processamento de
consultas, embora no sejam adotadas neste texto. Portanto, a operao de juno no ser
definida sobre tabelas de ndices.
A juno por intercalao se aplica quando P(T,U) da forma T.X <op> U.Y & Q(T,U), onde
<op> um dos comparadores anteriormente apresentados. Ou seja, dever haver uma
comparao distinguida, possivelmente conjugada com outras comparaes. Este tipo de juno
exige ainda que os registros de T e U estejam ordenados pelos atributos X e Y, respectivamente,
em uma ordem de juno compatvel com T.X <op> U.Y, qual seja:
se <op> for '=', ento a ordenao poder ser tanto ascendente quanto descendente (mas a
mesma para T e U);
se <op> for '<' ou '', a ordenao dever ser ascendente;
se <op> for '>' ou '', a ordenao dever ser descendente;
Nesta implementao de juno, os registros de T so recuperados um a um e, como na juno
interativa, para cada registro t de T, registros da tabela U so recuperados, criando-se registros
da tabela V. A posio do primeiro registro u de U que casa com t guardada. Assim, quando o
prximo registro t' de T lido, a tabela U pesquisada a partir da posio guardada. Mais
precisamente, em pseudo-cdigo temos:
/ *
P(T,U) da forma T.X<op>U.Y & Q(T,U)
Te U esto ordenados por X e Y, respectivamente,
em uma ordem de juno c ompatvel com T.X<op>U.Y
*/
begin
inicie V como vazia;
if U for vazia then retorne;
inicie u0 com o primeiro registro de U;
foreach registro t de Tque satisfaz P(T) do
begin
substitua t em T.X<op>U.Y criando C(U);
leia os registros de U a partir de u0
at encontrar o primeiro que satisfaz C(U) ou U se esgotar;
if U se esgotou then retorne;
inicie u0 com u;
substitua t em Q(T,U) criando Q(U);
foreach registro u de U a partir de u0
que satisfaz C(U), Q(U) e P(U) do
begin
acrescente um registro v a V criado a partir de t e u;
end
end
end
- 14 -
3.3.2 O Nvel Fsico do SAR
O nvel fsico do SAR define a estrutura fsica final onde sero armazenados os dados, as
estruturas auxiliares de acesso aos dados (i.e., tabelas de inverso) e mesmo informaes de
controle do SGBDD, como o prprio diretrio de dados. O nvel fsico define ainda as aes
elementares (ou acessos fsicos) que manipulam as estruturas fsicas. Esta seo apresenta
apenas um esboo do que seria o nvel fsico do SAR, pois os detalhes de sua implementao
esto intimamente ligados aos mtodos de controle de integridade utilizados pelo sistema (veja
a Seo 9.2).
Para o nvel fsico do SAR, a memria secundria est dividida em segmentos e cada segmento
est dividido em pginas de tamanho fixo. Cada pgina possui um identificador nico. A
memria principal conter reas de trabalho, cada rea seria capaz de conter uma pgina. Toda
vez que dados contidos em uma pgina forem necessrios, a pgina inicialmente lida para uma
rea de trabalho e os dados so ento extrados. O mecanismo de gerncia das reas de trabalho
deixado em aberto.
O SAR possui apenas duas aes elementares operando sobre pginas (outras aes sero
acrescentadas na Seo 9.2):
R(X) leia todas as pginas cujos identificadores esto contidos no conjunto X
W(X) escreva novamente em memria secundria todas as pginas contidas na rea de
"buffers" cujos endereos esto em X
e duas operaes sobre o contedo das pginas:
r(x,p,s) recupere o contedo da pgina x a partir da posio p at a posio p+s-1
w(x,p) mude o contedo da pgina x a partir da posio p (o novo valor bem como o seu
comprimento foram omitidos da definio da operao por simplicidade)
O conceito de ao elementar ser usado novamente nos captulos sobre processamento de
transaes, controle de integridade e controle de concorrncia.
3.3.3 Definio dos Esquemas Internos
Uma vez descrita a forma interna de armazenamento do banco de dados, possvel, ento,
discutir como so definidos os esquemas internos. Seja E um esquema conceitual (local, no caso
distribudo), ou seja, uma coleo de definies de esquemas de relao usando o comando
DEFINE TABLE de SQL. Na sua forma mais geral, um esquema interno para E seria definido em
dois passos, refletindo a estrutura do SAR.
Inicialmente, cada esquema de relao seria mapeado em uma ou mais tabelas externas. O
mapeamento indicaria a correspondncia entre os registros das tabelas externas e as tuplas da
relao denotada pelo esquema. Alm do mapeamento de esquemas de relao em tabelas
externas, na primeira fase da descrio do esquema interno seriam definidas tabelas de inverso
representando inverses sobre atributos das tabelas externas. A escolha de que inverses
- 15 -
devero existir depende das consultas e atualizaes que so antecipadas, e influencia
decisivamente a performance do sistema.
Em uma segunda fase, as tabelas externas e de inverso so mapeadas em segmentos, e os
registros destas tabelas em pginas dos segmentos. Convm mapear registros de tabelas
diferentes, que so freqentemente acessados em conjunto, na mesma pgina ou em pginas
contguas, sempre que possvel. Os critrios que governam a estratgia de grupamento sero
chamados de critrios de contigidade fsica.
A regra mais simples para definir esquemas internos seria mapear cada esquema de relao
R[A
1
, ... , A
n
] em uma nica tabela externa, cujos registros representam tuplas da relao
corrente associada a R. Neste caso, a tabela externa poderia ser descrita pelo esquema R[IDR ,
A
1
, ... , A
n
], onde o tipo de dados de IDR IDR e este atributo corresponde ao campo contendo
o identificador do registro. Assim, uma tabela externa herda o nome e os atributos da relao
que armazena. Da mesma forma, cada tabela externa seria armazenada em um segmento
diferente. Em todos os exemplos descritos neste texto adotaremos este mapeamento simples.
A linguagem usada para descrever o esquema interno , s vezes, chamada de linguagem de
definio interna de dados (LDID). Ela dever, no caso do subsistema de armazenamento aqui
descrito, permitir a declarao de tabelas externas e de inverso, a declarao de segmentos e
critrios de contigidade fsica, alm dos mapeamentos dos esquemas de relao em tabelas
externas e das tabelas nos segmentos. Neste texto no entraremos nos detalhes especficos de
uma LDID.
3.4 EXEMPLO DO PROCESSAMENTO DE UMA CONSULTA
Para ilustrar o processamento de comandos da LMD, nesta seo sero apresentadas todas as
fases do processamento de uma consulta formulada sobre um esquema externo.
O esquema conceitual global ser o seguinte:
ESQUEMA CONCEITUAL GLOBAL
create table PRODUTO ( CODIGO (integer),
NOME (char(10)),
MELHOR_FORN (integer) )
c reate table FORNECIMENTO ( NUMERO (integer),
CODIGO (integer),
QUANTIDADE (integer),
LOCAL (char(5)) )
Suporemos que a rede possui trs ns (RJ, SP e DF, digamos) e que o banco est armazenado
em dois ns apenas (RJ e SP).
- 16 -
O primeiro n (RJ) contm toda a relao de produtos e todos os fornecimentos, exceto aqueles
para SP. O esquema conceitual local a RJ ser, portanto:
ESQUEMA CONCEITUAL LOCAL AO N 'RJ'
create table PRODUTO_RJ ( CODIGO (integer),
NOME (char(10)),
MELHOR_FORN (integer) )
create table FORNECIMENTO_RJ ( NUMERO (integer),
CODIGO (integer),
QUANTIDADE (integer),
LOCAL (char(5)) )
Assumiremos que o esquema interno deste n contm as seguintes tabelas (vide Seo 1.3.3):
ESQUEMA INTERNO LOCAL AO N 'RJ'
PRODUTO_RJ
tabela externa armazenando a relao correspondente ao esquema
de quem herda o nome
FORNECIMENTO_RJ
tabela externa armazenando a relao correspondente ao esquema
de quem herda o nome
PRODUTO_RJ_COD
tabela de inverso sobre o atributo CODIGO de
PRODUTO_RJ
FORNECEDOR_RJ_NUM
tabela de inverso sobre o atributo NUMERO de
FORNECEDOR_RJ
FORNECEDOR_RJ_COD
tabela de inverso sobre o atributo CODIGO de
FORNECEDOR_RJ
Note que o mapeamento do esquema conceitual para o interno aquele trivial em que cada
esquema de relao corresponde a uma tabela externa de mesmo nome.
O mapeamento do esquema conceitual global para o esquema conceitual local em 'RJ'
definido tratando-se PRODUTO_RJ e FORNECIMENTO_RJ como vises do esquema global:
MAPEAMENTO DO ESQUEMA CONCEITUAL GLOBAL PARA O LOCAL EM 'RJ'
define view PRODUTO_RJ ( CODIGO,NOME,MELHOR_FORN )
as select CODIGO, NOME, MELHOR_FORN
from PRODUTO
define view FORNECIMENTO_RJ (NUMERO,CODIGO,QUANTIDADE,LOCAL )
as select NUMERO,CODIGO, QUANTIDADE, LOCAL
from FORNECIMENTO
where LOCAL = 'SP'
- 17 -
O segundo n (SP) contm apenas os fornecimentos relativos a SP. O esquema conceitual local
ser, ento:
ESQUEMA CONCEITUAL LOCAL AO N 'SP'
create table FORNECIMENTO-SP ( NUMERO (integer),
CODIGO (integer),
QUANTIDADE (integer),
LOCAL (char(5)) )
Assumiremos que o esquema interno deste n contm as seguintes tabelas, por sua vez:
ESQUEMA INTERNO LOCAL AO N 'SP'
FORNECIMENTO-SP
tabela externa armazenando a relao
correspondente ao esquema de quem herda o nome
FORNECEDOR-SP-NUM
tabela de inverso sobre o atributo NUMERO de
FORNECEDOR-SP
FORNECEDOR-SP-COD
tabela de inverso sobre o atributo CODIGO de
FORNECEDOR-SP
O mapeamento deste esquema conceitual local para o esquema conceitual global ser:
MAPEAMENTO DO ESQUEMA CONCEITUAL GLOBAL PARA O LOCAL EM 'SP'
define view FORNECIMENTO-SP (NUMERO,CODIGO,QUANTIDADE,LOCAL )
as select NUMERO,CODIGO, QUANTIDADE, LOCAL
from FORNECIMENTO
where LOCAL = 'SP'
Como dito anteriormente, o terceiro n no armazena nenhuma parte do banco de dados.
Os mapeamentos do esquema conceitual global para os esquemas conceituais locais so teis
para traduzir atualizaes globais em atualizaes locais. Para se processar consultas, necessita-
se do mapeamento inverso, ou seja, necessita-se considerar cada relao do esquema conceitual
global como uma viso sobre a unio dos esquema conceituais locais. O mapeamento inverso
ser, ento:
MAPEAMENTO DO ESQUEMA CONCEITUAL GLOBAL PARA OS LOCAIS
define view PRODUTO ( CODIGO,NOME,MELHOR_FORN )
as select CODIGO, NOME, MELHOR_FORN
from PRODUTO_RJ
define view FORNECIMENTO (NUMERO,CODIGO,QUANTIDADE,LOCAL )
as select NUMERO, CODIGO, QUANTIDADE, LOCAL
from FORNECIMENTO_RJ
union
select NUMERO, CODIGO, QUANTIDADE, LOCAL
from FORNECIMENTO-SP
- 18 -
Considere agora um esquema externo, definido sobre o esquema conceitual global introduzido
acima, e contendo apenas uma relao:
ESQUEMA EXTERNO
define view PRODUTO_NESTLE ( CODIGO,NOME,MELHOR_FORN )
as select P.CODIGO, P.NOME, P.MELHOR_FORN
from PRODUTO P, FORNECIMENTO F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
Estaremos interessados em processar a seguinte consulta, Q
0
, sobre este esquema externo
("Qual o cdigo dos produtos para os quais a Nestl o melhor fornecedor?"):
select CODIGO
from PRODUTO_NESTLE
where MELHOR_FORN = '41.738'
Seguindo a Figura 1, o primeiro passo traduzir Q
0
para o esquema conceitual global. Isto
feito substituindo-se a referncia a PRODUTO_NESTLE pela sua definio. A consulta resultante,
Q
1
, ser:
select P.CODIGO
from PRODUTO P, FORNECIMENTO F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
and P.MELHOR_FORN = '41.738'
O segundo passo do processamento consiste em traduzir Q
1
para uma seqncia de
transferncias de dados e consultas sobre os esquemas conceituais locais. H vrias estratgias
para tal, algumas das quais sero discutidas no Captulo 5. Procederemos aqui da seguinte
forma. Inicialmente, traduziremos Q
1
para uma consulta Q
2
sobre a unio dos esquemas
conceituais locais. Este passo idntico ao anterior e consiste em substituir-se cada relao do
esquema conceitual global pela sua definio em termos da unio dos esquemas conceituais
locais:
select P.CODIGO
from PRODUTO_RJ P, FORNECIMENTO_RJ F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
and P.MELHOR_FORN = '41.738'
union
select P.CODIGO
from PRODUTO_RJ P, FORNECIMENTO-SP F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
and P.MELHOR_FORN = '41.738'
Note que Q
2
a unio de duas subconsultas, a primeira das quais local ao n 'RJ' enquanto que
a segunda envolve uma tabela localizada em 'RJ' e outra localizada em 'SP'.
- 19 -
Adotaremos, ento, a seguinte estratgia:
1) A primeira subconsulta de Q
2
processada da seguinte forma:
a) Inicialmente a seguinte consulta, Q
21
, que nada mais do que a primeira subconsulta de
Q
2
ligeiramente modificada para produzir uma relao armazenada, executada em RJ:
select P.CODIGO
from PRODUTO_RJ P, FORNECIMENTO_RJ F
into CODIGO_RJ
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
and P.MELHOR_FORN = '41.738'
Note que o resultado de Q
21
, CODIGO_RJ, dever ser substancialmente menor do que as
tabelas em RJ, pois contm apenas parte dos cdigos originalmente armazenados em
PRODUTO_RJ.
b) O resultado de Q
21
, CODIGO_RJ, movido para o destino final, DF, atravs de uma
transferncia de dados T
21
.
2) A segunda subconsulta de Q
2
processada da seguinte forma:
a) Para minimizar os dados transferidos, PRODUTO_RJ inicialmente reduzida atravs da
seguinte subconsulta Q
22
:
select CODIGO
from PRODUTO_RJ
into PRODUTO-MELHOR_RJ
where P.MELHOR_FORN = '41.738'
Esta subconsulta induzida pela clusula da qualificao de Q
2
que afeta apenas
PRODUTO_RJ.
Note que o resultado de Q
22
, PRODUTO-MELHOR_RJ/ certamente menor do
PRODUTO_RJ pois duas colunas foram eliminadas e provavelmente muitas tuplas.
Portanto, esta reduo benfica em termos do nmero de mensagens que economiza.
b) PRODUTO-MELHOR_RJ ento movida de RJ para SP atravs de uma transferncia T
22
.
c) Uma vez recebida esta tabela em SP, a seguinte subconsulta local, Q
23
, executada:
select P.CODIGO
from PRODUTO-MELHOR_RJ P, FORNECIMENTO-SP F
into CODIGO-SP
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
Esta subconsulta induzida pelas clusulas que se referem apenas a F e P (onde P agora
varre PROD-MELHOR_RJ).
d) Finalmente, o resultado de Q
23
, CODIGO-SP, movido para o destino final, DF, atravs
de uma transferncia de dados T
23
.
- 20 -
3) Aps CODIGO_RJ e CODIGO-SP terem sido recebidas em DF, a sua unio, Q
3
, obtida,
produzindo o resultado final da consulta
Sucintamente, esta estratgia pode ser expressa atravs do seguinte programa concorrente:
P = (Q
21
; T
21
// Q
22
; T
22
; Q
23
; T
23
) ; Q
3
indicando que a seqncia de operaes Q
21
; T
21
pode ser processada (em RJ) em paralelo com
a seqncia Q
22
; T
22
; Q
23
; T
23
(processada em RJ e SP). Aps o trmino de ambas, Q
3

executada (em DF).
O resto deste exemplo discute como cada subconsulta local poderia ser processada utilizando-se
as operaes do SAR apresentadas na Seo 1.3. Considere Q
21
primeiro. Esta subconsulta pode
ser, por exemplo, processada por uma juno interativa das tabelas externas PRODUTO_RJ e
FORNECIMENTO_RJ, tendo como predicado de juno P.CODIGO=F.CODIGO, como filtro para
os registros de PRODUTO_RJ o predicado P.MELHOR-FORN = 41.738, e como filtro para os
registros de FORNECIMENTO_RJ o predicado F.NUMERO = 41.738. possvel ainda usar pesquisa
direta para acessar estas tabelas pois esto ambas invertidas por CODIGO, atravs das tabelas de
inverso PRODUTO_RJ_COD e FORNECEDOR_RJ_COD, respectivamente. O resultado
produzido como uma tabela externa CODIGO_RJ a ser transferida para DF atravs de T
21
.
Para processar Q
22
s se poder usar uma pesquisa seqencial na tabela externa PRODUTO_RJ,
pois no h uma inverso em MELHOR_PROD. O resultado criado sob forma de uma tabela
externa PRODUTO-MELHOR_RJ a ser remetida para SP via T
22
.
Q23 poder ser processada por uma juno interativa das tabelas externas PRODUTO-MELHOR-
RJ e FORNECEDOR-SP, tendo como predicado de juno P.CODIGO = F.CODIGO. Os registros
da tabela FORNECIMENTO-SP tero como filtro o predicado F.NUMERO = 41.738. A pesquisa em
FORNECEDOR-SP poder ser direta via a tabela de inverso FORNECEDOR-SP-COD, mas a
pesquisa em PRODUTO-MELHOR_RJ ter que ser seqencial, pois no h inverses sobre esta
tabela recm-criada pela consulta Q
22
e recebida atravs da transferncia T
22
.
Finalmente, Q
3
processada atravs de uma operao UNIAO.
As decises, ilustradas acima, sobre o desmembramento de uma consulta distribuda em
subconsultas locais mais transferncias de dados, bem como sobre a escolha das operaes do
SAR para processar consultas locais contituem o tpico dos dois prximos captulos.
NOTAS BIBLIOGRFICAS
Apers [1983] trata explicitamente de processamento de consultas em bancos de dados
distribudos. Bracchi et all. [1980] e Spaccapietra [1980] discutem o problema genrico de
processar consultas de alto nvel em BDDs. Stonebraker [1980] contm algumas observaes
sobre como processar atualizaes. A definio original de SQL encontra-se em Chamberlin,
Astrahan, Eswaran e Lorie [1976]. O Captulo 7 de Date [1981] explica as principais
caractersticas de SQL. A definio do subsistema de armazenamento foi inspirada no
subsistema RSS do Sistema R, descrito brevemente em Astrahan et all. [1981] e em Blasgen et
all. [1979]. O Captulo 10 de Date [1981] tambm contm uma breve introduo ao RSS.
- 21 -
Blasgen e Eswaran [1976] enumeram vrios algortmos para fazer junes, incluindo os dois
descritos neste captulo. Kim [1981] apresenta novos mtodos para juno. Rosenthal e Reiner
[1982] apresentam uma proposta bem estruturada para um otimizador de consultas, incluindo
formas muito interessantes de realizar junes atravs de tabelas de inverso. Mais referncias
podero ser encontradas nas notas bibliogrficas dos Captulos 4 e 5.
- 1 -
CAPTULO 4. PROCESSAMENTO DE COMANDOS DA LMD
- O CASO CENTRALIZADO
Este captulo aborda o problema do processamento de comandos da LMD para o caso de
bancos de dados centralizados. Assume-se que a LMD e o subsistema de armazenamento so
aqueles descritos no captulo anterior e que o SGBD homogneo. A maior parte do captulo
devotada ao processamento de consultas, enfatizando especialmente o problema de
otimizao. Atualizaes sero tratadas apenas na ltima seo.
Toda discusso deste captulo, naturalmente, tambm se aplica ao processamento local de
comandos da LMD no caso de um SGBD distribudo.
4.1 INTRODUO AO PROCESSAMENTO DE CONSULTAS
Processamento de consultas em um banco de dados centralizado (ou processamento de
consultas locais em um ambiente distribudo) corresponde a traduo de pedidos, formulados
em uma linguagem de alto nvel, para seqncias de operaes elementares sobre os dados
armazenados em um banco centralizado (ou em um banco local no caso de um SGBDD). Em
termos dos esquemas que compem a descrio de um banco de dados centralizado, podemos
distinguir, ento, trs etapas:
1. Traduo para o Esquema Conceitual.
2. Traduo para o Esquema Interno.
3. Traduo para Acessos Fsicos.
A etapa inicial, traduo para o esquema conceitual, transforma a consulta submetida pelo
usurio, como formulada em termos do esquema externo a que ele tem acesso, em uma
consulta equivalente, mas formulada em termos do esquema conceitual. A ltima etapa,
traduo para acessos fsicos, de responsabilidade do subsistema de armazenamento
(SAR), conforme discutido na Seo 3.3. Portanto, no ser abordada neste captulo.
A etapa intermediria, traduo para o esquema interno, mapeia uma consulta, formulada
agora em termos do esquema conceitual, para uma seqncia de operaes do nvel interno do
SAR. Esta a etapa principal do processo e, como em uma compilao tradicional, possui
quatro fases distintas: anlise sinttica, otimizao, gerao de cdigo e execuo. A fase de
anlise sinttica a mais simples e no apresenta novidades. Aps uma validao inicial da
sintaxe do comando, informao acerca das relaes referenciadas na consulta obtida do
catlogo. Uma nova validao feita verificando-se se os atributos usados pertencem s
relaes, se as comparaes respeitam os tipos de dados, etc. Esta fase no ser abordada
neste captulo. A fase de otimizao a mais difcil e ocupar a maior parte deste captulo. De
fato, se a LMD no-procedimental, uma consulta indica que dados devem ser recuperados,
mas no como estes dados devem ser recuperados. Cabe, ento, ao otimizador definir como,
ou seja, selecionar uma seqncia de operaes do subsistema de armazenamento que traduza
corretamente a consulta e minimize uma dada funo de custo. O resultado da fase de
otimizao ser um plano de acesso aos dados, em pseudo-cdigo, representando a seqncia
de operaes escolhida.
- 2 -
Figura 4.1 - Fases do Processamento de Consultas
As duas ltimas fases, gerao de cdigo e execuo, refletem uma de duas estratgias
adotadas: interpretao ou compilao. Se a primeira estratgia for adotada, no h distino
entre estas duas fases: o pseudo-cdigo gerado pelo otimizador executado
interpretativamente. Nesta estratgia, cada vez que uma consulta re-submetida sofrer todo
o processo de traduo desde o incio pois nenhum cdigo armazenado. Nas sees
seguintes, esta ser a estratgia adotada.
Uma consulta poder, por outro lado, ser compilada da forma usual, armazenando-se o cdigo
gerado (correspondente seqncia de operaes escolhida pelo otimizador) para posterior
execuo. Desta forma, diminui-se o tempo de execuo de comandos repetitivos,
aumentando-se a performance dos programas de aplicao.
H uma diferena fundamental, no entanto, entre a compilao de consultas de uma LMD e a
compilao de programas usuais. Um programa, escrito em uma linguagem de programao
normal, mapeado em um conjunto de instrues que fixo para a mquina onde o programa
ser executado. Analogamente, uma consulta da LMD mapeada em operaes sobre as
estruturas de dados do banco, incluindo estruturas auxiliares (como rvores-B). Mas tais
estruturas podem mudar entre o tempo de compilao e o tempo de execuo. Portanto, no
caso de compilao de consultas de uma LMD, necessrio um processo de validao e, se
necessrio, recompilao antes da execuo. A estratgia de compilao no mais ser
discutida neste captulo.
Isto conclui a nossa breve introduo ao processamento de consultas centralizadas.
Tradutor1
Tradutor2
SAR
BD
comando expresso em termos
do esquema externo
comando expresso em termos
do esquema conceitual
seqncia de operaes
elementares
seqncia de acessos
fsicos
aos dados armazenados
(2)
(1)
(3)
- 3 -
4.2 CLASSIFICAO DE CONSULTAS
O processo de traduo de consultas depender de certas definies e de uma breve
classificao para consultas simples que sero introduzidas nesta seo.
A seguinte consulta sobre o banco de dados da Seo 3.2.2 ser usada como exemplo:
selec t F.NOME
from FORNECEDOR F, FORNECIMENTO FN, REGIO R
P
1
where F.NUMERO = FN.NUMERO
P
2
and (FN.CODIGO = 10 or FN.CODIGO = 12)
P
3
and FN.QUANT> 10.000
P
4
=(P
41
or P
42
) and (F.SEDE = R.ESTADO or F.SEDE = 'DF')
P
5
and R.NOME = 'CENTRO SUL'
(P
1
indicar a primeira clusula da qualificao, e assim por diante).
Seja Q uma consulta simples formulada em SQL. Seja V=(V
1
,...,V
n
) a lista de variveis de Q,
X a lista resultante de Q e B a qualificao de Q. Assumiremos que:
B est em forma normal conjuntiva, ou seja, B da forma "C
1
and ... and C
m
", onde
C
i
uma disjuno de comparaes negadas ou no.
C
i
ser chamada de uma clusula de B e uma comparao, negada ou no, ser chamada de
um literal.
Esta suposio interessante j que cada tupla da resposta da consulta Q dever satisfazer a
cada clusula de B. Em particular, a qualificao da consulta usada como exemplo est em
forma normal conjuntiva. As clusulas da qualificao so P
1
, P
2
, P
3
, P
4
e P
5
.
Uma clusula C univarivel se apenas uma varivel da consulta ocorre nos literais de C,
caso contrrio, C multivarivel. C homognea se ou for univarivel ou todos os seus
literais forem junes, ou negaes de junes, sobre as mesmas duas variveis; caso
contrrio C heterognea.
Assim, as clusulas P
2
, P
3
e P
5
so univariveis, a clusula P
1
homognea e a clusula P
4

heterognea, e ambas so multivariveis.
Estendendo as definies acima, uma conjuno de clusulas B univarivel se todas as suas
clusulas forem univariveis sobre a mesma varivel, caso contrrio B multivarivel. B
homognea se todas as suas clusulas forem homogneas e as mesmas duas variveis ocorrem
nas suas clusulas (assim, se B for homognea, poder conter clusulas univariveis e
multivariveis homogneas ao mesmo tempo).
Por exemplo, a conjuno de P
1
, P
2
e P
3
homognea, mas a conjuno de P
4
e P
5
no o
(pois P
4
heterognea).
Uma consulta simples univarivel, multivarivel, homognea, heterognea, se a sua
qualificao for univarivel, multivarivel, homognea, heterognea.
- 4 -
4.3 TRADUO PARA O ESQUEMA CONCEITUAL
Esta etapa traduz uma consulta formulada em termos de um esquema externo para uma
consulta equivalente formulada em termos do esquema conceitual. Na maior parte dos casos o
processo bastante simples, apresentando dificuldades apenas quando os esquemas usam
modelos de dados diferentes.
Aps uma anlise sinttica inicial, com o auxlio de informao contida no catlogo do
SGBD, cada referncia a uma estrutura externa substituda pela sua definio em termos das
estruturas do esquema conceitual. Em lugar de um algoritmo detalhado, apresentaremos um
exemplo ilustrando o processo.
Considere o banco de dados usado como exemplo na Seo 3.2.1, e o esquema externo usado
na Seo 3.2.4, cuja definio repetida abaixo para facilidade de referncia:
define view PRODUTO_NESTLE ( CODIGO,NOME,MELHOR_FORN )
as select P.CODIGO, P.NOME, P.MELHOR_FORN
from PRODUTO P, FORNECIMENTO F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
Considere agora a seguinte consulta sobre o esquema externo:
select CODIGO
from PRODUTO_NESTLE
where MELHOR_FORN = '41.738'
Esta consulta traduzida para o esquema conceitual substituindo-se PRODUTO_NESTLE pela
sua definio, resultando em:
selec t P.CODIGO
from PRODUTO P, FORNECIMENTO F
where F.NUMERO = '41.738'
and F.CODIGO = P.CODIGO
and P.MELHOR_FORN = '41.738'
Isto conclui a nossa breve discusso acerca da traduo de consultas sobre esquemas externos
para consultas sobre o esquema conceitual.
4.4 TRADUO PARA O ESQUEMA INTERNO
Esta seo inicia o estudo da etapa de traduo de consultas formuladas em termos do
esquema conceitual para operaes do nvel interno do SAR. Apenas o problema de se obter
uma traduo correta ser investigado, deixando a questo de otimizao para as sees
seguintes.
O problema de traduo ser dividido em duas etapas (vide Figura 4.2):
1. Desmembramento: reduz consultas sobre o esquema conceitual a uma srie de
subconsultas homogneas e operaes de unio que podem ser processadas diretamente
pelo SAR;
2. Processamento de Consultas Homogneas: seleciona seqncias de operaes do nvel
interno do SAR que resolvem diretamente consultas homogneas simples.
As subsees seguintes investigaro cada uma destas fases.
- 5 -
Figura 4.2 - Desmembramento de Consultas
4.4.1 Processamento de Consultas Homogneas
As operaes do nvel interno do SAR apresentadas na Seo 3.3 so capazes de resolver
diretamente uma consulta homognea simples e uma unio de relaes, se fizermos certas
suposies razoveis.
Em primeiro lugar, ignoraremos o problema de duplicatas, que surge da diferena entre o
conceito de tabelas do SAR, que podem conter registros duplicados, e o conceito de relaes
do modelo relacional (e, portanto, de SQL), onde a existncia de tuplas duplicadas no faz
sentido pois relaes so conjuntos. Este problema poderia ser tratado introduzindo-se uma
nova operao no SAR explicitamente para eliminar registros duplicados mas, por
simplicidade, ser abstrado neste captulo.
Em segundo lugar, assumiremos por simplicidade que o esquema interno tal que, a cada
esquema de relao R[A
1
,...,A
n
] definido no esquema conceitual, corresponder uma nica
tabela externa, cujos registros representaro tuplas da relao corrente associada a R.
Assumiremos ainda que esta tabela externa descrita pelo esquema R[IDR,A
1
,...,A
n
], onde o
tipo de dados de IDR IDR e este atributo corresponde ao campo contendo o identificador do
registro. Assim, cada tabela externa que armazena uma relao herda o seu nome e os seus
atributos.
Consideraremos consultas simples univariveis e multivariveis em separado, bem como
unies de relaes.
(A) Unies de Relaes
Dentro das suposies acima, a unio de duas relaes R e S pode ser realizada diretamente
pela operao UNIAO(T,U;V), onde T e U so as tabelas armazenando as relaes R e S.
Desmembr
Proc_Hom
consulta expressa em termos
do esquema conceitual
seqncia de subconsultas
homogneas
seqncia de operaes
elementares do SAR
- 6 -
(B) Consultas Univariveis
Seja Q uma consulta simples univarivel, R a relao varrida pela nica varivel v de Q, X a
lista de atributos de R ocorrendo na lista resultante de Q e B a qualificao de Q.
Seja T a tabela armazenando R.
Inicialmente, observemos que os literais de B so formulados em termos da varivel v e dos
atributos da relao R. No entanto, como T possui todos os atributos desta relao, por
construo, podemos criar uma expresso booleana P equivalente a B simplesmente
substituindo cada ocorrncia de v em B por T. A expresso P ser ento usada na definio
das operaes do SAR.
H duas estratgias bsicas para processar Q:
Estratgia
1
:
Uma pesquisa sequencial PESQ_SEQ(T,X,P;V) resolver Q diretamente.
T pode ser uma tabela externa, uma tabela interna ou uma tabela transiente. V ser criada
como uma tabela interna, se a sua cardinalidade for pequena, ou como uma tabela transiente
em caso contrrio. (Estimativa de cardinalidades ser discutida na Seo 4.5.4). V poder
ainda ser criada como uma tabela externa se for a resposta da consulta, ou se necessitar ser
movida para outro n, no caso de consultas distribudas.
Estratgia 2:
Suponha que haja uma tabela de inverso E sobre T em uma lista de atributos Y. Suponha que
h um conjunto P' de clusulas de P tais que todo atributo de T ocorrendo em um literal de P'
tambm ocorre em Y. Ento uma pesquisa direta PESQ_DIR(T,X,P'',E,P';V) resolver a
consulta, onde P'' a conjuno das clusulas de P que no esto em P'.
T neste caso ser necessariamente uma tabela externa, pois este o nico tipo de tabela que
nas estratgias consideradas possui inverses. V ser passada como uma tabela interna ou
uma tabela transiente, exatamente como na estratgia anterior.
guisa de ilustrao, apresentaremos aqui uma outra estratgia para processamento de
consultas univariveis. Como esta estratgia aumenta a complexidade do SAR e do
otimizador, no constar do conjunto oficial de estratgias consideradas, no entanto.
Estratgia 3:
Suponha que P possua uma coleo
de clusulas P
1
,...,P
k
tais que P
i
pode ser resolvida por uma pesquisa direta. Seja P' a
conjuno das clusulas restantes. Suponha que o SAR suporte um tipo de pesquisa direta em
T (via uma TINV U
i
) que retorne apenas a lista L
i
de identificadores dos registros de T que
satisfazem a P
i
.
- 7 -
Ento a consulta Q ser resolvida tomando-se a interseo de L
1
,...,L
k
, acessando-se apenas os
registros de T cujos identificadores esto na interseo (pois estes satisfazem
simultaneamente a P
1
,...,P
k
) e filtrando-se aqueles que no satisfizerem a P'.
Estratgias semelhantes, usando unio de listas de identificadores existem para processar
disjunes de clusulas.
(C) Consultas Homogneas Multivariveis
Seja Q uma consulta simples homognea e multivarivel. Ento h pelo menos uma clusula
da qualificao de Q onde ocorrem duas variveis. Sejam R e S as relaes varridas pelas
duas variveis de Q, X a lista de atributos de R e Y a lista de atributos de S na lista resultante
de Q, e B a qualificao de Q. Sejam T e U as tabelas armazenando R e S, respectivamente.
Como no caso anterior, seja P a expresso booleana equivalente a B mas formulada em
termos de T e U.
Consideraremos as seguintes estratgias para processar Q:
Estratgia 1:
Uma juno interativa
JUNCAO_INTERATIVA(T,U,X,Y,P(T,U),P(T),P(U);V)
resolver Q diretamente, onde P(T,U) a conjuno de todas as clusulas de P onde ocorrem
tanto T quanto U (h pelo menos uma destas clusulas), P(T) a conjuno das clusulas de P
onde ocorre apenas T, e P(U) a conjuno das clusulas de P onde ocorre apenas U (tanto
P(T) quanto P(U) podem ser vazias).
Esta estratgia se desdobra em quatro outras, dependendo da escolha de pesquisa seqencial
ou pesquisa direta para acesso a T e U.
Alm disto, a ordem das tabelas pode ser trocada, considerando-se U como o primeiro
argumento e T como o segundo argumento.
T e U podero ser tabelas externas, tabelas internas ou tabelas transientes. V ser criada como
uma tabela interna, uma tabela transiente, ou uma tabela externa.
Estratgia 2:
Suponha que P seja da forma T.K<op>U.L and B e que T e U em ordem de juno por
<op>. Ento uma juno por intercalao
JUNCAO_INTERCALACAO(T,U,X,Y,P(T,U),P(T),P(U);V)
resolver Q diretamente, onde os argumentos so como na estratgia anterior.
- 8 -
A estratgia se desdobra em outras, dependendo da escolha de pesquisa seqencial ou direta
para T, mas para U ser sempre usada pesquisa seqencial. De novo, a ordem das tabelas T e
U poder ser trocada, bem como a forma da tabela resultante V.
Estratgia 3:
Semelhante a anterior, exceto que T ou U no esto na ordem de juno . Neste caso, a juno
precedida da ordenao de T ou U (ou ambas) na ordem correta. T e U devem portanto ser
tabelas externas ou tabelas internas.
Naturalmente outras estratgias existem para processar consultas homogneas de duas
variveis, algumas usando listas de identificadores ou criao dinmica de inverses. Mas as
estratgias acima listadas sero as nicas consideradas neste texto.
4.4.2 Desmembramento de Consultas
Esta seo apresenta em linhas gerais o mtodo de desmembramento de consultas, deixando
para a seo seguinte os detalhes.
Nesta e nas prximas sees assumiremos novamente que a qualificao das consultas
simples est em forma normal conjuntiva, ou seja, que a qualificao da forma "C
1
and ...
and C
m
", onde C
i
uma disjuno de comparaes, negadas ou no. Caso a qualificao da
consulta j no esteja sob esta forma, ela dever ser transformada atravs do mtodo usual.
Uma subconsulta de uma consulta simples Q simplesmente uma consulta cuja qualificao
a conjuno de um subconjunto das clusulas da qualificao de Q e cuja lista de relaes
uma sublista da lista de relaes de Q. Uma subconsulta prpria de Q uma subconsulta de
Q cuja qualificao no idntica a de Q.
Em linhas gerais, a estratgia para processar uma dada consulta Q, formulada em SQL,
consiste em desmembrar Q em uma coleo QC de consultas homogneas simples e unies
de relaes, que podero ento ser mapeadas diretamente em operaes do SAR. O processo
de desmembramento feito atravs de duas operaes primitivas, desmembramento por
unio e desmembramento por combinao. O desmembramento por unio decompe Q em
Q
1
e Q
2
de tal forma que a relao resultante de Q idntica unio das relaes resultantes
de Q
1
e Q
2
. O desmembramento por combinao por sua vez decompe Q em Q
1
e Q
2
de tal
forma que a relao resultante de Q coincide com a relao resultante de Q
2
, que por sua vez
depende de Q
1
.
O processo de desmembrar uma consulta Q em uma coleo N de unies de relaes e
consultas homogneas cria ainda uma ordem parcial sobre N tal que, para Q e Q em N, Q
preceder Q sse Q depender do resultado de Q (ou seja, se Q tiver que ser processada
antes de Q/). O resultado do desmembramento de uma consulta Q ser ento representado
por um grafo de desmembramento G =(N,E), onde N a coleo de consultas homogneas e
unies de relaes em que Q se decompe, e (Q',Q'') est em E se Q depender do resultado
de Q. Este grafo acclico e contm um sumidouro Q
n
, que a ltima operao a ser
processada e cuja relao resultante dever coincidir com a de Q. O desmembramento ser
- 9 -
correto se a relao final produzida por Q
n
for idntica a de Q, para todo estado do banco de
dados.
A seo seguinte apresenta os algoritmos que implementam o desmembramento, enquanto
que o resto desta seo discute um exemplo de desdobramento.
Seja Q a seguinte consulta simples:
select F.NOME, P.CODIGO
into RESULTADO
from FORNECEDOR F, FORNECIMENTO FN, PRODUTO P
P
1
where P.NOME = 'BOMBOM'
P
2
and P.CODIGO = FN.CODIGO
P
3
and FN.NUMERO = F.NUMERO
P
4
and (FN.QUANTIDADE > 10000 or F.SEDE = 'SP')
Um possvel desmembramento de Q seria o seguinte. Como P
4
uma disjuno, Q pode ser
substituda equivalentemente pela unio Q
0
.
Q
0
= RESULTADO = FORN_PROD1 union FORN_PROD2
das relaes resultantes de duas consultas definidas da seguinte forma:
Q
1
= select F.NOME, P.CODIGO
into FORN_PROD1
from FORNECEDOR F, FORNECIMENTO FN, PRODUTO P
where P.NOME = 'BOMBOM'
and P.CODIGO = FN.CODIGO
and FN.NUMERO = F.NUMERO
and FN.QUANTIDADE > 10000
Q
2
= select F.NOME, P.CODIGO
into FORN_PROD2
from FORNECEDOR F, FORNECIMENTO FN, PRODUTO P
where P.NOME = 'BOMBOM'
and P.CODIGO = FN.CODIGO
and FN.NUMERO = F.NUMERO
and F.SEDE = 'SP'
O grafo de desmembramento neste ponto, portanto,
G = ({Q
0
,Q
1
,Q
2
},{(Q
1
,Q
0
),(Q
2
,Q
0
)})
indicando que Q
1
e Q
2
devero ser processadas antes da unio Q
0
.
Q
1
por sua vez pode ser decomposta em uma combinao de duas consultas, Q
3
e Q
4
:
Q
3
= select F.NOME, FP.CODIGO
into FORN_PROD1
from FORNECEDOR F, FORN_PROD3 FP
where FP.NUMERO = F.NUMERO
and FP.QUANTIDADE > 10000
- 10 -
Q
4
= select FN.NUMERO, FN.QUANTIDADE, P.CODIGO
into FORN_PROD3
from FORNECIMENTO FN, PRODUTO P
where P.NOME = 'BOMBOM'
and P.CODIGO = FN.CODIGO
importante observar que o resultado de Q
1
exatamente o mesmo de Q
3
, que depende do
resultado de Q
4
. Note ainda que FORN_PROD3, o resultado de Q
4
, contm toda informao,
originaria de FORNECIMENTO e PRODUTO, que necessria execuo de Q
3
. Para acomodar o
desmembramento de Q
1
, o grafo de desmembramento deve ser modificado para
G = ( {Q
0
, Q
2
, Q
3
, Q
4
} , { (Q
4
, Q
3
) , (Q3, Q
0
) , (Q
2
, Q
0
) } )
Similarmente Q
2
pode ser decomposta na combinao de Q
5
e Q
4
, onde
Q
5
= select F.NOME, FP.CDIGO
into FORN_PROD2
from FORNECEDOR F, FORN_PROD3 FP
where FP.NMERO = F.NMERO
and F.SEDE = 'SP'
O grafo final de desmembramento ser ento
G = ( {Q
0
, Q
3
, Q
4
, Q
5
} , { (Q
4
, Q
3
) , (Q
3
, Q
0
) , (Q
4
, Q
5
) , (Q
5
, Q
0
) } )
indicando que a primeira consulta a ser processada dever ser Q
4
, em seguida as consultas Q
3
e Q
5
devero ser processadas em qualquer ordem, e a unio Q
0
dever ser a ltima operao.
*4.4.3 Algoritmos de Desmembramento
Os algoritmos, em pseudo-cdigo, definindo as operaes de desmembramento por unio,
desmembramento por combinao e o algoritmo definindo o processo de desmembramento
completo encontram-se no final desta seo. O algoritmo de desmembramento no
determinstico e pode ser entendido como uma pesquisa arbitrria no espao de todos os
desmembramentos corretos de Q. Embora no seja imediato, pode-se provar por induo no
nmero de operaes de desmembramento por unio e por combinao que, dada uma
consulta Q, este algoritmo produz um desmembramento correto de Q.
No contexto destes algoritmos, uma operao ou a unio de duas relaes ou uma consulta
simples e sempre produzir como resultado uma relao. Na descrio destes algoritmos, uma
consulta simples ser denotada como uma qudrupla Q=(L,T,B,R) onde L a lista de relaes
de Q, T a lista resultante de Q, B a qualificao de Q e R o nome da relao resultante de
Q. Uma unio de duas relaes, R
0
=R
1
union R
2
, ser denotada por uma tripla ( R
0
,R
1
,R
2
),
onde R
0
a relao resultante e (R
1
,R
2
) a lista de relaes da operao. Diremos ainda que
uma operao O contribui para uma operao O' se o nome da relao resultante de O ocorre
na lista de relaes de O'.
Alm disto, o seguinte comando no determinstico ser usada no algoritmo de
desmembramento completo:
if P
1
s
1
... P
n
s
n
endif
- 11 -
Este comando deve ser interpretado da seguinte forma: escolha no deterministicamente uma
ramo
' P
i
s
i
' tal que a condio P
i
satisfeita e execute o comando s
i
.
Os algoritmos encontram-se abaixo.
DESMEMBRAMENTO_UNIO(Q;Q1,Q2,Q3)
/ *
entrada:
Q=(L,T,B,R) - consulta simples a ser desmembrada por unio;
B dever possuir uma clusula com mais de um literal
sada :
Q1, Q2, Q3 - subconsultas tais que o resultado de Q equivalente a unio dos
resultados de Q1 e Q2, expressa por Q3
*/
begin
selecione no deterministicamente uma clusula arbitrria C de B
com mais de um literal;
particione no deterministicamente C em duas disjunes C1 e C2
tais que cada uma tem pelo menos um literal;
esc olha nomes de relao temporrias no utilizados at o momento e
coloque-os em R0, R1 e R2;
B' := conjuno das clusulas em B, exceto as em C;
Q1 := (L,T,C1 & B',R1);
Q2 := (L,T,C2 & B',R2);
Q3 := (R0,R1,R2); / * unio de R1 e R2 */
end
DESMEMBRAMENTO_COMBINAO(Q;Q1,Q2)
/ *
entrada: Q - consulta simples a ser desmembrada por combinao ;
B dever possuir mais de uma clusula
sada : Q1, Q2 - subconsultas tais que o resultado de Q equivalente
a executar Q1 e depois Q2
*/
begin
partic ione no deterministicamente B em duas conjunes B' e B"
tais que B' e B" possuem pelo menos uma clusula;
esc olha nomes de relaes temporrias no utilizados at o momento e
coloque-os em R1 e R2;
L1 := sublista de L contendo todos os pares 'R r' tais que r ocorre em B';
T1 := lista de todos os atributos qualificados A.r que ocorrem em Tou B"
e tais que r uma varivel ocorrendo em L1;
B1 := B';
L2 := sublista de L contendo todos os pares 'R r' que no ocorrem em L1,
mais o par 'R1 R1';
T2 := lista resultante Tonde cada atributo qualificado A.r tal que
r uma varivel em L1 foi substituido por A.R1;
B2 := conjuno B" onde cada atributo qualificado A.r tal que
r uma varivel em L1 foi substituido por A.R1;
Q1 := (L1,T1,B1,R1);
Q2 := (L2,T2,B2,R2);
end
- 12 -
DESMEMBRAMENTO(Q;G)
/ *
entrada: Q - consulta a ser desmembrada
sada : G=(N,E) - um grafo de desmembramento para Q
*/
begin
if Q uma consulta simples
then N := {Q}; E := ;
else begin / * Q uma c onsulta-unio */
suponha que Q seja a unio de Q1 e Q2,
onde Q1=(L1,T1,B1,R1) e Q2=(L2,T2,B2,R2);
seja R0 um novo nome de relao ;
P := (R0,R1,R2);
N := {P,Q1,Q2};
E := {(Q1,P),(Q2,P)}
end
enquanto houver uma consulta simples no homognea em N faa:
begin
selecione uma consulta P no homognea em N;
if
h uma clusula na qualificao de P com mais de um literal
begin
DESMEMBRAMENTO_UNIO(P,Q1,Q2,Q3);
acrescente Q1, Q2, Q3 a N;
remova P de N;
acrescente (Q1,Q3) e (Q2,Q3) a E;
foreach (P,Q') em E do
begin remova (P,Q') de E;
acrescente (Q3,Q') a E;
end
end
/ /
h mais de uma clusula na qualificao de P
begin
DESMEMBRAMENTO_COMBINAO(Q,Q1,Q2);
acrescente Q1 e Q2 a N;
remova P de N;
acrescente (Q1,Q2) a E;
foreach (P,Q') em E do
begin remova (P,Q') de E;
acrescente (Q2,Q') a E;
end
end
endif
foreach (Q',P) em E do
begin remova (Q',P) de E;
if Q' contribui para Q1 then acrescente (Q',Q1) a E;
if Q' contribui para Q2 then acrescente (Q',Q2) a E;
end
end
end
- 13 -
4.4.4 Descrio Final da Soluo
Seja Q uma consulta. O grafo de desmembramento G=(N,E) resultante do processo de
desmembrar Q indica uma coleo (N) de consultas homogneas e unio de relaes capazes
de produzir o resultado da consulta, e a ordem (parcial) em que as consultas e unies devero
ser processadas (pois G, por construo, e acclico).
O objetivo final, porm, obter uma seqncia S de operaes do nvel interno do SAR que
resulte em uma tabela contendo o resultado de Q. Mas este passo final simples, e consiste
de:
1. Substitua cada operao O em N por uma seqncia S(O) de operaes (ou por apenas
uma operao ) do nvel interno do SAR de acordo com as estratgias discutidas na Seo
4.4.1.
2. Produza uma ordem linear S das operaes em N compatvel com a ordem parcial
representada por G.
3. S ser ento a seqncia procurada.
Note que S representa um programa sequencial. Se, por outro lado, for possvel execuo
concorrente de operaes, o grafo G indicar ento como as operaes podero ser
despachadas.
4.5 OTIMIZAO
O algoritmo de desmembramento conforme apresentado na seo anterior, produz uma
desmembramento correto de uma consulta. No entanto, o desmembramento obtido
completamente arbitrrio, e no leva em considerao a estrutura da qualificao da consulta
e informao acerca da cardinalidade das tabelas, inverses existentes e, principalmente, as
estratgias para processar uma consulta homognea. Por outro lado, o algoritmo tem o mrito
de definir de forma concisa o espao de todos os desmembramentos corretos para uma
consulta.
O problema imediatamente seguinte consiste, ento, em construir um desmembramento
correto para uma consulta e escolher uma estratgia de processamento para cada consulta
homognea do desmembramento de tal forma a minimizar uma dada funo de custo. Este
essencialmente um problema combinatorial de otimizao e como tal ser tratado. A primeira
soluo a ser discutida consiste em uma pesquisa exaustiva no espao de todas as solues
possveis para localizar a de menor custo. Uma segunda soluo ser em seguida apresentada
baseando-se em uma heurstica para limitar a pesquisa. Por fim, o problema de estimar o
custo de uma soluo, que por si s interessante, ser abordado.
4.5.1 Pesquisa Exaustiva da Soluo tima
A forma mais simples de otimizar uma consulta resume-se a uma pesquisa exaustiva no
espao de todas as possveis solues do problema para localizar a de menor custo. Uma
soluo neste contexto pode ser descrita em dois nveis: um desmembramento correto da
- 14 -
consulta e, para cada operao (consulta homognea ou unio de relaes) resultante do
desmembramento, uma estratgia para processamento da operao. Resumidamente, este
procedimento consiste, ento, de:
1. enumerar todos os possveis desmembramentos de uma consulta (primeiro nvel da
busca);
2. para cada desmembramento possvel, enumerar todas as possveis estratgias para
processar cada consulta homognea ou unio de relaes gerada pelo desmembramento
(segundo nvel da busca);
3. estimar o custo de cada soluo;
4. escolher a soluo de menor custo.
Dada a natureza do problema, tcnicas de "branch-and-bound" ou "backtracking" com
funes limitantes aplicam-se na pesquisa da soluo tima.
4.5.2 Desmembramento Controlado - Parte I
O nmero total de possveis formas de processar uma consulta cresce exponencialmente com
o nmero de clusulas da qualificao. Uma pesquisa exaustiva para selecionar a melhor
soluo pode ento se tornar proibitiva, especialmente para consultas imediatas que no sero
repetidas novamente. interessante definir portanto uma heurstica que limite a busca da
soluo tima.
Por outro lado, tal heurstica deve produzir uma soluo que, embora possa no ser tima,
pelo menos seja razovel.
Descartaremos como "no razovel" qualquer soluo que leve desnecessariamente a um
crescimento exponencial dos resultados intermedirios. Tal situao conseqncia da
formao implcita do produto cartesiano de vrias relaes (que em certos casos, porm,
exigido para resolver um conjunto de clusulas homogneas de duas variveis). Esta posio
justifica-se pois o custo de processar uma consulta e o seu tempo de resposta esto
diretamente ligados ao tamanho dos resultados intermedirios.
Nesta seo ser apresentada ento uma heurstica que, baseada em uma anlise da
qualificao da consulta, procura uma soluo que evita o crescimento exponencial
desnecessrio dos resultados intermedirios e, ao mesmo tempo, evita uma pesquisa exaustiva
de todas as formas possveis de processar a consulta. Chamaremos esta heurstica de
desmembramento controlado. Ela se processa da seguinte forma:
1. desmembre a consulta original em suas componentes irredutveis (que levam
necessariamente formao de produtos cartesianos implcitos);
2. ordene as componentes irredutveis de tal forma que as componentes correspondendo a
subconsultas homogneas sejam executadas primeiro e a componente contendo a lista
resultante por ltimo (isto reduz o tamanho dos resultados intermedirios);
3. otimize o processamento de cada componente irredutvel em separado, ignorando as
outras componentes. (Como as componentes so mais simples do que a consulta original,
exceto se a consulta j for irredutvel, o problema de otimiz-las mais simples que o
- 15 -
problema de otimizao global. Por outro lado, no convm otimizar uma consulta mais
simples do que uma componente irredutvel pois corre-se o risco de produzir resultados
intermedirios muito maiores do que o necessrio).
Para avaliar o efeito do desmembramento controlado, considere o seguinte exemplo. Seja Q a
consulta abaixo sobre o banco de dados da Seo 3.2.1:
select P.MELHOR_FORN, P.NOME, FN.QUANTIDADE
from FORNECEDOR F, FORNECIMENTO FN, PRODUTO P, REGIO R
P
1
where R.NOME = 'CENTRO-SUL'
P
2
and F.SEDE = R.ESTADO
P
3
and P.MELHOR_FORN = F.NOME
P
4
and P.CODIGO = FN.CODIGO
P
5
and F.NUMERO = FN.NUMERO
(Quais os nomes dos fornecedores, os nomes dos produtos e as quantidades fornecidas tais
que o fornecedor est sediado em um estado da regio Centro-Sul, fornece o produto e
considerado o melhor fornecedor do produto).
Esta consulta interessante pois possui quatro clusulas de duas variveis (P
2
a P
5
). No
entanto, h certas diferenas fundamentais em como estas clusulas podem ser tratadas. Em
primeiro lugar, a clusula P
2
, juntamente com P
1
, age no sentido de restringir a relao
FORNECEDOR.Alm disto, apenas a varivel F varrendo FORNECEDOR existe em comum entre
P
2
e P
3
, P
4
e P
5
. Logo possvel otimizar a subconsulta gerada por P
1
e P
2
em separado sem
correr o risco de criar um resultado intermedirio demasiadamente grande. O seu resultado
ser necessariamente um subconjunto de FORNECEDOR e conter toda informao necessria
ao resto da consulta.
Por outro lado, as trs ltimas clusulas, P
3
, P
4
e P
5
, formam uma componente irredutvel no
sentido de que, para resolver uma destas clusulas, necessrio fazer uma juno de duas
relaes e manter informao sobre ambas para resolver as outras clusulas e criar o resultado
da consulta. Ou seja, no possvel reduzir o seu processamento a subconsultas
independentes mais simples. Por exemplo, se for feita a juno de FORNECEDOR com
PRODUTO para resolver P
3
, necessrio manter CODIGO de PRODUTO e NUMERO de
FORNECEDOR para que possam ser resolvidas as clusulas P
4
e P
5
. Alm disto, preciso
manter NOME e MELHOR_FORN de PRODUTO para criao das tuplas resultantes. Estes blocos
de clusulas criam resultados intermedirios potencialmente explosivos e devem ser
otimizados exaustivamente.
Em resumo, uma boa estratgia para processar Q consiste em
1. desmembrar Q em Q
1
e Q
2
, que so geradas pelos conjuntos de clusulas {P
1
,P
2
} e
{P
3
,P
4
,P
5
}, respectivamente;
2. otimizar Q
1
e Q
2
separadamente, obtendo o desmembramento timo destas subconsultas
por pesquisa exustiva.
Desta forma estaremos reduzindo o trabalho de otimizao pois Q
1
e Q
2
so mais simples do
que Q. Por outro lado, como Q
1
e Q
2
s tem uma varivel em comum (a varivel F), no h
perigo de gerarmos um resultado intermedirio desnecessariamente grande.
Estas observaes formam a base intuitiva do desmembramento controlado.
- 16 -
*4.5.3 Desmembramento Controlado - Parte II
Para tornar a discusso sobre desmembramento controlado mais precisa necessitamos das
seguintes definies. Seja Q uma consulta. Q disconexa se a sua qualificao puder ser
particionada em duas conjunes de clusulas sem nenhuma varivel em comum. Q conexa
se no for disconexa. Se Q for disconexa, possvel desmembr-la em duas subconsultas, Q
1
e Q
2
, sem nenhuma varivel em comum. Assim, Q
2
totalmente independente de Q
1
, embora
ambas sejam necessrias pois se um dos resultados for vazio, assim ser o de Q. Uma
varivel de juno de Q uma varivel v tal que a qualificao de Q pode ser particionada em
duas conjunes de clusulas com apenas v em comum. Neste caso, Q pode ser desmembrada
na composio de uma subconsulta Q
1
com uma subconsulta Q
2
tais que Q
1
e Q
2
tm
apenas a varivel v em comum. Uma consulta Q irredutvel se for conexa e no possuir uma
varivel de juno.
Uma subconsulta Q de Q gerada por um subconjunto B'={C
1
,..., C
n
} das clusulas da
qualificao de Q se a qualificao de Q for a conjuno das clusulas em B'. Uma consulta
Q uma subconsulta ou componente irredutvel de Q se Q for uma subconsulta de Q, Q for
irredutvel e no existir uma subconsulta Q de Q tal que Q irredutvel e Q uma
subconsulta prpria de Q''. Uma subconsulta irredutvel possui uma qualificao cujas
clusulas formam um bloco semelhante quele formado por P
3
, P
4
e P
5
no exemplo da
seo anterior.
Voltemos agora ao desmembramento controlado. A heurstica em questo prope
desmembrar uma consulta em subconsultas irredutveis, inicialmente, ignorando as
subconsultas univariveis que sempre sero incorporadas a outras. O grafo de
desmembramento, T, ser uma floresta aps este desmembramento inicial pois, caso
contrrio, uma das consultas no seria irredutvel (o leitor deve se convencer deste ponto
usando a definio de subconsulta irredutvel, ou ler a caracterizao mais precisa da
heurstica apresentada abaixo).
Em seguida T percorrida das folhas para as razes. Para cada subconsulta Q visitada, se Q
no for homognea, um desmembramento timo obtido por pesquisa exautiva. Q ento
substituda pelo grafo de desmembramento resultante do processo. O resultado final um
desmembramento de Q em subconsultas homogneas.
Como pode haver mais de uma possvel ordenao das componentes irredutveis sob forma
de uma floresta T para uma dada consulta, a heurstica prope ainda escolher uma que force
subconsultas homogneas a serem processadas primeiro, e deixe a componente que contm a
lista resultante para o fim.
A consulta tomada como exemplo na seo anterior conexa e possui uma varivel de
juno, F. O desmembramento inicial de Q em componentes irredutveis resulta em trs
consultas Q
11
, Q
12
e Q
2
, geradas pelos conjuntos de clusulas {P
1
}, {P
2
}, e {P
3
,P
4
,P
5
},
respectivamente. Como Q
11
univarivel, a heurstica dita incorpor-la a Q
12
, obtendo a
consulta Q
1
. Ou seja, obtemos as mesmas subconsultas de Q encontradas no exemplo da
seo anterior. Como Q
1
homognea e, alm disto, Q
2
contm a lista resultante, a heurstica
recomenda processar Q
1
antes de Q
2
. Isto significa que o desmembramento inicial uma
rvore cujos ns so Q
1
e Q
2
e tal que Q
2
o pai de Q
1
.
- 17 -
O prximo passo da heurstica otimizar Q
1
e Q
2
em separado. Como Q
1
homognea, no
necessrio desmembr-la. Mas para Q
2
necessrio obter um desmembramento timo por
pesquisa exaustiva. Digamos que o resultado seja um desmembramento de Q
2
na combinao
de Q
22
com Q
23
, onde Q
22
e Q
23
so geradas pelos conjuntos de clusulas {P
3
} e {P
4
, P
5
}.
O grafo final de desdobramento seria ento uma rvore com trs ns, Q
1
, Q
22
e Q
23
, onde
Q
23
a raz, Q
22
o filho de Q
23
e Q
1
o filho de Q
22
.
A anlise da qualificao da consulta necessria heurstica pode ser feita representando-se a
qualificao da consulta atravs de um hipergrafo. Um hipergrafo um par ordenado H =
(N,E) onde N um conjunto no vazio de ns e E um conjunto de subconjuntos finitos de
ns, chamados de hiper-arestas. No caso de todos os conjuntos em E conterem exatamente
dois ns, o hipergrafo se reduz a um grafo no-dirigido. As noes de caminho, componente
biconexa e ponto de articulao em hipergrafos so definidas como para grafos. (Se o leitor
assim o desejar, poder raciocinar em termos de grafos no que se segue. O exemplo adotado
no necessita da generalidade de hipergrafos para ser analisado).
O hipergrafo H(Q) = (N,E) de uma consulta Q construdo a partir da qualificao e da lista
resultante da seguinte forma: o conjunto de ns N consiste de todas as variveis da consulta;
para cada clusula C da qualificao (ou lista resultante T) acrescente a E, se j no houver,
uma hiper-aresta consistindo de todas as variveis ocorrendo em C (ou em T).
possvel mostrar que as subconsultas irredutveis da consulta so geradas pelas clusulas
correspondendo s hiper-arestas das componentes biconexas do hipergrafo da consulta e as
variveis de juno da consulta so os pontos de articulao do hipergrafo. Portanto, para se
determinar as subconsultas irredutveis da consulta, basta se determinar as componentes
biconexas do grafo (ou os seus pontos de articulao).
E = {{R},{F,R},{P,F},{P,FN},{F,PN}}
Note que a hiper-aresta {P,FN} representa tanto a lista resultante quanto a clusula P
4
.
A heurstica apresentada de forma mais precisa atravs do algoritmo (em pseudo-cdigo)
DESMEMBRAMENTO_CONTROLADO. Este algoritmo usa um outro, REDUO, que determina
as subconsultas irredutveis da consulta e as ordena de forma apropriada, combinando as
subconsultas irredutveis univariveis com outras. Estes algoritmos so apresentados a seguir.
DESMEMBRAMENTO_CONTROLADO(Q;G)
/ *
entrada: Q uma consulta a ser desmembrada
sada : G um desmembramento correto e otimizado de Q
*/
begin
/ *
criao de um desmembramento parcial G de Q em subconsultas irredutveis,
onde as subconsultas univariveis foram incorporadas a outras.
G ser sempre uma floresta.
*/
REDUO(Q;G);
- 18 -
/ *
substituio de cada subconsulta irredutvel Q' em G por um desmembramento de Q',
produzindo o desmembramento final
*/
foreach n P de G em ordem ps-fixa tal que P no homognea do
begin
ache o desmembramento timo de P por pesquisa exaustiva;
faa G' igual ao grafo do desmembramento;
faa Q' igual operao final de G';
/ *
substitua P por G' em G
*/
G := G union G';
foreach (P',P) em G do
begin remova (P',P) de G;
foreach P" em G' do
if P' contribui para P"
then adicione (P',P"') a G;
end
foreach (P,P') em G do
begin remova (P,P') de G;
adicione (Q',P') a G;
end
remova P de G;
end
end
REDUO(Q;G)
/ *
entrada: uma consulta Q
sada : um desmembramento G de Q em subconsultas irredutveis onde as subconsultas
univariveis foram incorporadas a outras; G ser sempre uma floresta.
*/
begin
PRE_ORDENAO(Q;F);
TRANSFORMAO1(F;G);
TRANSFORMAO2(G);
end
PRE_ORDENAO(Q;F)
/ *
pre-ordenao das componentes biconexas de H(Q)
entrada: consulta Q
sada : floresta rotulada F=(M,B,r) onde cada n n rotulado com um conjunto de
clusulas de Q
*/
begin
/ *
organizao das componentes em um grafo
*/
construa o hipergrafo H(Q) de Q;
determine as componentes biconexas de H(Q);
construa um grafo rotulado no dirigido H=(M,A,r) tal que
(1) para cada componente biconexa C de H(Q) existe um n n de H
(diz-se que C gera n);
(2) r(n) o conj. de clusulas ou lista resultante de Q correspondendo s arestas de C;
(3) (n,m) A se e somente se as c omponentes C e D
que geram n e m tem um ponto de articulao em comum.
- 19 -
/ *
ordenao das componentes em uma floresta
*/
construa uma floresta rotulada F=(M,B,r) tal que:
(1) F uma floresta geradora de H (logo M e r so herdados de H);
(2) o n n cujo rtulo contm a lista resultante uma raz de F;
(3) os ns rotulados com apenas uma clusula univarivel so sempre folhas;
(4) os ns rotulados com um conjunto de clusulas homogneas devem estar o mais
prximo possvel das folhas.
/ *
c ompactao das componentes univariveis
*/
foreach folha n de F do
if n rotulada com apenas uma clusula univarivel
then begin
acrescente a clusula ao conjunto que rotula o pai de n em F;
remova n de F
end
end
TRANSFORMAO1(F;G)
/ *
Criao de um desmembramento parcial de Q - Fase I
entrada: floresta F=(M,B,r) rotulada com conjuntos de clusulas
sada : floresta G=(N,E) representando um desmembramento parcial de Q
*/
begin N=; E=;
/ *
c ria o das subconsultas do desmembramento parcial a menos das listas resultantes
*/
foreach n n de F em pr-ordem do
begin
gere a partir de n uma consulta P da seguinte forma:
(a) a relao resultante de P um novo nome de relao;
(b) a qualificao B de P a conjuno das clusulas que rotulam n;
(c) a lista de relaes de P contm todas as variveis referenciadas em B
junto com as relaes que elas varrem;
(d) a lista resultante de P coincide com a de Q,
se o rotulo de n contiver a lista resultante de Q;
caso contrrio, a lista resultante de P permanece indefinida.
adicione P a N;
if n' o pai de n em F e P' a consulta gerada por n'
then adicione o arco (P,P') a E;
end
end
TRANSFORMAO2(G)
/ *
Criao de um desmembramento parcial de Q - Fase II
entrada e sada : floresta G=(N,E) representando um desmembramento parcial de Q
*/
begin
/ *
criao do desmembramento parcial final
*/
- 20 -
foreach consulta P de G em ps-ordem do
begin
/ *
criao da lista resultante final
*/
acrescente a lista resultante de P cada atributo de cada relao varrida em P
que referenciada em um ancestral de P em G;
/ *
modificao dos ancestrais de P em G para que G
seja um desmembramento c orreto
*/
foreach ancestral P' de P em G do
begin / *
substitua as relaes varridas em P pela relao resultante de P
*/
elimine todos os pares 'R r' da lista resultante de P' onde R uma das
tabelas varridas em P;
adicione um par 'RP p' onde RP a relao resultante de P;
/ *
modifique a qualificao de P para
refletir mudanas na lista resultante
*/
substitua todas as ocorrncias de atributos qualificados 'r.A',
onde r foi eliminada, por 'p.A'
end;
end;
end
*4.5.4 Estimativa de Custo
Independentemente do mtodo de otimizao usado, pesquisa exaustiva ou pesquisa guiada
por uma heurstica, necessrio estimar o custo de cada possvel estratgia para processar
uma consulta. A estimativa de custo pode ser reduzida a duas tarefas bsicas:
1. estimar o custo das operaes do SAR usadas para processar consultas homogneas e
unies de relaes;
2. estimar como o resultado de uma consulta ou unio afeta o custo das consultas ou unies
posteriores no desmembramento.
De fato, lembremos que uma estratgia compe-se de um desmembramento da consulta
seguido da especificao de um mtodo para processar cada consulta homognea e unio de
relaes do desmembramento. Logo, o custo de uma estratgia , ento, a somatria dos
custos das consultas homogneas e unies em que resulta o desmembramento, o que nos leva
primeira tarefa. Alm disto, uma consulta ou unio poder usar o resultado de outra, o que
implica por sua vez na segunda tarefa.
Discutiremos cada um destes problemas em separado no que se segue.
Assumiremos que o esquema interno definido de forma simples, ou seja, que cada relao
armazenada em uma tabela externa diferente, que por sua vez ocupa um segmento distinto.
- 21 -
Assumiremos ainda que as seguintes estatsticas sobre o banco de dados so mantidas pelo
sistema:
para cada tabela externa T:
CAR(T) - nmero de registros de T;
PAG(T) - nmero de pginas ocupados por T;
para cada atributo A de T:
CMX(T,A) - comprimento mximo do campo correspondente a A em T;
CMN(T,A) - comprimento mnimo do campo correspondente a A em T;
MAX(T,A) - maior valor de T[A] ocorrendo no banco, se o domnio de A for aritmtico;
MIN(T,A) - menor valor de T[A] ocorrendo no banco, se o domnio de A for aritmtico;
para cada tabela de inverso U:
CHV(U) - nmero de chaves distintas em U;
PAG(U) - nmero de pginas contendo chaves em U;
Estas estatsticas so mantidas no catlago do sistema junto com a definio do banco e, para
no sobrecarregar o sistema, so atualizadas de forma peridica.
(A) Influncia do Resultado de uma Operao sobre Outra
Seja Q uma consulta ou unio de relaes. Suponhamos que a relao resultante de Q seja
armazenada em uma tabela T. Como T poder ser varrida em outras consultas, desejamos
estimar as estatsticas de T para que seja possvel tratar T como qualquer outra tabela do
banco de dados.
Se Q uma unio de relaes, a estimativa das estatsticas simples e no ser discutida.
Portanto assuma que Q uma consulta simples. (A discusso a seguir se aplica a qualquer
consulta simples, embora no necessitemos destes resultados para consultas homogneas).
Inicialmente, observemos que MAX(T,A), MIN(T,A), CMX(T,A), CMN(T,A) so facilmente
computados a partir destes mesmos parmetros mantidos para as tabelas de dados do banco e
a partir da qualificao da consulta (apenas necessria para MAX(T,A) e MIN(T,A), pois pode
haver comparaes na qualificao limitando estes parmetros). Da mesma forma, PAG(T)
facilmente estimado conhecendo-se CAR(T). De fato, como so conhecidos os comprimentos
dos campos de cada atributo de cada tabela do banco, sempre possvel estimar os
comprimentos mximo e mnimo, CMAX e CMIN, dos registros de T (se os campos forem de
comprimento fixo, CMAX = CMIN, naturalmente). Logo, conhecendo-se o comprimento das
pginas, CPAG, teremos:
CAR(T) * CMIN / CPAG < PAG(T) < CAR(T) * CMAX / CPAG
Portanto, ficamos reduzidos estimao de CAR(T).
Sejam r
1
... r
n
as variveis de Q e U
1
... U
n
as tabelas varridas por r
1
... r
n
. Seja T a tabela
resultante de Q e B a qualificao de Q. Ento, por definio, T ser o subconjunto do produto
cartesiano U = U
1
U
n
definido por B. Seja F(B) o fator de seletividade de B, ou seja, a
percentagem de tuplas de U que satisfazem B. Ento temos que
- 22 -
CAR(T) = CAR(U
1
) CAR(Un) F(B)
Basta portanto estimar F(B). No entanto, uma estimativa precisa de F(B) requer um estudo
minucioso que est alm do escopo desta seo. Estimativas imediatas, que mostraram ser
eficazes em um sistema real, so descritas abaixo por tipo de clusula (i e j varrem o intervalo
[1,n]):
B do tipo r
i
.A = "valor"
F(B) = 1 / CHV(V), se existe uma tabela de inverso V invertendo U
i
por A (assume-se
uma distribuio uniforme de tuplas pelos valores de chave).
F(B) = 1/10, em caso contrrio.
Nota: No h qualquer significado maior na escolha de 1/10, exceto a hiptese de que
dificilmente uma consulta selecionar mais do que 1/10 das tuplas de uma relao.
B do tipo r
i
.A > "valor" (e semelhantemente para outras comparaes, exceto igualdade)
F(B) = (MAX(U
i
, A ) - "valor" )/(MAX(U
i
, A) - MIN(U
i
, A))
F(B) obtido por interpolao linear do valor no intervalo de valores existentes,
se o domnio de A for aritmtico;
F(B) = 1/10, se o domnio de A no for aritmtico;
B do tipo r
i
.A = r
j
.B
F(B) = 1 / MAX(CHV(V
1
),CHV(V
2
)),
se existem tabelas de inverso V
1
e V
2
invertendo U
I
por A e U
j
por B,
respectivamente (assume-se que cada valor de chave na tabela de inverso com menor
cardinalidade ocorre tambm na tabela de maior cardinalidade).
F(B) = 1 / CHV(V),
se existe uma tabela de inverso V invertendo U
I
por A ou U
j
por B.
F(B) = 1/10, em caso contrrio
B do tipo r
i
.A > r
j
.B (e semelhantemente para outras comparaes, exceto igualdade)
F(B) = (MAX(U
i
, A) - MIN(U
j
, B))/(MAX(U
i
, A) - MIN(U
i
, A)),
se o domnio de A for aritmtico;
F(B) = 1/10, se o domnio de A no for aritmtico;
B = B
1
OR B
2
.
F(B) = F(B
1
) + F(B
2
) - F(B
1
) * F(B
2
)
B = B
1
AND B
2
F(B) = F(B
1
) * F(B
2
) (Assume-se independncia de eventos neste caso).
B = B
1
F(B) = 1 - F(B
1
)
- 23 -
(B) Estimativa do Custo de Processar Consultas Homogneas e Unies de Relaes
Estimar o custo de processar consultas homogneas e unies de relaes degenera na
estimativa do custo das operaes do SAR, tendo em vista as estratgias apresentadas na
Seo 4.4.1 para tratamento de consultas homogneas e unies de relaes. Portanto esta
subseo se atm ao problema de estimar o custo das operaes do SAR.
A equao de custo para uma operao genrica P ter sempre o seguinte formato:
C(P) = nmero de pginas lidas para obter os operandos
+ nmero de pginas gravadas para produzir o resultado
+ W * tempo de CPU gasto para produzir tuplas do resultado
onde W um fator de ponderao entre tempo de CPU e atividade de leitura/gravao de
pginas. O tempo de CPU em todos os casos ser uma funo de uma cardinalidade
facilmente estimada a partir dos resultados da parte (A) desta seo. O nmero de pginas
lidas ou gravadas depende da forma como os argumentos so passados ou o resultado
gerado. Se for atravs de uma tabela de dados, este nmero ser estimado a partir do nmero
de pginas ocupadas pela tabela; se for atravs da uma tabela interna ou de uma tabela
transiente, ento este nmero ser zero.
As seguintes observaes simplificaro a apresentao das equaes. Em primeiro lugar, para
cada operao seria necessrio apresentar uma equao diferente para cada combinao
possvel de opo de passagem de argumentos e gerao do resultado. Isto pode ser evitado,
no entanto, definindo-se simplesmente um novo parmetro, PAG'(T), da seguinte forma:
PAG'(T) = PAG(T) , se T for passada ou gerada como uma tabela de dados
= 0 , caso contrrio
Em certos casos ser necessrio estimar PAG(T), mas nos limitaremos a estimar CAR(T) a
partir de fatores de seletividade, j que PAG(T) pode ser computado de CAR(V) e de outros
parmetros, conforme a discusso da parte (A).
1) ORD(T,X,tipo;V)
Intuitivamente, o custo desta operao ser:
C = nmero de pginas de T lidas
+ nmero de pginas de V gravadas
+ nmero de pginas lidas e gravadas para ordenao
+ W * tempo de CPU para ordenao
Assuma que T uma tabela de dados e que o algoritmo de ordenao externa por intercalao
("external sort-merge") usado. Assuma ainda que a intercalao envolve trs arquivos de
cada vez e que o tempo de CPU da ordenao desprezvel em presena do tempo de entrada
e sada.
Como V = T, as duas primeiras parcelas do lado direito da equao de custo anterior so
iguais. A terceira parcela dada pelo nmero de pginas lidas egravadas pelo algoritmo de
- 24 -
ordenao (veja qualquer livro de estruturas de dados). A quarta parcela nula em vista das
suposies anteriores.
Logo, teremos ento:
C = 2 * PAG(T) + 2 * PAG(T) * log(PAG(T))
onde log tomado na base 3 em vista das suposies.
Assuma agora que T est em memria principal (logo o custo de l-la nulo), mas que V
poder ou no ser gerada em memria principal. Assuma que nestas condies a ordenao
feita em memria principal. O custo ser ento:
C = 2 * PAG'(V) + W * CAR(T) * log(CAR(T))
onde W uma constante de proporcionalidade entre tempo de CPU (para ordenao) e tempo
de gravao (se V for gerada em memria secundria).
2) UNIO(T,U;V)
O custo ser:
C = nmero de pginas de T lidas
+ nmero de pginas de U lidas
+ nmero de pginas de V gravadas
= PAG'(T) + PAG'(U) + PAG'(V)
onde PAG'(V) obtido de PAG(V), que por sua vez simplesmente:
PAG(V) = PAG(T) + PAG(U)
3) PESQ_SEG(T,X,P(T);V)
O custo ser:
C = nmero de pginas de T lidas
+ nmero de pginas de V gravadas
+ W * nmero de tuplas de T processadas
= PAG'(T) + PAG'(V) + W * CAR(T)
onde usamos CAR(V) para computar PAG'(V), obtido como:
CAR(V) = CAR(T) * F(P(T))
4) PESQ_DIR(T,X,P(T),U,Q(T);V)
H duas situaes a considerar:
- 25 -
(i) U inverte T por Y, mas as tuplas de T no esto agrupadas por valor de Y.
O custo da operao ser ento:
C = nmero de pginas de T lidas
+ nmero de pginas de U lidas
+ nmero de pginas de V gravadas
+ W * nmero de tuplas de T processadas
Na situao considerada aqui, assumiremos que cada tupla de T requer a leitura de uma
pgina. Logo, o nmero de pginas de T lidas igual ao nmero de tuplas de T que satisfazem
a Q(T), que tambm coincide com o nmero de tuplas de T processadas. Assumiremos ainda
que a estrutura de acesso direto tal que para se determinar que chaves satisfazem Q(T)
necessrio acessar no mximo PAG(U). Esta uma estimativa muito conservativa, mas para
melhor-la necessitaramos assumir uma particular estrutura para U, o que no fizemos.
Finalmente, observamos que V conter todas as tuplas de T que satisfazem a P(T) AND Q(T).
Logo, teremos:
CAR(V) = CAR(T) * F(P(T) AND Q(T))
Lembrando que PAG'(V) computado de CAR(V), a equao de custo ser:
C = CAR(T) * F(Q(T))
+ CAR(U) * F(Q(T))
+ PAG'(V)
+ W * CAR(T) * F(Q(T))
Finalmente, note que como estamos usando uma inverso, tanto T quanto U devem ser tabelas
permanentes do banco, logo so acessadas diretamente de memria secundria, e no podem
ser recebidas como tabelas internas ou transientes.
(ii) U inverte T por Y e as tuplas de T esto agrupadas por valor de Y.
A diferena para o caso anterior est na estimativa do nmero de pginas de T lidas, que neste
caso feito da seguinte forma:
N = (CAR(T) * tamanho das tuplas de T) / tamanho da pgina
O resto da equao permanece o mesmo.
5) JUNO_INTERATIVA(T,U,X,Y,P(T,U),P(T),P(U);V)
Recordemos que uma juno interativa pode ser feita de quatro formas diferentes,
dependendo do tipo de pesquisa, seqencial ou direta, usado para acessar T e U. Lembremos
ainda que o resultado destas pesquisas sempre passado tupla-a-tupla neste algoritmo, no
incorrendo portanto em pginas sendo gravadas. Como os custos destas pesquisas j foram
discutidos acima, usaremos CPESQ(T,P(T)) para representar o custo da pesquisa em T usando
a qualificao P(T) e CPESQ(U,P(U) AND Q(U)) para representar o custo da pesquisa em U
usando a qualificao P(U) e a qualificao Q(U) resultante da substituio de T por uma
- 26 -
tupla T em P(T,U) (este custo na verdade ser independente da tupla T em questo dada a
forma como estimamos o fator de seletividade). Assim a equao de custo para juno
interativa se reduz a:
C = custo da pesquisa em T
+ (nmero de tuplas que satisfazem P(T) * custo da pesquisa em U)
+ nmero de pginas de V gravadas
ou seja,
C = CPESQ(T,P(T))
+ CAR(T) * F(P(T)) * CPESQ(U,P(U) AND Q(U))
+ PAG'(V)
onde PAG'(V) obtido a partir de CAR(V), estimado como:
CAR(V) = CAR(T) * CAR(U) * F(P(T,U) AND P(T) AND P(U))
6) JUNO_INTERCALAO(T,U,X,Y,P(T,U),P(T),P(U);V)
Seja T o registro lido de T e t' o registro anterior. Lembremos que, ao se processar T, U
pesquisada a partir do primeiro registro que foi usado para processar t'. Assumiremos que os
registro lidos de U so mantidos em reas de trabalho em memria principal enquanto forem
necessrios. Assim, U s pesquisada uma vez. Portanto, usando a notao da situao
anterior, teremos:
C = CPESQ(T,P(T))
+ CPESQ(U,P(U) AND Q(U))
+ PAG'(V)
4.6 PROCESSAMENTO DE ATUALIZAES
Esta seo discute brevemente o problema de processar atualizaes em bancos de dados
centralizados usando novamente SQL como a linguagem de manipulao de dados.
Comecemos com remoes da forma:
delete <nome de relao>
where <qualificao>
Comandos desta forma so processados em duas fases. Seja R a relao referenciada no
comando. Inicialmente todas as tuplas de R a serem removidas so localizadas como se o
comando fosse uma consulta. Em seguida, operaes do SAR (no discutidas na Seo 3.3)
so invocadas para retirar tais tuplas de R.
Considere agora inseres de apenas uma tupla
insert into <nome de relao>: <tupla>
- 27 -
ou inseres de mltiplas tuplas:
insert into <nome de rela o>: <c onsulta em SQL>
Ambos os tipos de insero so tratados novamente por operaes do SAR. Apenas no
segundo caso necessrio resolver inicialmente a consulta de SQL para localizar os dados a
serem inseridos.
Finalmente, considere atualizaes da forma:
update <nome de relao>
set <atualizao de campos>
where <qualificao>
Seja R a relao referenciada no comando. Neste caso h uma fase inicial em que as tuplas de
R a serem atualizadas so recuperadas conforme discutido nas sees anteriores, criando-se
uma relao temporria R. Em seguida, as atualizaes devidas so aplicadas a R.
Finalmente, atravs de operaes do SAR, as tuplas antigas de R so substitudas pelas novas,
que esto contidas em R.
NOTAS BIBLIOGRFICAS
A idia de desmembrar consultas e a tcnica de desmembramento controlado so uma
adaptao do mtodo de decomposio inicialmente proposto por Wong e Youssefi [1976] e
usado no sistema INGRES. Held, Stonebraker e Wong [1975] discutem brevemente como
estender decomposio para consultas cujas qualificaes so mais complexas, incluindo at
funes de agregao. As equaes de custo apresentadas so, por sua vez, adaptaes das
usadas no Sistema R e encontram-se descritas em detalhe em Selinger et all. [1979].
Christodoulakis [1983] e Richard [1981] discutem em consideravelmente mais detalhe como
estimar o tamanho do resultado de junes e outras expresses da lgebra relacional. O
tratamento de consultas e atualizaes no Sistema R abordado em uma srie de trabalhos.
Selinger et all. [1979] descrevem em detalhe o otimizador do Sistema R, cuja performance
analisada em Astrahan, Kim e Schkolnick [1980]. Chamberlin et all. [1981] descrevem em
detalhe o processo de compilao de consultas. Vrios outros trabalhos abordam extenses do
problema de processamento de consultas. Filkelstein [1982] estuda o problema de otimizar
conjuntamente seqncias de consultas. Jarke e Kock [1984] e Dayal[1979] investigam o
problema de processar consultas cujas qualificaes contm explicitamente quantificadores.
- 1 -
CAPTULO 5. PROCESSAMENTO DE COMANDOS DA LMD
- O CASO DISTRIBUDO
Este captulo aborda o problema do processamento de consultas e atualizaes em bancos de
dados distribudos, estendendo alguns resultados do captulo anterior. Novamente a maior
nfase recair sobre o problema de otimizao do processamento de consultas.
5.1 INTRODUO AO PROCESSAMENTO DE CONSULTAS
5.1.1 Discusso Geral
Processamento de consultas sobre um banco de dados distribudo corresponde a traduo de
pedidos, formulados em uma linguagem de alto nvel, para seqncias de operaes elementares
sobre os dados armazenados nos vrios bancos locais. Difere do caso centralizado em trs
aspectos bsicos:
o diretrio de dados, em geral, distribudo e a sua forma de armazenamento afeta
fortemente a eficincia do processador de consultas;
como o banco distribudo, uma relao do esquema conceitual pode estar fragmentada e
replicada ao longo da rede. O processador dever selecionar os fragmentos, localizar as
cpias apropriadas e eventualmente mov-las para que a consulta possa ser processada;
se o sistema for heterogneo, o processador dever, ainda, efetuar tradues entre modelos
de dados distintos.
Trataremos, brevemente, do problema do diretrio de dados em primeiro lugar. Lembremos que
o diretrio dever ser acessado antes do processamento da consulta em si para se obter
informao acerca das estruturas do banco, incluindo sua localizao, bem como estatsticas
necessrias fase de otimizao. O diretrio, em princpio, pode ser fragmentado e replicado
como qualquer banco distribudo. Os critrios usados para sua alocao so os mesmos usados
para qualquer banco distribudo. Basicamente, deve-se duplic-lo na medida do possvel,
evitando-se assim acessos remotos apenas para se obter informao sobre o banco. Por outro
lado, o custo de armazenamento do diretrio poder limitar o fator de replicao, ou forar a
adoo de replicao seletiva de partes do diretrio.
Passemos agora aos dois problemas seguintes. semelhana do caso centralizado, o processo
de traduo desmembra-se em quatro etapas, se visto em termos dos esquemas que compem a
descrio do banco de dados distribudo (ver Figura 5.1):
1. Traduo para o Esquema Conceitual Global.
2. Traduo para os Esquemas Conceituais Locais.
3. Processamento Local e Transferncia de Dados.
4. Ps-Processamento Global.
- 2 -
Figura 5.1 Fases do Processamento
Consideremos, inicialmente, o caso mais simples de um sistema homogneo. A etapa inicial,
traduo para o esquema conceitual global, idntica ao caso centralizado e mapeia a consulta
submetida pelo usurio, como formulada em termos do esquema externo a que este tem acesso,
em uma consulta equivalente, mas formulada em termos do esquema conceitual global.
A etapa seguinte, traduo para os esquemas conceituais locais, consiste da traduo da
consulta, formulada agora em termos do esquema conceitual global, para uma seqncia de
consultas locais e transferncias de arquivos. Esta etapa inteiramente diferente do caso
centralizado e dever resolver os problemas inerentes distribuio do banco. Novamente, a
fase de otimizao nesta etapa a parte crucial do processo.
A terceira etapa, processamento local e transferncia de dados, consiste em resolver consultas
locais atravs do SGBD local e no difere, portanto, do caso centralizado. A resoluo de uma
consulta local poder, no entanto, envolver transferncia prvia de dados.
Finalmente, a etapa de ps-processamento necessria pois o resultado de uma consulta pode
ser deixado sob forma de uma relao distribuda pelas etapas anteriores. Logo, necessrio
reunir os fragmentos do resultado em um nico n. Esta etapa, por ser simples, no ser tratada
explicitamente neste captulo.
Tradutor1
Tradutor2
SGBDL
BDL
Rede
comando expresso em termos
do esquema externo
comando expresso em termos
do esquema conceitual global
seqncia de comandos locais
e transferncias de dados
comando expresso em termos do
esquema conceitual local
seqncia de acessos fsicos
sobre o banco de dados local
Noi
Noj
(2)
(1)
(3)
- 3 -
O caso heterogneo mais complicado na medida em que os esquemas externos e os esquemas
conceituais locais no necessariamente esto no mesmo modelo de dados do esquema
conceitual global. Isto torna a primeira e a ltima etapas mais complexas e est fora do escopo
deste texto.
5.1.2 Estratgias de Processamento
A etapa mais crtica do processamento de consultas distribudas, traduo da consulta para os
esquemas conceituais locais, envolve dois aspectos importantes:
1. Tratamento de fragmentos e suas cpias.
2. Escolha das consultas locais e transferncias de arquivos.
A forma de resoluo destes dois problemas determina uma estratgia de implementao para
esta etapa. Em qualquer caso, porm, os parmetros so sempre o banco de dados em questo
(os vrios esquemas e as estatsticas sobre o estado corrente), uma determinada funo de custo,
a prpria consulta distribuda e o nome do n para onde o resultado dever ser mandado (o n
final).
Uma estratgia, talvez a mais simples, consiste em transformar a consulta distribuda em uma
consulta local:
PROCESSAMENTO CENTRALIZADO
1. loc alize os fragmentos necessrios c onsulta Q;
2. selec ione cpias dos fragmentos e um n n de tal forma a minimizar o c usto de mover as
cpias para n, e depois mover o resultado para o n final;
3. mova as c pias selecionadas para n;
4. execute Q localmente em n;
5. mova o resultado de Q para o n final.
Um refinamento possvel consiste em restringir as cpias atravs de consultas locais antes de
mov-las. Um programa consistindo de consultas locais e transferncias de dados com o
propsito de reduzir o tamanho das cpias a serem movidas chamado de um redutor.
Incluiremos no redutor tambm as transferncias finais para o n onde a consulta submetida
ser processada. O refinamento aludido resultar, ento, na seguinte estratgia:
PROCESSAMENTO CENTRALIZADO COM REDUO PRVIA
1. loc alize os fragmentos necessrios c onsulta Q;
2. selec ione cpias dos fragmentos, selecione um n n, defina um redutor P de tal forma a
minimizar o custo de executar P, e depois mova o resultado da consulta submetida para o
n final;
3. execute P;
4. execute Q localmente em n;
5. mova o resultado de Q para o n final.
- 4 -
Esta estratgia ser discutida em detalhe na Seo 5.1.2. Ela interessante pois reduz o
problema de processar consultas distribudas a um problema bem mais simples, mas, por outro
lado, leva a solues sub-timas, em geral.
No outro extremo do espectro de possveis alternativas, temos a estratgia que permite escolher
qualquer seqncia de consultas locais e transferncias de dados para resolver a consulta
distribuda:
OTIMIZAO IRRESTRITA DE CONSULTAS DISTRIBUDAS
1. selec ione um n n e um programa P (em geral paralelo) consistindo de consultas locais e
transferncias de dados de forma a minimizar o custo total de exec uo, gerando o
resultado em n, e o c usto de transferir o resultado para o n final.
2. execute P;
3. mova o resultado final para o n final.
Esta estratgia produz um programa timo dentre aqueles que utilizam apenas consultas locais e
transferncias de arquivos. Mas gera, no entanto, um problema de otimizao extremamente
difcil pois o nmero de possveis alternativas a serem exploradas explosivo.
As Sees 5.1.3 e 5.1.4 discutiro duas variaes desta estratgia diferindo no tratamento dos
fragmentos, mas ambas baseadas no critrio de desmembramento controlado. A primeira delas
transforma a consulta distribuda em uma consulta sobre fragmentos antes da fase de
otimizao:
DESMEMBRAMENTO CONTROLADO DISTRIBUDO A NVEL DE FRAGMENTOS
1. transforme a consulta Q em uma consulta equivalente Q' j incorporando a estratgia de
fragmentao;
2. desmembre Q' em consultas homogneas sobre os fragmentos, seguindo a estratgia de
desmembramento c ontrolado;
3. proc esse cada subc onsulta homognea sobre os fragmentos atravs de transferncias de
dados e c onsultas locais (a esc olha das cpias a serem usadas feita neste ponto);
4. mova o resultado para o n final.
A segunda variao a ser estudada desmembra a consulta distribuda antes do tratamento de
fragmentos e pode ser descrita brevemente como:
DESMEMBRAMENTO CONTROLADO DISTRIBUDO
1. desmembre Q em c onsultas irredutveis, ordenando-as segundo a estratgia de
desmembramento c ontrolado;
2. proc esse cada subc onsulta irredutvel atravs da reduo ao proc essamento
c entralizado, otimizando o proc esso;
3. mova o resultado para o n final.
Naturalmente, o passo 2 poderia ser alterado como abaixo criando-se uma terceira variao:
2. proc esse cada subconsulta irredutvel atravs de otimizao irrestrita;
Esta breve descrio das estratgias nos d, ento, um panorama das prximas sees.
- 5 -
5.1.3 Interface com o Gerente de Transaes
A interface entre o processador de comandos da LMD e o gerente de transaes seguir um
padro nico, independentemente da estratgia usada. Assumiremos que o processador de
comandos gera um programa concorrente consistindo de consultas e atualizaes locais (ou
seja, a serem executadas em um nico n) e transferncias de arquivos.
Mais precisamente, o processador de comandos gerar sempre programas pertencentes classe
PR, definida indutivamente como:
1. consultas e atualizaes locais suportadas pelos SGBDs locais pertencem a PR;
2. transferncias de tabelas externas de um n para outro pertencem a PR;
3. se P e P so programas em PR, ento a composio concorrente de P e P, denotada por
P // P', tambm pertence a PR;
4. se P e P so programas em PR, ento a composio seqncial de P e P, denotada por
P;P', tambm pertence a PR;
Consultas e atualizaes locais, como o nome indica, so executadas localmente em apenas um
n pelo SGBD local. Uma transferncia indica que alguma tabela externa deve ser movida de
um dado n n para um n m. Uma composio concorrente P // P indica que P e P podem ser
executados em paralelo, enquanto que uma composio seqncial P;P' indica que P s pode
ser executado depois que P terminar. Em ambos os casos, P e P podem ser programas que
envolvem tarefas em vrios ns.
As sees seguintes descrevero, de forma breve, como uma consulta ou atualizao sobre o
esquema conceitual global ser traduzida em programas do tipo acima.
5.2 PROCESSAMENTO CENTRALIZADO COM REDUO
Esta seo discute a estratgia mais simples para processamento de consultas distribudas, qual
seja, a transformao ao processamento centralizado. nfase ser dada a um refinamento em
que cpias so reduzidas atravs de consultas locais antes de serem movidas.
Consideraremos que a rede opera por comutao de pacotes e que o objetivo minimizar
apenas o trfego de mensagens. Assumiremos, ainda, que o banco distribudo de tal forma que
as relaes no so fragmentadas nem replicadas. Ou seja, cada relao reside inteiramente em
um n e no possui cpias. Esta suposio poder ser relaxada se fragmentos e cpias forem
tratados antes da fase de otimizao aqui descrita (como na Seo 5.1.3.2).
5.2.1 Introduo
Considere uma estratgia para reduzir o processamento de consultas distribudas ao caso
centralizado que opere em duas fases:
reduo: delimite, atravs de consultas locais, um subconjunto do banco de dados onde a
consulta possa ser executada;
execuo: envie as partes delimitadas na fase anterior para um n designado e l execute a
consulta.
- 6 -
Figura 5.2 - Processamento Centralizado com Reduo
O trabalho de otimizao, neste caso, se concentra na fase de reduo e consiste da escolha de
um redutor P e um n n de tal forma que o custo de executar P e mover os resultados para n seja
mnimo. O redutor deve ser acompanhado das transferncias finais para o n onde a consulta
submetida ser processada. A Figura 5.2 resume a seqncia de operaes desta estratgia.
5.2.2 Envelopes, Redutores e Semi-junes
Nesta seo investigaremos que operaes podem ser usadas para delimitar um subconjunto do
banco de dados suficiente para processar uma dada consulta distribuda Q. O processo de
delimitao comea com a definio de um envelope para Q, que um conjunto de consultas a
nvel do esquema conceitual global. O processo continua com a obteno de um redutor para o
envelope, que consiste de uma srie de consultas locais e transferncias de arquivos. O
resultado de processar Q contra o banco de dados original e contra o resultado do redutor deve
ser o mesmo.
A noo de envelope definida a nvel do esquema conceitual global. Suponha que R
1
,...,R
n
sejam os nomes de relaes mencionados na lista de relaes de Q. Um envelope para Q um
conjunto de consultas E={Q
1
,...,Q
n
} tal que:
Envelopa
Otimiza
Transfere
Dados em N
Q (consulta distribuda)
E (envelope de Q)
Reduz
BDD
P (redutor)
Executa
BDD reduzido
- 7 -
1. Cada Q
i
da forma
selec t t
i
from R
1
r
1
, ... ,R
n
r
n
where B
onde t
i
a lista dos atributos qualificados de R
i
que ocorrem em B e B uma conjuno
de comparaes da forma R
i
.A = R
j
.B ou R
i
.A = R
i
"." A = k.
Note que todas as consultas em E possuem a mesma qualificao.
2. Para todo estado S do banco de dados, para todo conjunto S de relaes resultante da
execuo de E em S, o resultado de Q em S e S o mesmo.
Nesta seo no abordaremos o problema de se obter um envelope para uma consulta, mas
suporemos que o envelope j dado.
Um redutor para um envelope E um programa concorrente P consistindo de consultas locais e
transferncias de arquivos tal que, para todo estado S do banco de dados, para todo conjunto S
de relaes resultante da execuo de P em S, o resultado de E em S e S o mesmo.
Lembremos que nesta seo a funo de custo se restringe ao trfego de dados na rede. O
benefcio de um redutor P a diferena entre o custo potencial do trfego de dados que P
economiza e o custo das transferncias de dados necessrias para executar P. Dado um envelope
E={Q
1
,...,Q
n
} possvel analisar como um redutor benfico P deve ser construdo. Sejam
R
1
,...,R
n
os nomes de relaes envolvidos em E. Recordemos que cada relao est
completamente armazenada em um n, por suposio. Para cada relao R
i
, o redutor P dever
conter uma consulta P
i
, local ao n onde R
i
reside, tal que:
Projees: P
i
dever conter na lista resultante apenas os atributos de R
i
mencionados em Q
i
. O
benefcio de projees sempre positivo e obtido a custo nulo, j que no h transferncia de
dados.
Restries: P
i
dever conter na sua qualificao todas as comparaes da forma R
i
.A=k e
R
i
.A=R
i
.B que forem conseqncia lgica da qualificao de Q
i
. (Isto fcil de se obter pois
todas as comparaes de Q
i
so igualdades. Assim, o problema degenera em um problema de
grafos). O benefcio de restries tambm ser sempre positivo e obtido a custo nulo j que no
h transferncia de dados.
Semi-junes: P
i
dever conter na sua qualificao todas as comparaes da forma R
i
.A=R
j
.B
que forem benficas. O benefcio deste tipo de comparao obtido comparando-se o seu custo
C como o volume de dados :f/V/ que economiza, onde:
C = 0 , se R
i
e R
j
esto no mesmo n
C = c(R
j
.B)*c(dom(R
j
.B)) , em caso contrrio
onde c(R
j
.B)=cardinalidade de R
j
.B
c(dom(R
j
.B))=comprimento dos elementos do domnio de B
O volume de dados que este tipo de comparao economiza estimado por:
V = (c
0
(R
i
) - c
1
(R
i
) ) * c (dom(R
i
))
- 8 -
onde
c
0
(R
i
) = cardinalidade de R
i
antes da semi-juno
c
1
(R
i
) = cardinalidade de R
i
depois da semi-juno
c(dom(R
i
)) = comprimento mdio das tuplas de R
i
As projees, restries e semi-junes descritas acima so chamadas de operaes permitidas
por E. Uma semi-juno R
i
.A=R
j
.B dita local se e somente se R
i
e R
j
residem no mesmo n. O
termo semi-juno advm do fato da comparao R
i
.A = R
j
.B, includa em P
i
, significar a
juno de R
i
com R
j
em A e B, seguida da projeo sobre os atributos de R
i
(pois P
i
s contm
na sua lista resultante atributos de R
i
). Ou seja, a semi-juno "a metade de uma juno".
As transferncias de dados necessrias ao processamento de P so implicitamente definidas
pelas semi-junes includas em P. De fato, se a relao R
j
no residir no mesmo n que R
i
, ser
necessrio transferir a projeo R
j
[B] para o n onde R
i
reside para se resolver a semi-juno
R
i
.A=R
j
.B.
5.2.3 Otimizao
Esta seo discute o problema de otimizao bsico da estratgia em discusso. A entrada do
otimizador ser um envelope E e estatsticas D sobre o estado corrente do banco. A sada um
redutor P, que estimado ser benfico para todo estado modelado por D, e um n n onde a
consulta ser executada. O algoritmo de otimizao segue o mtodo ganancioso e no garante a
obteno do timo global.
OTIMIZACAO_REDUCAO(E,D;P,n)
/ *
entrada: - envelope E e estatstic as D
sada: - redutor P e n final n
*/
begin
/ *
aproximao inicial
*/
c onstrua P contendo todas as proje es, restries e semi-junes locais permitidas por E;
estime o benefcio de todas as semi-junes no-locais permitidas por E;
/ *
incremento a P
*/
while houver uma semi-juno no-local benfica e permitida por E do
begin
seja s
j
a semi-juno no-local permitida por E de maior benefcio;
acresc ente s
j
consulta local em P apropriada;
ac resc ente a transferncia de dados necessria ao proc essamento de s
j
;
ajuste os benefcios das semi-junes restantes para levar em considerao
os efeitos de s
j
;
end
/ *
esc olha do n n
*/
para cada n m, seja TAM(m) a soma do total de "bytes"
das relaes referenciadas em E e armazenadas em m;
esc olha n como o n c om maior valor de TAM(n);
acrescente a P comandos para transferir os dados necessrios dos outros ns para n;
end
- 9 -
Este algoritmo puramente ganancioso e pode ser melhorado atravs de uma anlise detalhada
da seqncia de operaes que gera (veja as referncias bibliogrficas no final deste captulo).
Por exemplo, a escolha do n final pode tornar alguma semi-juno suprflua. Assim, poder-se-
ia acrescentar a seguinte otimizao aps o final do algoritmo anterior:
seja P
n
a consulta local a ser exec utada em n;
para cada semi-juno R
i
.A = R
k
.B de P
n
do
se o c usto de P sem esta semi-juno for menor do que o c usto original de P
ento retire esta semi-juno de P
n
Isto conclui a nossa descrio do mtodo centralizado com reduo.
5.3 DESMEMBRAMENTO CONTROLADO DISTRIBUDO - PARTE I
Esta seo indica uma primeira forma de se estender a heurstica de desmembramento
controlado para um ambiente distribudo. A caracterstica principal desta primeira extenso o
tratamento dos fragmentos antes do prprio desmembramento.
5.3.1 Fases do Desmembramento
Desmembramento controlado distribudo a nvel de fragmentos uma forma de implementar a
etapa de traduo de consultas, formuladas em termos do esquema conceitual global, para uma
srie de consultas locais e transferncias de arquivos.
As fases desta forma de desmembramento sero as seguintes:
1. Tratamento de Fragmentos: transforma a consulta, expressa em termos do esquema
conceitual global, em uma consulta equivalente expressa em termos de fragmentos (sem
levar em considerao replicao);
2. Desmembramento controlado: desmembra a consulta em subconsultas homogneas da
forma usual, otimizando o processamento atravs da ttica de desmembramento controlado;
3. Processamento de Subconsultas Homogneas: traduz cada subconsulta resultante do
desmembramento em uma srie de subconsultas locais e transferncias de arquivos. Nesta
etapa, cpias dos fragmentos so selecionadas;
4. Processamento Local: os SGBDs locais processam as subconsultas locais que lhes cabem e
transferem arquivos, se necessrio.
O processo de otimizao ser guiado pela heurstica de desmembramento controlado como no
caso centralizado pois, em um ambiente distribudo, extremamente importante limitar o
espao de busca da soluo tima j que o nmero de solues possveis enorme. (alm da
complexidade inerente da consulta h que se lidar com a distribuio do banco em si).
A funo de custo que governa a fase de otimizao poder tanto ser baseada no custo de
processamento da consulta, que inclui agora transferncias de arquivos, quanto no tempo de
resposta. Em qualquer caso, dever levar em considerao o tipo de rede utilizada: comutao
de pacotes ou difuso ("broadcast").
- 10 -
As subsees seguintes trataro de cada uma das fases do processamento e do problema de
otimizao e estimao de custo, exceto a fase de processamento local que idntica quela
discutida para o caso centralizado.
5.3.2 Tratamento de Fragmentos
O propsito da etapa inicial transformar uma consulta sobre o esquema conceitual global em
uma consulta equivalente que j incorpore informao sobre o critrio de fragmentao do
banco. O tratamento de fragmentos est baseado na suposio de que o mapeamento do
esquema conceitual global para os esquemas conceituais locais feito em dois nveis:
1. Fragmentao: cada relao , se desejvel, fragmentada;
2. Replicao: cada fragmento ento distribudo para um ou mais ns.
Alm disto, supe-se que h um mapeamento definindo como cada fragmento formado e um
mapeamento definindo como cada relao do esquema conceitual global reconstruda a partir
dos seus fragmentos (ignorando replicao). Ou seja, a forma de fragmentao e replicao de
cada relao do esquema conceitual, bem como a forma de reconstruo, so explicitamente
definidas. Este cuidado essencial pois atravs dos mapeamentos que definem a forma de
fragmentao e replicao podemos traduzir inseres, atualizaes e remoes globais em seus
correspondentes locais e, atravs dos mapeamentos que definem como reconstruir uma relao
do esquema conceitual global a partir dos seus fragmentos, podemos tratar consultas.
Observemos ainda que o mapeamento de reconstruo deve agir como o inverso do
mapeamento de distribuio para que a definio do banco possa ser considerada como correta.
Em geral, no possvel se obter tais inverses automaticamente, da a necessidade de inclu-las
na definio do banco.
Como resultado, temos, efetivamente, um novo nvel de descrio do banco de dados
distribudo. De fato, a aplicao dos critrios de fragmentao ao esquema conceitual global
gera um novo esquema que chamaremos de esquema conceitual fragmentado, simplesmente.
Como exemplo considere um banco de dados distribudo em trs ns conforme descrito abaixo:
Esquema Conceitual Global (contm apenas uma relao):
R[A,B,C,D,E]
Critrios de Fragmentao de R:
R
1
[A,B,C] tal que R
1
a projeo de R em A, B, C;
R
2
[A,D,E] tal que R
2
a projeo de R em A,D,E
seguida da seleo das tuplas com A<a;
R
3
[A,D,E] tal que R
3
a projeo de R em A,D,E
seguida da seleo das tuplas com Aa;
- 11 -
Critrio de Reconstruo de R:
R reconstruda da seguinte forma:
selec t R
1
.A,R
1
.B,R
1
.C,R
2
.D,R
2
.E
from R
1
, R
2
where R
1
.A=R
2
.A
union
select R
1
.A,R
1
.B,R
1
.C,R
3
.D,R
3
.E
from R
1
, R
3
where R
1
.A=R
3
.A
Critrios de Distribuio dos Fragmentos pelos Esquemas Conceituais Locais:
N 1: contm apenas uma cpia de R
1
N 2: contm cpias de R
1
e R
2
N 3: contm apenas uma cpia de R
3
Estando o banco de dados distribudo definido da forma acima, o tratamento de fragmentos
torna-se idntico traduo de consultas sobre esquemas externos para consultas sobre o
esquema conceitual. Por exemplo, considere a seguinte consulta sobre o esquema conceitual
global do banco anteriormente descrito:
selec t A,D,E
from R
where B = 'b'
Sem nos preocuparmos com o problema de cpias, podemos traduzir esta consulta em
subconsultas sobre os fragmentos utilizando apenas o mapeamento de reconstruo para R. A
consulta resultante, Q', seria:
selec t R
1
.A, R
2
.D, R
2
.E
from R
1
, R
2
where R
1
.A = R
2
.A
and R
1
.B = 'b'
union
selec t R
1
.A, R
3
.D, R
3
.E
from R
1
, R
3
where R
1
.A = R
3
.A
and R
1
.B = 'b'
Isto conclui a discusso sobre o tratamento de fragmentos.
5.3.3 Desmembramento Propriamente Dito
A fase central do processo, o desmembramento propriamente dito, transforma uma consulta
(formulada em termos do esquema conceitual fragmentado) em uma srie de consultas
homogneas (tambm formuladas em termos do esquema conceitual fragmentado) e
transferncias de arquivos. A heurstica de desmembramento controlado utilizada nesta fase
para reduzir o trabalho de otimizao mas, ao mesmo tempo, evitar a construo de resultados
intermedirios vultuosos sem necessidade.
- 12 -
A definio da heurstica em nada alterada em relao quela discutida para o caso
centralizado, exceto no que se refere funo de custo. A consulta ser desmembrada em suas
componentes irredutveis. Estas componentes sero parcialmente ordenadas de tal forma que as
subconsultas homogneas sejam executadas primeiro, se possvel, e a componente contendo a
lista resultante seja executada por ltimo. Cada componente ser otimizada em separado,
ignorando-se as outras componentes.
A funo de custo que governa a fase de otimizao poder tanto ser baseada no custo de
processamento da consulta quanto no tempo de resposta, e dever levar em considerao o tipo
de rede utilizada: comutao de pacotes ou difuso ("broadcast").
Consideremos, a guisa de exemplo, o caso de custo de processamento em uma rede por
comutao de pacotes. A funo de custo, neste caso, ser composta de trs fatores:
C = k
1
* custo de processamento local +
k
2
* custo de I/O local +
custo de transmisso de dados
onde k
1
e k
2
so constantes de mrito relativo. As duas primeiras parcelas so idnticas ao caso
centralizado. J o custo de transmisso de dados , em geral, estimado levando-se em conta
apenas o nmero de pacotes necessrios para transferir uma tabela de um n para outro. Ou
seja, o custo de transmitir um pacote o mesmo entre qualquer par de ns. O nmero de pacotes
, por sua vez, estimado em termos do tamanho do pacote, da cardinalidade estimada da tabela e
do comprimento mdio dos seus registros. Note que a estimao dos dois primeiros fatores j
foi discutida quando tratamos do caso centralizado.
Por fim, observamos que a estimao do custo de processamento de uma consulta genrica a
soma das estimativas de custo das subconsultas homogneas em que foi desmembrada. Por sua
vez, em vista das estratgias para processamento de consultas homogneas distribudas, a
estimativa do custo de processamento destas consultas recai no caso centralizado e na estimao
do custo de transferncia de tabelas, j discutido.
5.3.4 Processamento de Consultas Homogneas
Nesta etapa, uma subconsulta homognea mapeada em uma srie de consultas locais e
transferncias de arquivos. O resultado da subconsulta homognea poder ser deixado
fragmentado em vrios ns. As subconsultas locais e as transferncias de arquivos sero
processadas pelos SGBDs locais, explorando o paralelismo da rede sempre que possvel.
A subconsulta considerada nesta fase j est re-escrita em termos de fragmentos e homognea
com relao a este nvel de descrio do banco. Os problemas a serem resolvidos consistem,
ento, da escolha das cpias dos fragmentos a serem usadas e da definio de uma estratgia de
transferncia de dados para reduzir a consulta a subconsultas locais.
Consideraremos consultas univariveis em separado daquelas de duas variveis.
- 13 -
(A) Consultas Homogneas Univariveis
Uma consulta homognea univarivel, a nvel do esquema conceitual fragmentado, referencia
apenas um fragmento. Portanto o seu processamento simples e consiste apenas de trs passos:
1. Escolha da cpia do fragmento a ser utilizada;
2. Envio da consulta para o n que armazena a cpia escolhida;
3. Processamento local da consulta, permanecendo o seu resultado no prprio n.
(B) Consultas Homogneas de Duas Variveis
Sejam F
1
e F
2
os dois fragmentos referenciados pela consulta homognea de duas variveis Q
em questo. H vrias estratgias a considerar:
Estratgia 1:
Se existem cpias dos fragmentos em um mesmo n i, a consulta poder ser executada
localmente em i e o seu resultado a permanecer.
Estratgia 2:
Sejam Q
1
e Q
2
as subconsultas de Q geradas pelas clusulas de Q que referenciam apenas F
1
e
F
2
, respectivamente. Seja Q
3
a subconsulta de Q gerada pelas clusulas de Q que referenciam F
1
e F
2
. Cpias de F
1
e F
2
residindo em ns diferentes, i e j, so selecionadas e Q
1
e Q
2
executadas
localmente em i e j. Os resultados so enviados para um terceiro n k onde Q
3
executada. O
resultado de Q , ento, o resultado de Q
3
e permanece em k.
Estratgia 3:
Seja Q
1
como na estratgia 2. Seja Q
2
a subconsulta de Q gerada pelas clusulas de Q que no
foram usadas para gerar Q
1
. Cpias de F
1
e F
2
residindo em ns diferentes, i e j, so
selecionadas e Q
1
executada localmente em i. O resultado enviado para j onde QPRIME
2

executada. O resultado de Q , ento, o resultado de Q
2
e permanece em j.
Estratgia 4:
Idntica anterior, invertendo-se os papis de F
1
e F
2
.
Isto encerra a discusso sobre o processamento de consultas homogneas.
5.4 DESMEMBRAMENTO CONTROLADO DISTRIBUDO - PARTE II
A variao do desmembramento controlado apresentado na Seo 5.1.3 possui duas
caractersticas importantes:
1. Uma consulta mapeada para o esquema conceitual fragmentado antes do
desmembramento;
2. S h movimento de dados para processar as subconsultas homogneas (sobre o esquema
conceitual fragmentado).
Esta forma de conduzir o processamento pode gerar, no entanto, movimentos de dados
desnecessrios, pois o desmembramento j a nvel de fragmentos.
- 14 -
Considere, por exemplo, a seguinte consulta:
selec t R.A
from R, S
where R.B=S.B
Suponha que R e S esto fragmentados horizontalmente em R
1
, R
2
e S
1
, S
2
respectivamente.
Ento a consulta anterior seria inicialmente transformada em:
select R
1
.A
from R
1
, S1
where R
1
.B=S
1
.B
union
select R
1
.A
from R
1
, S
2
where R
1
.B=S
2
.B
union
select R
2
.A
from R
2
, S
1
where R
2
.B=S
1
.B
union
select R
2
.A
from R
2
, S
2
where R
2
.B=S
2
.B
Assumindo que os quatro fragmentos esto em ns separados, so necessrias quatro
transferncias de dados, digamos, S
1
e S
2
para o n de R
1
, e S
1
e S
2
para o n de R
2
para resolver
as quatro consultas acima. Alm disto, so necessrias duas transferncias de dados para mover
os resultados dos ns onde esto armazenados R
1
e R
2
para o n final. Em contraste, os quatro
fragmentos poderiam ser simplesmente movidos para o n final, economizando-se, assim, 2
transferncias.
De forma geral, uma alternativa plausvel para o mtodo de resoluo apresentado na seo
anterior seria desmembrar a consulta em componentes irredutveis antes de tratar os fragmentos.
Obter-se-ia, primeiramente, as subconsultas irredutveis a nvel de esquema conceitual global
para depois tratar de fragmentos e cpias. Cada subconsulta irredutvel Q poderia ser
processada por desmembramento irrestrito ou por reduo ao processamento centralizado. Em
ambos os casos a heurstica de desmembramento controlado seria usada com o propsito de
reduzir o problema de otimizao inicial a uma srie de problemas de otimizao mais simples
(referentes s subconsultas irrestritas), evitando ainda a obteno de resultados intermedirios
demasiadamente grandes.
5.5 PROCESSAMENTO DE ATUALIZAES
Esta seo discute brevemente o problema de se processar atualizaes em bancos de dados
distribudos usando novamente SQL como a LMD bsica. Inicialmente, os problemas comuns a
todas as formas de atualizao sero apresentados. Em seguida, o processamento de cada tipo
de atualizao ser discutido em detalhe.
Conforme apresentado em detalhe na Seo 3.2.2, SQL possui quatro comandos bsicos para
atualizao do banco:
- 15 -
remoes da forma:
delete <nome de relao>
where <qualificao>
inseres de apenas uma tupla:
insert into <nome de rela o>: <tupla>
inseres de mltiplas tuplas:
insert into <nome de rela o>: <c onsulta em SQL>
atualizaes da forma:
update <nome de relao>
set <atualizao de campos>
where <qualificao>
H trs problemas bsicos a serem resolvidos no contexto de atualizaes em BDDs:
1. localizao dos dados afetados pela atualizao;
2. atualizao dos dados em si;
3. tratamento de fragmentos e cpias.
De forma geral, e independentemente do tipo de atualizao, estes problemas so equacionados
da seguinte forma. O primeiro problema resolvido utilizando-se as tcnicas descritas
anteriormente para processar consultas, exceto que os resultados podero ser deixados sob
forma de uma relao distribuda. O segundo problema tratado atravs de novas operaes do
subsistema de armazenamento (que no so descritas aqui) para atualizao de campos de
tuplas. O terceiro problema j no to simples pois, como as atualizaes so descritas a nvel
do esquema conceitual global, necessrio mape-las para atualizaes a nvel de fragmentos e
cpias. Em toda a sua generalidade, este um problema extremamente difcil, sendo
equivalente ao problema de atualizar vises (ou esquemas externos. Veja as referncias
bibliogrficas para tratamentos deste problema). No entanto, atravs de certas hipteses sobre
como fragmentos e cpias so definidos, gerados e mantidos possvel contorn-lo de forma
satisfatria. Para tal, assumiremos que os fragmentos so gerados segundo a poltica abaixo:
1. cada tupla t de uma tabela t a nvel do esquema conceitual global recebe um identificador
interno (isto j era feito pelo SAR no caso centralizado)
2. cada tupla t resultante da fragmentao de t carrega consigo a identificao da tupla
original t e inserida em todas as cpias do fragmento de t a que pertence. Se houver
fragmentao horizontal e esta no definir uma partio de t, insira t em todos os
fragmentos horizontais de t possveis;
3. quando t for removida por um comando da LMD, remova todas as tuplas com o mesmo
identificador que t de todos os fragmentos de t e suas cpias;
4. tuplas que no puderem ser mapeadas em nenhum fragmento pelos critrios de distribuio
sero tratadas como violaes de um critrio de consistncia implcito.
Cada tipo especfico de atualizao tratado da seguinte forma.
- 16 -
Considere inicialmente uma insero do seguinte tipo:
insert into R: Q
onde Q uma consulta em SQL. Seja R' a relao resultante de Q.
Esta insero ser tratada da seguinte forma:
1. execute Q, criando R' em um nico n;
2. gere novos identificadores para as tuplas de R';
3. fragmente R' em R
1
, , R
n
de acordo com os critrios de fragmentao de R e seguindo a
poltica anteriormente descrita para tratamento de fragmentos;
4. envie R
i
para cada n contendo uma cpia do fragmento correspondente de R;
5. faa as inseres locais atravs de operaes do SAR.
O tratamento de inseres de apenas uma tupla idntico, apenas que o primeiro passo no
necessrio.
Considere agora uma remoo do tipo:
delete R where B
O tratamento de remoes deste tipo segue o seguinte procedimento:
1. resolva, atravs dos algortmos usados para processamento de consultas, a qualificao B
recuperando apenas os identificadores de tuplas. O resultado pode ser deixado sob forma de
uma relao distribuda R';
2. envie o conjunto de identificadores recuperados para todos os ns contendo cpias de algum
fragmento de R;
3. remova localmente, atravs de operaes do SAR, todas as tuplas de cpias de fragmentos
de R cujos identificadores esto no conjunto recebido.
Finalmente, considere o tratamento de atualizaes de campos:
update R
set R.A1=E1,...,R.An=En
where B
Este tipo de comando apresenta uma complicao adicional gerada pelo fato de, ao alterar o
valor de um campo, o usurio implicitamente fora a migrao de uma tupla de um fragmento
para outro. Uma forma de processar este tipo de comando seria:
1. recupere todas as tuplas de R que satisfazem B atravs dos algortmos de processamento de
consultas usuais. A relao resultante R' poder ser deixada distribuda, mas dever incluir
os identificadores das tuplas;
2. faa todas as modificaes definidas pelo comando nos fragmentos de R';
3. distribua apenas os identificadores recolhidos em R' para todos os ns que contm cpias de
fragmentos de R;
4. redistribua R' de acordo com os critrios de fragmentao de R;
- 17 -
5. em cada n armazenando uma cpia de um fragmento de R, remova as tuplas cujos
identificadores esto no conjunto de identificadores recebido e insira as novas tuplas
recebidas, se este for o caso.
Isto conclui a nossa breve descrio sobre processamento de comandos da LMD em bancos de
dados distribudos.
BIBLIOGRAFIA
Wong [1977], um dos primeiros trabalhos em otimizao de consultas distribudas, descreve
uma heurstica de otimizao (gananciosa) baseada apenas em transferncias de arquivos e
consultas locais. Hevner e Yao [1978], tambm um dos trabalhos pioneiros, apresenta uma
heurstica mais sofisticada. O algortmo centralizado com reduo prvia usado no sistema
SDD-1 e descrito em Goodman et all. [1979]. A tcnica de usar semi-junes para diminuir o
trfego de dados recebeu considervel ateno recentemente. Bernstein e Chiu [1981] foram dos
primeiros a explorar esta tcnica em detalhe. Yu e Chang [1983] explicam como melhorar o
mtodo baseado em semi-junes descrito no texto, incorporando tambm o problema de tratar
cpias mltiplas. O mtodo de desmembramento controlado distribudo inspirado no
algortmo de decomposio distribudo usado no sistema INGRES e apresentado em Epstein,
Stonebraker e Wong [1978] e Stonebraker [1980]. O processo de otimizao de consultas usado
no Sistema R* esboado em Selinger e Adiba [1980]. Daniels et all. [1982] resumem a
estratgia de compilao usada no Sistema R*. Maiores detalhes encontram-se em Daniels
[1982] e Ng [1982]. Dayal [1983] apresenta o mtodo usado para processar consultas no
sistema MULTIBASE, que heterogneo e possui uma arquitetura bem peculiar.
- 1 -
Captulo 6. INTRODUO GERNCIA DE TRANSAES
No captulo anterior foram descritos procedimentos atravs dos quais comandos que partem
do usurio so decompostos em aes elementares e distribudos atravs dos vrios ns que
compem o sistema. As preocupaes bsicas recaam, tipicamente, em tcnicas para se
determinar quais os mecanismos de acesso mais eficientes s tabelas residentes em cada n
particular; em como deslocar dados entre os ns quando a informao necessria encontra-se
distribuda ou mesmo replicada pelos vrios ns; etc. Neste captulo, e de ora em diante, tais
questes sero pressupostas como devidamente equacionadas. Tudo se passa como se
adentrssemos uma camada mais interior do sistema de gerncia do banco de dados qual
so requisitadas tarefas bem determinadas. O leitor deve estar atento para o fato de que tais
tarefas ou seqncias de aes elementares manipulam os dados a nvel fsico, uma vez que o
processador de comandos da LMD, discutido no captulo anterior, j resolveu, a partir de uma
anlise da consulta do usurio, todos os dilemas a nvel lgico.
O objetivo primordial deste captulo dar uma viso panormica dos problemas enfrentados
pelo gerente de transaes. O conceito fundamental de uma transao introduzido na
prxima seo. Toda discusso subseqente dele depender criticamente. A seo seguinte
aborda aspectos relativos ao gerenciamento de transaes e discute os procedimentos que
devem ser efetivados em vrios pontos especficos durante a execuo de transaes. A
prxima seo toca nos problemas advindos de falhas no sistema que perturbam o ciclo de
vida normal de transaes em execuo. Por questes de eficincia do sistema como um todo
desejvel que vrias transaes executem simultaneamente em cada n. Isto acarreta
problemas de controle de concorrncia que so mencionados na ltima seo deste captulo.
Os trs captulos seguintes detalham as questes relativas ao gerenciamento de transaes,
controle de concorrncia e falhas no sistema, respectivamente.

6.1 O CONCEITO DE TRANSAO
6.1.1 Noes Bsicas
A nvel lgico, um banco de dados distribudo descrito por um esquema conceitual global.
Neste e nos captulos que se seguem, os objetos descritos no esquema conceitual global sero
chamados de objetos lgicos, e uma funo associando a cada objeto lgico um valor ser
chamada de estado lgico do banco. A linguagem de manipulao de dados (LMD) oferece
ento uma srie de comandos para criar, destruir ou modificar objetos lgicos. Embora a
natureza dos objetos lgicos e as caractersticas da LMD dependam do modelo de dados
usado para descrever esquemas conceituais, a discusso neste captulo ser largamente
independente destes detalhes.
A nvel fsico, o banco de dados definido atravs de uma srie de esquemas internos, um
para cada n em que o banco armazenado. Os objetos descritos nos esquemas internos sero
chamados de objetos fsicos ou simplesmente objetos. A cada objeto fsico est associado um
nico nome de tal forma que objetos diferentes recebem nomes distintos. Os operadores
atmicos que atuam sobre os objetos fsicos sero chamadas de aes elementares.
Finalmente, a cada instante, o estado fsico ou, simplesmente, o estado do banco de dados
associa a cada objeto fsico um determinado valor, que poder mudar por meio de uma ao
elementar.
- 2 -
O relacionamento entre o esquema conceitual global e os vrios esquemas internos definido
atravs de mapeamentos, que servem a dois propsitos:
1. indicar os objetos fsicos que implementam um objeto lgico;
2. indicar como construir um estado lgico do banco a partir do estado fsico corrente.
A cada objeto lgico podero naturalmente estar associados vrios objetos fsicos atravs
destes mapeamentos.
Neste captulo, para efeitos dos exemplos, assumiremos que o modelo relacional usado para
descrever o esquema conceitual global e que a linguagem de manipulao de dados SQL.
Portanto, os objetos lgicos sero relaes, tuplas e campos de tuplas. Quanto aos objetos
fsicos, assumiremos que so tabelas do SAR, e no pginas e segmentos conforme seria de
se supor tendo em vista a discusso da Seo 3.3. Isto uma mera convenincia para tornar
os exemplos mais simples. Alm disto, assumiremos ainda que as tabelas so descritas como
"arrays" em PASCAL, o que possibilita usar a notao usual de PASCAL para descrever
aes elementares sobre as tabelas.
Um exemplo simples servir para esclarecer a discusso acima, um tanto compacta.
Considere um esquema conceitual global contendo apenas um esquema de relao, definida
como (ignorando os domnios dos atributos):
CONTAS[CPF,NOME,SALARIO,ENDERECO,NUMERO_CONTA,SALDO,SALDO_MEDIO]
A chave neste caso NUMERO_CONTA.
Suponha que este esquema de relao mapeado em duas tabelas, CADASTRO e
CONTAS_CORRENTES (a localizao exata das tabelas no importante), descritas da seguinte
forma:
type PESSOA = rec ord of
CPF = integer;
NOME = array[1..30] of CHAR;
SALARIO = real;
ENDERECO = array[1..5,1..50] of CHAR
end;
MOVIMENTO = rec ord of
NUMERO_CONTA, CPF integer;
SALDO, SALDO_MEDIO = real
end;
var CADASTRO = array[1..1000] of PESSOA;
CONTAS_CORRENTES = array[1..1000] of MOVIMENTO;
O mapeamento de CONTAS nas tabelas CADASTRO e CONTAS_CORRESTES definido da
seguinte forma:
CADASTRO a projeo de CONTAS em CPF, NOME, SALARIO, ENDERECO;
CONTAS_CORRENTES a projeo de CONTAS em NUMERO_CONTA, CPF,
SALDO, SALDO_MEDIO.
- 3 -
Os objetos lgicos deste banco sero dados pela relao associada a CONTAS, as tuplas da
relao associada a CONTAS e os campos destas tuplas. Note que as tuplas, ao contrrio das
relaes, no tm um nome especfico. Os objetos fsicos sero as tabelas, os elementos das
tabelas e seus campos.
Um comando de SQL, a LMD usada no exemplo, refere-se a uma relao pelo seu nome
(dado no esquema conceitual), mas identifica as tuplas de uma relao pelos valores dos seus
campos. Observe a seguinte atualizao:
update CONTAS
set SALDO = SALDO - 1000
where NUMERO_CONTA = 34.567
Atravs de uma srie de transformaes, um comando da LMD eventualmente gera uma
seqncia de aes elementares. Por exemplo, o comando anterior poderia gerar a seguinte
seqncia
A1 = (LEIA,CONTAS_CORRENTES[4].SALDO,X)
A2 = (COMPUTE,X:=X-1000)
A3 = (ESCREVA,CONTAS_CORRENTES[4].SALDO,X)
onde X representa uma varivel tipo "real" e :f/ CONTAS_CORRENTES[4] indica que o quarto
elemento de CONTAS_CORRENTES corresponde a tuplas de CONTAS com NUMERO_CONTA =
34.567.
Por ltimo, h a noo de consistncia de estados. Podemos visualizar tambm dois nveis de
consistncia para o banco, consistncia lgica e consistncia interna.
Considere consistncia lgica primeiro. fcil de aceitar que, sob o ponto de vista do
usurio, cada estado do banco deve satisfazer certos critrios de consistncia. Por exemplo, o
saldo das contas dever ser sempre positivo. Um estado lgico do banco consistente quando
satisfizer a todos os critrios de consistncia. Caso contrrio, diz-se que o estado
inconsistente. Suporemos aqui que no seja de responsabilidade do SGBD cuidar para que
violaes dos critrios de consistncia no ocorram. Isto ser obrigao do usurio ao
codificar as atualizaes do banco.
J consistncia interna se refere coerncia das estruturas internas (objetos fsicos) usados
para armazenar o banco. Por exemplo, uma rvore-B poder ser usada para manter um ndice
sobre determinados campos de uma tabela. Isto implica que as chaves e ponteiros da rvore-B
devem estar sempre consistentes com os dados armazenados na prpria tabela. Dentro deste
conceito, o SGBD dever, ento, ser responsvel pela manuteno da consistncia interna do
banco.
6.1.2 Transaes
Suponha que um usurio apresente a seguinte atualizao a um banco de dados usado para
processar compensao de cheques bancrios.
Debite $100,00 c onta corrente do cliente N
Credite $100,00 c onta c orrente do cliente M
Aps manipulao pelo processador de consultas, teramos algo como a seguinte seqncia
de aes elementares
- 4 -
A1 = (LEIA,CONTA_CORRENTE[A].SALDO,X)
A2 = (COMPUTE, W:=X-100)
A3 = (ESCREVA,CONTA_CORRENTE[A].SALDO,W)
A4 = (LEIA,CONTA_CORRENTE[B].SALDO,X)
A2 = (COMPUTE, W:=X+100)
A6 = (ESCREVA,CONTA_CORRENTE[B].SALDO,W)
onde A e B so os elementos de CONTA_CORRENTE correspondentes s tuplas de CONTAS
com NUMERO_CONTA = N e NUMERO_CONTA = M, respectivamente.
Por alguma razo qualquer (falta de energia, falhas no equipamento ou programas, etc.)., a
atividade do banco de dados interrompida aps a execuo da ao elementar A3. Ao
retornar atividade, teramos debitado $100,00 conta de A e ainda no creditado valor
algum conta de B. Isto colocaria o banco de dados num estado inconsistente, pois $100,00
teriam simplesmente "desaparecido". Seria muito conveniente se pudssemos assegurar que a
seqncia de aes elementares acima tivesse a propriedade de que "ou todas as aes
elementares executam com sucesso ou nenhuma delas executada". Em outras palavras,
gostaramos de estender o conceito de atomicidade de modo a envolver agora tambm
seqncias de aes elementares.
A atomicidade de seqncia de aes elementares poderia tambm ser violada por
interferncia de outras aes executadas concorrentemente (exemplos sero dados no
Captulo 8).
A noo de transao introduzida para forar o sistema a executar uma seqncia de aes
elementares como se fosse uma unidade atmica, sem interferncia externa.
A nvel lgico, uma transao definida atravs de um programa em uma linguagem de alto
nvel, contendo comandos da LMD embebidos, e iniciado e terminado pelos comandos
COMEO-DE-TRANSAO e FIM-DE-TRANSAO. Na sua forma mais simples, uma transao
contm apenas um comando da LMD. Exige-se do usurio que codifique as transaes de tal
forma que quando executadas sozinhas:
T1. sempre terminem;
T2. preservem a consistncia do banco de dados.
Exige-se do SGBD, por sua vez, que a cada invocao de uma transao T:
S1. a transao T seja executada por completo;
S2. a execuo da transao T se d sem interferncia de outras transaes que porventura
estejam sendo executadas concorrentemente.
Lembremos que a cada transao T corresponde uma seqncia de aes elementares sobre
os objetos fsicos. O primeiro requisito, S1, garante ento que o efeito lquido, isto , aquele
que ser tornado pblico aps o trmino da chamada a T, refletir o fato de que todas ou
nenhuma das aes elementares de T foram executadas. Note que isto no implica em que
cada uma das aes de T deva ser ativada apenas uma nica vez. Para ver isto, suponha que
existam, no repertrio de aes elementares do n onde T foi executada, as aes elementares
A
1
,, A
n
onde A
i
indica a ao elementar de efeito exatamente contrrio A
i
. Em
outras palavras, A
i
devolve o banco de dados ao estado anterior execuo de A
i
.
Retornando ao exemplo anterior sobre compensao bancria, fcil ver que A
1
, como uma
- 5 -
operao de "leitura", no altera o estado do banco. Portanto, seria vlido colocar A
1
=
(NULO), isto , A
1
no corresponde operao alguma. Idem, A
2
= (NULO).
Continuando, A
3
= (ESCREVA, CONTA_CORRENTE[A].SALDO, X) pois a varivel X detm o
contedo inicial de CONTA_CORRENTE[A].SALDO at o trmino da transao. Note que isto
restaura o valor do objeto CONTA_CORRENTE[A] ao valor que apresentava antes da execuo
de A
3
. Podemos definir A
4
, A
5
e A
6
analogamente.
Dentro deste esprito, se E = (A
1
, A
2
, A
3
, A
4
) for a seqncia de aes elementares gerada por
uma execuo seqencial de T, ento cada uma das seqncias de aes elementares abaixo,
quando ativadas pelo sistema, satisfazem ao requisito contido no item (1) acima.
A
1
, A
2
, A
3
, A
4
A
1
, A
2
, A
2
, A
2
,

A
3
, A
4
, A
4
, A
4
A
1
, A
1
, A
1
, A
1
, A
1
, A
2
,

A
3
, A
3
, A
2
, A
1
,

A
1
, A
2
,

A
3
, A
4
Na realidade, embora as aes elementares A
i
paream um tanto obtusas no momento,
desempenharo um papel crucial nas idias a serem desenvolvidas mais adiante. O leitor
atento j deve ter percebido isto. Voltando ao exemplo da compensao bancria, caso o
sistema falhe aps a execuo das aes elementares A
1
, A
2
e A
3
, e supondo que os objetos
envolvidos residam em memria secundria, ao retornar atividade o banco de dados estaria
em um estado refletindo uma execuo parcial de T. Neste ponto, aps executada as aes
U = ( A
3
, A
2
, A
1
) o banco de dados recairia novamente em um estado que no reflete
nenhuma ao de T, podendo retomar suas atividades normais.
O segundo requisito, S2, no exclui a possibilidade de intercalar aes elementares de
transaes diferentes sobre o mesmo banco de dados local, ou de executar paralelamente
aes elementares da mesma transao ou de transaes diferentes sobre bancos de dados
locais distintos. No entanto, o requisito S2 exige que algum controle seja exercido para que o
nvel de concorrncia permitido no destrua a idia de atomicidade da execuo das
transaes.
6.2 EXECUTANDO TRANSAES: INCIO, MIGRAO E TRMINO
Recordemos inicialmente a arquitetura para SGBDDs introduzida na Seo 1.1.3. Em um
primeiro nvel, esta arquitetura divide o SGBDD em uma coleo de SGBDs locais
interligados pelo SGBD global. Cada n da rede possui uma cpia do SGBD global. Este, por
sua vez, dividido em trs grandes componentes:
1. diretrio de dados global (DDG): contm descries dos objetos lgicos e fsicos e
dos mapeamentos entre estes;
2. gerente de transaes (GT): interpreta e controla o processamento de consultas e
transaes submetidas ao sistema;
3. gerente de dados (GD): interface com o SGBD local, fazendo as tradues necessrias
no caso de sistemas heterogneos.
- 6 -
O propsito desta seo ser apresentar em mais detalhe como um GT processa transaes.
Considere uma transao sobre um determinado banco de dados definida por um programa
em uma linguagem de alto nvel contendo comandos da LMD embebidos. Como tal, a
transao ter que passar por uma compilao inicial. Durante esta fase, os comandos da
LMD encontrados podero ser tratados de duas formas distintas. Uma estratgia seria
preparar, j nesta fase, um plano completo para sua execuo, o que equivaleria a uma
compilao prvia dos comandos. Uma segunda estratgia seria substituir cada comando da
LMD por uma chamada para o SGBDD, postergando o tratamento do comando. Em qualquer
caso, o resultado da fase de compilao ser um programa objeto contendo chamadas para o
SGBDD.
Quando a transao T chamada, o gerente de transaes do seu n de origem assume o
controle do seu processamento. O GT aciona mecanismos apropriados
antes do incio da transao
quando do trmino da transao
durante a execuo da transao
Quando do incio da transao, o gerente de transaes deve identificar a transao de
maneira unvoca. Esta identificao ser estendida a cada ao elementar executada a favor
desta transao. Desta forma, no caso de ser necessrio desfazer parte das aes elementares
associadas a uma particular transao, o gerente de transaes ter condies de faz-lo sem
problemas. Tambm importante iniciar todo um contexto apropriado do qual dependero os
mecanismos de controle de concorrncia e controle de integridade, que podero ser acionados
durante a execuo da transao.
Durante a execuo do programa-objeto que define a transao, o SGBDD chamado em
cada ponto onde havia um comando da LMD. Se a estratgia de compilao prvia no foi
adotada, o GT intersepta estas chamadas e invoca o processador de comandos da LMD para
criar um plano de execuo para o comando. Caso tenha sido, o GT apenas verifica se o
plano ainda continua vlido, refazendo-o se houve mudanas no banco de dados que o
invalide.
Um plano de execuo descrito por um programa concorrente consistindo de consultas e
atualizaes para serem executadas pelos SGBDs locais, alm de transferncias de arquivos.
Uma vez de posse do plano de execuo para o comando corrente, o GT chama o executor de
transaes, ET, para interpretar o plano. O papel do ET consiste em enviar as consultas,
atualizaes e transferncias para os ns apropriados e garantir que so executadas na ordem
correta e em paralelo, quando o plano assim o permitir.
Durante a execuo de transaes sob seu controle, o gerente de transaes interage tanto
com os mecanismos de controle de concorrncia quanto com os mecanismos de controle de
integridade. preciso que o gerente de transaes esteja atento ao fato de que recursos, do
sistema estaro sendo requisitados pelas vrias transaes em andamento. Ao conceder o uso
de determinados recursos o gerente de transaes aciona os procedimentos de controle de
concorrncia para evitar que mais de uma transao tenha acesso, simultaneamente, a
recursos que no podem ser compartilhados. Por outro lado, o prprio fato de cancelar
transaes pressupe, tambm, que o gerente de transaes mantm um histrico da
- 7 -
seqncia de aes que vo sendo executadas em favor da transao. De outra forma, pode
ser impossvel realizar a funo de controle de integridade uma vez que no haveria meios de
se inverter efeitos de aes elementares passadas. Manter este histrico tarefa dos processos
de controle de integridade com os quais o gerente de transaes deve, portanto, manter
estreito contato durante a execuo da transao.
Quando do trmino da transao, uma deciso deve ser tomada no sentido de tornar pblico
todos os efeitos das aes elementares executadas em benefcio da transao ou nenhum
deles, em cujo caso as aes elementares j invocadas devem ter seus efeitos removidos do
BD. No primeiro caso, diz-se que a transao foi confirmada reservando-se o termo
cancelada para o segundo caso. Uma transao pode terminar de forma natural ou devido a
causas excepcionais. Quando terminada de maneira excepcional, tipicamente devido a falhas
ou a incompatibilidades insolveis na repartio dos recursos do sistema, como veremos nas
sees seguintes, a transao ser sempre cancelada. Neste instante, entram em ao os
mecanismos de controle de integridade que invertero a transao, restaurando o BD a um
estado consistente de onde possa recomear suas operaes normais. Transaes tambm
podem ser canceladas mesmo estando em processamento normal. Isto pode ser visualizado
num cenrio onde transaes so executadas iterativamente e o usurio tem a opo de
simplesmente abandonar a transao antes de complet-la. Neste caso, a transao est sendo
cancelada a pedido do usurio, no devido a fatores anormais operao do sistema. claro
que os meios de controle de integridade devem, tambm neste caso, ser acionados para
garantir a consistncia do BD. Note que o processo de confirmar uma transao tambm
envolve os mecanismos de controle de integridade, pelo menos para registrar que este fato
ocorreu, evitando que uma transao j confirmada tenha seus efeitos removidos quando de
uma eventual falha posterior do sistema. Finalmente, ao trmino da transao, o gerente de
transaes deve garantir que todos os recursos apropriados temporariamente por esta
transao voltem ao controle do SGBD, sendo postos a disposio de outras transaes.
Em um cenrio distribudo os mecanismos para terminar uma transao no so simples. De
alguma forma todos os ns que se envolveram com a transao devem refletir ou remover
todos os efeitos das aes elementares executadas em favor da particular transao. Quando
do trmino da transao, portanto, protocolos especiais devem ser ativados para garantir a
atomicidade da transao como um todo, mesmo na presena de falhas repetidas e
imprevisveis que podem afetar a operao normal de vrios dentre os ns participantes. O
leitor pode imaginar as dificuldades enfrentadas por um processo distribudo cuja misso seja
obter o acrdo detodos os ns envolvidos quando uns e outros podem ser acometidos das
falhas as mais variadas. No caso centralizado este complicador simplesmente inexiste.
O problema referente confirmao/cancelamento de transaes fundamental. Em BDs
distribudos os ns participantes devem adotar um protocolo comum para que o processo se
desenvolva de forma ordenada. Uma possibilidade seria adotar o protocolo bifsico para
confirmar intenes, ou simplesmente protocolo bifsico. Existem vrias verses deste
protocolo, diferindo mais em aspectos de implementao que de filosofia bsica. Todas
seguem o esquema geral abaixo. Suponha que uma transao distribuda chegou ao ponto
onde deve ser confirmada ou cancelada. Um dos ns participantes, por exemplo o n de
origem da transao, estabelecido, "a priori", como o coordenador da operao. Este
coordenador conhecido dos demais ns e tambm dispe da identidade de todos os ns
participantes. Isto no difcil de ser conseguido durante a fase em que a transao migra de
um n para outro e dados so enviados de volta aos ns requisitantes.
- 8 -
NUMA PRIMEIRA FASE
coordenador: envia, a todos os ns participantes, mensagens na forma PREPARE-SE.
cada n participante
1. ao receber uma mensagem de PREPARE-SE vinda do coordenador, tenta
registrar em memria estvel, isto , de forma que sobreviva eventuais falhas
do sistema, os efeitos locais da transao
2. a seguir, envia ao coordenador mensagens na forma PREPARADO caso tenha
conseguido o registro em memria estvel, ou na forma IMPOSSIBILITADO
em caso contrrio
NUMA SEGUNDA FASE
coordenador
1. envia a todos os ns participantes a mensagem CONFIRME, caso deseje
confirmar a transao e todos os ns participantes tenham remetido a
mensagem PREPARADO na primeira fase;
2. em qualquer outro caso, o coordenador envia a mensagem CANCELE a todos
os ns participantes
cada n participante: ao receber o veredito do coordenador, procede de acordo com
este.
Se nenhum dos ns participantes, o coordenador ou os canais de comunicao forem
acometidos por falhas durante o processo, fcil de ver que o protocolo funciona a contento.
O Captulo 7 contm mais detalhes sobre o mtodo, bem como explora outras variantes e
filosofias que visam solucionar o problema, garantindo sempre a propriedade de atomicidade
inerente ao conceito de transao. L tambm so examinados mecanismos para se lidar com
as questes da migrao e trmino de transaes. Isto conclui a nossa descrio do
processamento de transaes neste captulo.
6.3 FALHAS NO SISTEMA
Dada a complexidade dos equipamentos e programas modernos, ponto pacfico que falhas
ocorrero, quer sejam problemas de "hardware", quer sejam defeitos de "software". Estas
falhas tm como efeito indesejvel comprometer a integridade do BD. Para que seja de
alguma utilidade prtica, O SGBD deve, portanto, incorporar mecanismos que garantam sua
integridade, quando no pelo menos na presena daquelas falhas que ocorrem com mais
freqncia. Desta forma, o SGBD pode ser mantido em operao por longos perodos de
tempo sendo, quando muito, interrompido por curtos intervalos para que os mecanismos de
controle de integridade sanem inconsistncias causadas por eventuais falhas. Esta seo
sevir de introduo rea de controle de integridade em SGBD, onde os principais
problemas e as solues mais importantes sero mencionadas de forma simplificada. Em
captulo posterior, esta problemtica ser analisada em maiores detalhes.
Intuitivamente, a nica maneira do SGBD se proteger contra falhas, que podem destruir parte
dos dados, criar e manter certa redundncia no sistema. Desta forma, quando parte do BD
- 9 -
danificado, sua "cpia redundante" pode ser revivida para recuperar os dados perdidos e
restabelecer a operao normal. Inclusive, em sistemas que requeiram alta confiabilidade, as
partes mais crticas do prprio "hardware" podem ser duplicadas de forma redundante. Note
que, se a "cpia" de um objeto no recente, ento deve-se manter tambm um histrico das
operaes efetuadas sobre este objeto, de tal modo que o SGBD possa refazer estas operaes
e trazer esta "cpia" ao estado mais recente, idntico quele da "cpia" original antes da
falha. Caso contrrio, transaes executadas entre o instante de criao da "cpia" e o
momento atual sero perdidas.
6.3.1 Tipos de Falhas
Um n qualquer, quando em operao normal, depende de um padro de interligaes
complexas entre vrios elementos. Para efeito de examinar a ocorrncia e danos causados por
falhas nestes componentes conveniente agrup-los da seguinte forma
procedimentos
processadores
memrias
no caso distribudo, comunicao de dados
Por procedimentos entende-se a totalidade dos mdulos e programas aplicativos ("software")
que compem o SGBD, podendo-se incluir aqui tambm os utilitrios do sistema operacional
usados pelo SGBD. Os processadores correspondem tanto ao processador, ou processadores,
central como as demais unidades de controle de perifricos, terminais, "modems", etc. As
memrias, onde reside o BD, aqui entendido como dados mais programas, so de crucial
importncia. l que ser acomodada toda redundncia introduzida para fins de controle de
integridade. Todos os mecanismos de proteo contra falhas prestam especial ateno ao
tratamento dispensado aos vrios tipos de memrias com que o sistema interage e, em ltima
anlise, se fiaro na boa caracterstica de resistncia a falhas que tais elementos oferecem.
Para que se possa conduzir uma anlise mais detalhada, as memrias manipuladas pelo
sistema sero subdivididas em:
memria principal
memria secundria imediatamente disponvel
memria secundria dormente
A memria principal corresponde a memria associada aos processadores, isto , memria
dos processadores centrais, memrias tipo cache, "buffers" de entrada/sada, espao de
paginao, etc. H certos tipos de falhas s quais o contedo da memria principal no
sobrevive, devendo ser considerado como irremediavelmente perdido. Estes defeitos sero
cognominados de falhas primrias. Interrupo no fornecimento de energia eltrica, defeito
nos processadores ou procedimentos do sistema podem causar este tipo de falha. Por no
sobreviver a este tipo de falha mais comum, diz-se que a memria principal voltil.
O termo memria secundria imediatamente disponvel, ou memria secundria ativa,
referem-se memria de massa, geralmente discos magnticos, onde o BD residente e que
est a disposio do SGBD a todo instante. O contedo da memria secundria ativa no
afetado por falhas primrias que o sistema venha a sofrer. Porm, panes nos cabeotes de
leitura/escrita dos discos ou partculas de poeira que assentem sobre a superfcie dos mesmos
podem danificar os delicados mecanismos dos cabeotes e provocar danos irrecuperveis
superfcie magntica destruindo, em todo ou em parte, o contedo da memria secundria
- 10 -
ativa. Isto se verificando, diz-se que o sistema sofreu uma falha secundria. Fitas magnticas
tambm podem ser usadas como memria secundria ativa, se bem que cuidados devem ser
tomados para que a eficincia do sistema no seja por demais comprometida. Partes
raramente usadas do BD, cpias antigas de parte ou da ntegra do sistema, alm de aplicativos
ativados com pouca freqncia, so candidatos naturais a residirem em fita. Nunca
dicionrios, catlogos e outros elementos freqentemente acessados.
Como um ltimo recurso, e em casos realmente catastrficos, o controle de integridade do
SGBD pode apelar para a memria secundria dormente ("off-line"). Entende-se como
memria secundria dormente toda memria fisicamente desconectada do sistema.
Geralmente, devido sua grande capacidade de armazenamento de dados, fitas magnticas
so empregadas para este fim. Em BD de grandes propores, toda uma fitoteca pode ser
necessria. comum armazenar os componentes da memria secundria dormente em locais
prprios, distantes do centro onde opera o sistema. A preocupao bsica evitar que
catstrofes sobre um dos lugares, tais como incndios ou furtos, no afete o outro. De
qualquer maneira, eventos que destruam ou inutilizem o contedo da memria secundria
dormente do sistema sero chamados de falhas tercirias.
Existem situaes que exigem aes por parte do sistema de controle de integridade do BD,
embora no se configurem propriamente como falhas em componentes do sistema. O caso
tpico quando, sob operao normal, surje a necessidade de se cancelar transaes. Isto
pode ocorrer tanto por erro ou a pedido do usurio, como podem ser aes foradas pelo
SGBD como ltima instncia para evitar bloqueio na execuo de transaes que competem
por certos recursos do sistema. Estes casos sero rotulados como pseudo-falhas do sistema.
Agora, no est em cheque o contedo de nenhuma das memrias ou a sanidade dos
processadores ou procedimentos associados ao sistema. A cooperao do controle de
integridade, porm, necessria para invocar a transao que inverte o efeito das aes
elementares executadas em benefcio da transao a ser cancelada. Deste modo, o BD
permanece em um estado consistente, alm do que forada a liberao dos recursos que
foram seqestrados pela transao.
A discusso acima desloca-se a partir de falhas nos componentes mais nobres, isto , com
menor tempo de acesso, para os menos nobres, com tempos de acesso consideravelmente
maiores. importante ter em mente uma noo da freqncia com que os vrios tipos de
falhas costumam ocorrer na prtica, bem como do tempo necessrio para que o controle de
integridade restaure a operao normal do BD em cada caso.
A Figura 6.1 resume a situao.
TIPO DA FALHA FREQNCIA TEMPO DE RECUPERAO
Pseudo-falha vrias por minuto milisegundos
Primria vrias por ms segundos
Secundria vrias por ano minutos
Terciria uma por sculo dias
Figura 6.1 - Caractersticas de Falhas
Est implcito aqui que o SGBD pode, ao ser reconduzido operao normal, detectar que
uma falha primria causou a interrupo das operaes. Ao voltar vida, o SGBD acionaria o
- 11 -
controle de integridade para levar o BD a um estado consistente. Falhas secundrias tambm
seriam detectadas pelo SGBD que interromperia momentaneamente suas operaes normais e
acionaria o controle de integridade. A deteo de falhas tercirias ficaria a cargo de
operadores externos ao SGBD os quais, uma vez verificado o problema, rodariam processos
especficos que eventualmente restaurariam a memria dormente do sistema.
Outra suposio importante diz respeito a freqncia ou probabilidade de cada tipo de falha.
Ser sempre suposto que os vrios componentes do sistema tm modos de falha
independentes, de tal modo que so praticamente negligenciveis as chances de que ocorrero
efeitos cascata com uma falha provocando outra. Mais ainda, a probabilidade de dupla falha,
isto , de falhas simultneas, torna-se desprezvel.
No caso de BD distribudos, h ainda o complicador adicional de que a rede comunicao de
dados ou os protocolos de comunicao de dados podem, um ou ambos, falhar. Isto
ocorrendo, diz-se que o sistema sofreu uma falha de comunicao de dados ou simplesmente
uma falha de comunicao. Como alertado no Captulo 1, o sistema de comunicao de
dados ser suposto perfeito do ponto de vista de que mensagens no so perdidas, danificadas
ou entregues a destinatrios errados. Existem mecanismos prprios para se atingir tais
objetivos, mecanismos estes que fogem ao escopo deste texto. Sob a tica do SGBD, porm,
estes processos so totalmente transparentes. O SGBD apenas coloca mensagens, isto ,
endereos mais contedos, nos "buffers" de sada e supe que mensagens podem
materializar-se em seus "buffers" de entrada. O primeiro complicador encontrado diz respeito
detectabilidade de falhas de comunicao. Torna-se extremamente difcil, se no
impossvel, para um particular n da rede descobrir se o outro n, com o qual deseja se
comunicar, no responde porque a comunicao foi cortada por uma falha de comunicaes
ou se o outro n est simplesmente sobrecarregado e, portanto, muito lento ao responder.
Note que um dado n no pode simplesmente continuar a retransmitir mensagens, sem tomar
nenhum cuidado adicional, at que o n destinatrio finalmente se manifeste. Sob este
cenrio, uma mesma transao poderia executar repetidas vezes no ambiente remoto.
Focalizando o problema de falhas sob o ponto de vista dos objetos envolvidos, pode-se
caracteriz-los como objetos volteis, estveis ou reais.
No primeiro grupo situam-se os objetos cujos valores no sobrevivem a falhas primrias. O
exemplo tpico dado pelos objetos que residem na memria primria do sistema. No grupo
intermedirio esto todos os objetos cujos valores sobrevivem a falhas primrias mas no a
falhas secundrias. Aqueles objetos residindo em memria secundria imediatamente
disponvel classificam-se como tal. Finalmente, no terceiro e ltimo grupo so encontrados
objetos cujos valores, uma vez modificados, escapam ao controle do SGBD. Numa transao
envolvendo um caixa bancrio automtico, uma vez dispensando um certo nmero de
cruzeiros, estes cruzeiros existem e esto fora do alcance do SGBD.
A prxima subseo abordar, de forma simplificada, os mecanismos usados para garantir o
controle de integridade do BD enquanto que o Captulo 9 detalhar as estruturas e algortmos
usados nos mtodos mais importantes para efetivar esta funo.
6.3.2 Proteo Contra Falhas
Como foi visto na subseco anterior, os mais variados tipos de falhas podem se abater sobre
o BD, cobrindo todo um espectro que vai desde situaes amenas e imediatamente
contornveis at catstrofes que deixam marcas irrecuperveis, destruindo dados e
procedimentos do sistema. O problema agravado pela imprevisibilidade das falhas e, ainda,
- 12 -
pelo fato de que novos desarranjos podem advir enquanto o SGBD est se recuperando de
outros anteriores, caracterizando mltiplas falhas simultneas. importante notar, desde j,
que no h proteo total e cabal contra todas as falhas que eventualmente podem vir a
perturbar o sistema. O que os mecanismos de proteo visam tornar o SGBD mais e mais
confivel e seguro a medida que se tornam mais sofisticados. No entanto, casos patolgicos
sempre podero ser imaginados de tal forma que no possam ser tratados a contento pelos
mecanismos de proteo. No deve ser esquecido, tambm, o aspecto da eficincia do SGBD
como um todo. Dispor de um sistema extremamente seguro e confivel, porm a um custo
absurdamente alto, inviabiliza o prprio SGBD, na medida em que no ser posto em
operao devido a sua impraticabilidade. Todo o desafio est em se imaginar tcnicas,
estruturas e procedimentos que dem proteo razoavelmente eficaz contra as falhas mais
observadas na prtica e que sejam, por outro lado, suficientemete expeditos de modo a no
causar impacto por demais negativo nas atividades do usurio.
Os vrios mecanismos de proteo podem tambm ser dicotomizados segundo propiciem ou
no certa robustez contra falhas. Muitos mecanismos provem simplesmente proteo aos
dados e procedimentos do SGBD, isto , ao ocorrer uma falha, o SGBD impede a utilizao
do BD enquanto aciona os mecanismos de proteo de que dispe na tentativa de restaurar
um estado consistente quando, ento, permite novamente que usurios continuem seu
trabalho. Outros mtodos detetam a ocorrncia de certos tipos de falhas e, de forma
transparente ao usurio, ativam mecanismos corretores os quais reparam os eventuais danos
causados, propiciando uma certa robustez a estes tipos de falhas.
Na presente subseco sero abordados, a nvel descritivo, os mtodos mais importantes para
controle de integridade. Alguns so de concepo muito simples e dispensam maiores
comentrios. Outros, mais sofisticados, sero detalhados no Captulo 9. Dada a pletora de
mtodos hoje desenvolvidos, a classificao abaixo um tanto arbitrria e algumas das
tcnicas poderiam ser reagrupadas de formas diferentes. Mais ainda, muitos dos mtodos s
garantem a integridade do BD contra certos tipos de falhas. comum, portanto, que o SGBD
disponha de vrias estratgias a seu alcance e procure us-las de forma orquestrada visando
cobrir um amplo espectro de falhas. Tambm, controlar vrios mtodos distintos permite ao
SGBD criar um certo sinergismo ao explorar particularidades dos mtodos e, assim, torn-los
mais eficientes e eficazes do que se operados individualmente.
Programas Restauradores
Uma das primeiras estratgias que vem a mente incorpora o conceito de um programa
restaurador. Estes programas simplesmente revem todos os dados do BD aps a ocorrncia
de um desarranjo e tentam salvar o que for possvel. Arquivos podem ser perdidos no
processo se o algoritmo decidir que no pode recuper-los. O programa tenta, entretanto,
deixar o BD em um estado consistente, embora no completo, no sentido de que os dados
sobreviventes satisfazem os requisitos de consistncia do BD enquanto no h garantias de
que parte dos dados no sejam eliminados.
A situao tpica quando programs restauradores so ativados se d em SGBDs onde os
algortmos empregados em operao normal no garantem a consistncia dos dados na
memria secundria ativa, a cada instante. Se o SGBD acometido por uma falha primria
quando est justamente no processo de transferir dados da memria principal para a memria
secundria ativa o contedo da primeira destrudo, impedindo que a operao seja
- 13 -
completada. Neste ponto, a memria secundria ativa, ainda no tendo sido completamente
atualizada, representa um estado inconsistente do BD. O programa restaurador vai, ento,
examinar os arquivos da memria secundria ativa e tentar, de alguma forma, torn-los
consistentes. fcil de imaginar situaes onde os dados da memria principal, destrudos
quando da ocorrncia da falha, sejam de tal forma crticos que a nica alternativa seria o
programa restaurador eliminar parte dos dados residentes na memria secundria ativa a fim
de trazer todo o DB a um estado consistente.
Programas restauradores normalmente entram em ao como um ltimo recurso ou na
ausncia de mecanismos apropriados para contornar certos tipos de falhas. Embora seja um
mecanismo primitivo de controle de integridade, o programa restaurador pode se tornar
atraente em BDs simples que implementem estruturas pouco sofisticadas. Isto tanto mais
verdade quando os dados que possam eventualmente vir a serem perdidos estiverem
disponveis em outras formas, de tal modo que as operaes possam ser rapidamente refeitas,
recuperando todo ou boa parte do que o programa restaurador no conseguiu salvar. Uma
descrio mais detalhada destes programas dependeria fortemente da particular concepo de
cada BD e, por isto, no ser tentada neste texto. H, porm, sistemas reais que se valem
deste recurso em maior ou menor extenso. O leitor encontrar exemplos de tais sistemas na
Figura 6.2 e nas notas bibliograficas no final do captulo.
Descargas
Aqui, novamente, a idia bsica bastante simples. Periodicamente, o contedo de toda a
memria secundria ativa descarregado (evitando o anglicismo "dumped") para outros
dispositivos ativos, geralmente fitas magnticas, que so em seguida arquivadas como
memria secundria dormente. Ocorrendo uma falha secundria, e outros mecanismos de
restaurao mais eficientes no operando a contento, o SGBD sempre pode apelar para esta
cpia arquivada e retornar a um estado consistente, anterior, do BD. Apenas falhas tercirias
podem afetar as cpias arquivadas. Note que se estas se constituem nos nicos objetos de que
se pode valer o SGBD para voltar normalidade, ento todas as transaes invocadas desde o
incio da descarga e o momento de ocorrncia das falhas sero perdidas. Nenhum trao de sua
existncia, mesmo daquelas que foram confirmadas, ser notado aps a recuperao do
sistema. Em muitos casos, isto pode ser intolervel. Mtodos apoiados em descargas do BD
so, portanto, candidatos naturais para se aliarem a outras estratgias que tentam remediar
este defeito, mantendo algum tipo de registro das atividades que ocorrem no hiato entre a
obteno de duas descargas consecutivas. Uma variao bvia consiste em se descarregar no
todo o BD, mas apenas as partes do BD que tenham sido afetadas desde a ltima descarga.
Este processo conhecido como descarga incremental. Descargas, como tcnica de controle
de integridade isolada, no sero descritas em maiores detalhes. Entretanto, alguns mtodos
mais sofisticados que empregam descargas, de uma forma ou outra, sero pormenorizados no
Captulo 9, onde, ento, tornado explcito o papel desempenhado pelas descargas no mtodo
como um todo.
Note que a periodicidade com que as cpias so obtidas deve ser analisada com cuidado.
Quanto mais freqentes, tanto mais eficazes sero no combate a falhas secundrias, visto que
representam um estado mais recente do BD em relao ao momento de ocorrncia da falha.
Por outro lado, maior freqncia implicar em maior degradao do tempo de resposta do
sistema, especialmente se o BD for de porte avantajado. O ajuste final dever ser feito
levando-se em conta quo susceptvel o sistema aos vrios tipos de falhas combatidas
atravs destas tcnicas.
- 14 -
H duas maneiras principais de se obter descargas, segundo o SGBD interrompe ou no suas
atividades normais enquanto a descarga obtida. Um mtodo vlido seria o SGBD
determinar, num dado momento, que por ora no aceitaria novas transaes. Aps aguardar
que todas as transaes iniciadas antes deste instante fossem completadas, o SGBD acionaria
os procedimentos prprios para obter a descarga desejada. Em seguida, retornaria a operao
normal aceitando novas transaes. Este processo ser rotulado de descarga esttica. Como
alternativa, o prprio SGBD poderia eleger algumas das transaes correntes para serem
canceladas, evitando esperar que completassem. No caso distribudo esta alternativa deve ser
abordada com cautela, visto que cancelar transaes que migraram para outros ns pode
onerar sobremaneira o sistema. A principal desvantagem est, claro, no fato do sistema se
tornar indisponvel entre o incio e trmino da descarga. Em contrapatida, pagando-se em
complexidade quanto aos algortmos usados, pode-se elaborar mecanismos que obtenham
uma descarga dinmica do BD. A cpia obtida dinamicamente, com o sistema ainda
disponvel, talvez com um tempo de resposta ligeiramente dilatado. Os algortmos devem
garantir, entretanto, que o BD congelado em um dado instante T de tal modo que apenas
transaes confirmadas antes de T tero seus efeitos refletidos na cpia obtida, enquanto que
no deixado trao algum das demais. No Captulo 9 ambos estes mecanismos sero
examinados em maiores detalhes, visto que integram outros mtodos de controle de
integridade mais elaborados.
Arquivos Diferenciais
Esta tcnica adota a filosofia de coletar todas as modificaes efetuadas contra certas
entidades do BD, em particular arquivos de dados, em estruturas prprias, especificamente
planejadas para este fim, mantendo os valores dos objetos originalmente associados a estas
entidades inalterados. Estas estruturas, onde as modificaes so agrupadas, recebero o
cognome de arquivos diferenciais. Tudo se passa como se o SGBD, ao concentrar
modificaes sobre os arquivos diferenciais, atrasasse o momento de tornar irreversvel o
efeito de aes elementares sobre o BD, mesmo daquelas correspondentes a transaes que j
foram confirmadas. A vantagem pretendida bvia. Os originais formam, naturalmente, uma
cpia que reflete um estado completo e consistente anterior do BD. Ocorrendo uma falha que
venha a prejudicar os arquivos diferenciais tudo que o SGBD tem a fazer reler da memria
secundria ativa os originais intactos, eventualmente disperdiando os trabalho das ltimas
transaes invocadas. Porm, se o usurio j foi informado de que derminada transao
confirmou, ignor-la neste ponto pode bem ser inadmissvel. Para maior segurana, os
originais e os respectivos arquivos diferenciais podem ser mantidos em dispositivos fsicos
distintos. Descarregando os originais em memria secundria dormente protejer o BD contra
quaisquer falhas secundrias.
No entanto, em algum ponto no tempo, os arquivos diferenciais tero que ser usados para
reconstruir os originais, processo este que pode ser oneroso. Mais ainda, ao acessar dados o
SGBD deve pesquisar, antes, se os objetos desejados no se encontram nos arquivos
diferenciais, incorrendo, assim, numa perda de eficincia. Duplicar os arquivos diferenciais
em memria secundria ativa, em unidades fsicas diferentes, pode, portanto, degradar ainda
mais o sistema a ponto de inviabilizar a idia na maioria dos casos. Alguns mecanismos
engenhosos e tcnicas especiais usadas na organizao dos arquivos diferenciais permitem
minimizar este problema. Note, em especial, que aes elementares que remodificam o valor
de um objeto que j est no arquivo diferencial no necessitam de criar um novo registro para
este particular objeto. Basta alterar o contedo do registro que l se encontra. Aes
elementares cujo efeito seja a remoo de um objeto so igualmente simples de serem
implementadas. A seu favor, este mtodo tem o fato de que facilita bastante a operao de
- 15 -
obter-se descargas incrementais do contedo do BD pois basta descarregar os arquivos
diferenciais os quais so, em princpio, bem menores que os originais.
Atas
Imagine um SGBD onde o conceito de transao permeia toda sua organizao, isto ,
transaes so as unidades bsicas de trabalho do sistema. Falhas, ocorrendo em momentos
imprevisveis, colhero algumas transaes em andamento, porm ainda no completadas,
isto , no confirmadas ou canceladas. Ao voltar a cena, o SGBD deve, portanto, desfazer
todos os efeitos parciais registrados por cada transao que ainda no completou at o
instante de ocorrncia da falha. Para que isto possa ser levado adiante, cada ao elementar
deve registrar, em uma ata (em ingls "log" ou "audit trail"), os valores iniciais e finais de
cada objeto modificado, bem como deixar claro em benefcio de que transao esta ao
elementar foi invocada. Normalmente, a ata reside na memria secundria ativa. Ocorrendo
uma falha primria, tudo que o SGBD precisa fazer consultar a ata e
refazer transaes confirmadas cujo efeito ainda no tenha sido registrado na memria
secundria ativa;
desfazer transaes canceladas cujo efeito j foi registrado em memria secundria ativa;
desfazer transaes que ainda estavam em andamento quando do instante de ocorrncia
da falha.
Note que tambm deve ir para a ata um registro de incio e trmino para cada transao
executada. Assim, os mecanismos de controle de integridade do SGBD teriam condies de
identificar todas as transaes em andamento a cada instante, bem como no teriam
dificuldades em agrupar e associar aes elementares que correspondam a uma mesma
transao. A prpria ordem seqencial em que aparecem os registros de aes elementares na
ata se presta muito bem a refazer/desfazer transaes.
Observe que atas devem residir em memria secundria ativa, visto serem estruturas muito
solicitadas uma vez que a invocao de cada ao elementar deixa l um registro. J uma
falha que destrua parte da memria secundria ativa, afetando segmentos da ata, provocaria
uma catstrofe no sistema. Transaes confirmadas cujos efeitos no foram ainda registrados
sobre os respectivos objetos simplesmente desapareceriam, uma vez ser a ata o nico registro
destas transaes capaz de fornecer informaes suficientes para que sejam refeitas. Atas
propiciam um meio de se restaurar o BD ao estado completo mais recente com relao ao
ponto de ocorrncia da falha. A se manter este requisito, o dilema est em se imaginar
estruturas eficazes que o satisfaam, mesmo na presena de falhas secundrias que podem
destruir parte da ata. Uma alternativa duplicar a ata em memria secundria ativa de tal
modo que as duas "cpias" residam em dispositivos fsicos distintos. Como estamos supondo
que a ocorrncia de falhas so eventos independentes, isto minimizaria as chances de que
partes da ata sejam perdidas. O preo, claro, seria comprometer o tempo de resposta ainda
mais. Em princpio, pode-se tornar o mecanismo to confivel quanto se queira atravs da
duplicao, triplicao, etc., da ata em unidades distintas.
Um problema mais sutil diz respeito ao sincronismo entre a entrada de registros na ata e a
alterao de valores de objetos na memria secundria ativa. Um bom procedimento seria
adotar um protocolo para uso da ata que garantisse a catalogao de cada ao elementar
antes de registrar seus efeitos em memria secundria ativa. Para apreciar que tipo de
problemas podem surgir, considere a seqncia de passos abaixo, usualmente seguidos pelo
- 16 -
SGBD ao manipular objetos do BD local:
1. determina se a pgina onde reside o objeto em questo est presente na memria
principal;
2. se no estiver, aciona o sistema operacional local para que este leia a pgina necessria da
memria secundria ativa para a memria principal;
3. perfaz as alteraes desejadas no valor do objeto, reconstruindo a pgina em que este
reside, na memria principal;
4. torna a acionar o sistema operacional local para que este reescreva a pgina atualizada da
memria principal para a memria secundria ativa, quando ento as modificaes se
tornam permanentes;
5. registra a ocorrncia desta ao elementar na ata, alm de associ-la transao
correspondente.
Suponha que uma falha colha o sistema no hiato entre os passos 4 e 5 da seqncia acima.
Neste caso, a situao se tornaria confusa pois o SGBD no teria condies de inverter a ao
elementar que alterou o contedo desta pgina, dado que no haveria registro algum de sua
invocao.
Observe que, se tomada isoladamente, a ata teria que registrar todas as aes elementares
efetuadas contra o BD desde que este foi criado. Esta situao remediada com o emprego de
descargas. A ltima descarga obtida seria revivida e, ao se ler a ata, todas as transaes que
porventura completaram antes da descarga ter sido iniciada poderiam ser ignoradas. As
demais seriam refeitas ou desfeitas, de acordo com a respectiva situao no instante de
ocorrncia da falha. Como pode ser visto, descargas complementam naturalmente tcnicas de
controle de integridade que operam atravs de atas. Neste caso especfico, descargas sero
conhecidas por balizadores (do termo em ingls "checkpoints"). Uma vez sabendo-se que as
descargas operaro em estreita cooperao com as atas, possvel otimizar o tempo de
resposta quando as primeiras esto sendo obtidas, dispensando-se certas informaes
redundantes.
Na realidade, a situao um pouco mais complexa do que pode deixar transparecer a
discusso acima. Detalhes do mecanismo sero examinados no Captulo 9.
Imagens Transientes
Imagine que o BD seja composto por um certo nmero de pginas de tamanho fixo e que a
memria secundria est dividida em setores do mesmo tamanho que as pginas.
Conforme j foi ressaltado anteriormente, aes elementares manipulam objetos do BD, que
sero identificados, para propsito desta discusso, com as pginas de memria. Uma
transao modificaria, possivelmente, um certo nmero destas pginas, caso confirmada.
claro que quaisquer alteraes na memria secundria ativa s podem ser efetivadas se a
pgina for construda na memria principal e, posteriormente, reescrita em memria
secundria ativa. Quando a pgina modificada repassada para a memria secundria ativa,
porm, tem-se duas alternativas:
- 17 -
1. reescrever a pgina reconstruda sobre o setor que ocupava inicialmente, destruindo, por
conseguinte, seu contedo original;
2. reescrever a nova pgina sobre um setor livre em memria secundria ativa, mantendo
seu contedo original inalterado.
As tcnicas de controle de integridade examinadas at o momento operavam na hiptese de
que o SGBD adotava o mecanismo do item 1 acima. Idias que exploram a metodologia do
item 2 seguem o esquema geral abaixo.
Ao modificar a pgina proceda da seguinte forma:
1. leia a pgina i da memria secundria ativa para a memria principal, caso esta l ainda
no se encontre; seja k o endereo desta pgina na memria principal;
2. modifique, na memria principal, valores de dados residentes nesta pgina;
3. encontre um setor livre, seja s, na memria secundria ativa;
4. reescreva a pgina i na memria principal sobre o setor de endereo s na memria
secundria ativa;
5. altere o diretrio de pginas, indicando que a pgina i se encontra agora no setor s;
6. libere o setor ocupado originalmente pela pgina i.
Visto de um certo ngulo, estas tcnicas criam uma imagem transiente com as modificaes
desejadas, enquanto mantm a imagem certificada inalterada. Contrastando com a tcnica de
arquivos diferenciais, porm, as imagens transientes so efmeras, substituindo,
imediatamente aps escritas na memria secundria ativa, as imagens originais a partir das
quais foram criadas. Obviamente, no caso do sistema sofrer uma falha primria durante a
execuo dos passos acima, as imagens originais estariam ainda intactas, alm de
representarem um estado consistente recente do BD.
Sero descritas duas maneiras de se implementar os mecanismos de imagens transientes:
atravs de vetores de ponteiros e atravs de listas de intenes.
No esquema de vetor de ponteiros o BD suposto formado por um conjunto de segmentos
divididos em pginas. O i-simo segmento dispe de um vetor de ponteiros, V
i
, que d os
setores que contm as suas pginas. Afora estes vetores, o mecanismo usa 2 vetores de "bits".
Em um deles, MAP, o i-simo "bit" representa a situao do i-simo setor da memria
secundria: 1 equivale a ocupado e 0 a livre. No outro vetor, EST, o j-simo "bit" indica a
situao do i-simo segmento: 1 se h transaes manipulando pginas deste segmento e 0
em caso contrrio. Alterar a j-sima pgina do i-simo segmento corresponde a
verificar se o i-simo segmento j est sendo manipulado, consultando o "bit" EST(i);
se no, copiar o diretrio do i-simo segmento em outro vetor, V'
i
, em memria
secundria;
se preciso, trazer o setor de endereo V
i
(j) = s para a memria principal;
efetuar as modificaes desejadas na pgina residente na memria principal;
procurar um setor livre na memria secundria ativa, consultando o vetor MAP. Seja s' o
endereo do setor encontrado;
- 18 -
reescrever a pgina modificada, na memria principal, para o setor de endereo s', na
memria secundria ativa;
preparar o setor de endereo s' para substituir o original, no endereo V
i
(j),
intercambiando os valores de V
i
(j) e s' ;
por motivo de segurana, copiar o vetor MAP para outro vetor, MAP';
efetivar as alteraes mudando MAP(s) para 0 e MAP(s') para 1;
Observe que, nos passos 2 e 8, so tomadas precaues para que, em caso de falha, o SGBD
possa restaurar seu estado anterior simplesmente copiando os vetores MAP' e V'
i
sobre os
vetores MAP e V
i
, respectivamente.
Uma variao deste primeiro esquema ser discutida em detalhe na Seo 9.2.
No segundo esquema, o processo ligeiramente diferente. Suponha que cada arquivo Q do
banco esteja dividido em pginas e que o banco possua um diretrio D indicando que setores
contm as pginas de Q. Uma transao, T, prossegue normalmente, alterando pginas de
acordo com o mesmo princpio de criar imagens transientes destas pginas. Suponha que a
transao manipulou dados e que, para isto, alterou pginas de Q com endereos P
1
,, P
n
. O
endereo do setor contendo a imagem original da pgina P
k
i
k
e o endereo do setor
contendo a imagem transiente de P
k
j
k
. Para finalizar, deve-se executar as aes A
k
= D(k)
:= j
k
, representando as operaes de atribuio necessrias atualizao de D. A lista de
aes L = (A
1
,, A
n
) chamada de lista de intenes para T.
Esquematicamante, T executa de acordo com o plano abaixo.
1) Na fase de execuo
a) T invoca cada uma de suas aes elementares, criando imagens transientes de
P
1
,,P
n
b) T cria, no processo, a lista de intenes L
2) Na fase de confirmao
a) T escreve L em memria secundria ativa
b) T executa L
c) Libera o espao ocupado por L em memria secundria ativa.
Portanto, se falhas primrias ocorrerem antes do passo 2, T simplesmente ignorada quando
o SGBD, ao retornar vida, se depara com o diretrio D inalterado em relao ao estado
anterior. Aps o passo 2a, T ser confirmada e falhas primrias no podem alterar este fato.
Uma propriedade muito desejvel est, obviamente, embutida no mecanismo: repetidas
execues de L, mesmo parciais, surtiro efeito equivalente a uma nica execuo de L. Isto
assegura que, se o sistema for acometido por uma falha primria enquanto ainda est se
recuperando de outra anterior, a transao ser, sempre, corretamente confirmada.
O caso de um BD distribudo apresenta complicaes caractersticas. Um determinado n
deve substituir as imagens certificadas pelas transientes ou, conforme o caso, executar a lista
de intenes de uma transao, se e somente se todos os demais ns que atuaram em
- 19 -
benefcio da transao atingirem um concenso neste sentido. Aqui poder-se-ia usar o
protocolo bifsico para se atingir um entendimento entre os ns participantes.
Muitas variaes podem ser construdas usando-se as mesmas idias bsicas. Por exemplo,
manter-se duas cpias de cada arquivo do BD a cada instante, uma delas servindo de reserva
caso a outra seja danificada por falhas. Modificaes seriam refletidas em ambas as cpias
imediatamete aps cada ao elementar executada. Para evitar inconsistncias por ocasio de
eventuais falhas, cada cpia disporia de um "bit" cuja funo seria indicar que a operao de
atualizao est em progresso sobre a respectiva cpia, evitando que esta fosse usada como a
cpia de reserva a ser usada quando o SGBD se recuperasse de falhas. Assumindo que este
"bit" sempre resiste a todos os tipos de falhas que se pretende contornar com este mecanismo,
o SGBD sempre resgataria um estado consistente anterior quando voltasse operao normal
aps uma falha. Esta e outras variaes possveis no sero discutidas em maiores detalhes no
texto que segue.
6.3 CONTROLE DE CONCORRNCIA
Um SGBD, suportando bancos de dados com vrias aplicaes, dever necessariamente
permitir acesso concorrente aos dados. intuitivo que, em tese, quanto maior for o nvel de
concorrncia permitido, tanto melhor ser o tempo de resposta do sistema como um todo. Em
tese porque, forosamente, os mecanismos que controlam o acesso concorrente ao banco
impem um nus adicional sobre o desempenho do SGBD. Os procedimentos que
harmonizam o paralelismo no seio do SGBD sero conhecidos por mecanismos de controle
de concorrncia.
Num cenrio de BDs distribudos, ou mesmo de BDs centralizados com acesso distribudo, a
implementao de paralelismo torna-se uma necessidade imperiosa. Com relao ao caso
centralizado, hoje so conhecidas tcnicas que equacionam os problemas a contento, apoiadas
em um tratamento terico preciso e confirmadas por implementaes reais. No que concerne
ao caso distribudo, a situao mais confusa. Isto devido, em grande parte, ao fato de que
os ns da rede operam de forma bastante independente, embora o controle de concorrncia
deva ser efetivado de forma global, abrangendo informao que pode estar espalhada por
vrios ns. Aqui, muitos dos aspectos do problema ainda se encontram em fase de pesquisa e
experimentao.
Nesta seo sero apresentados os problemas fundamentais a respeito de controle de
concorrncia bem como sero descritos, de forma suscinta, alguns algortmos usados para
solucion-los. No Captulo 8 estas questes sero examinadas em profundidade.
No que tange ao restante desta seo, ser suposto que o sistema nunca falha, a no ser
quando explicitamente dito em contrrio. Equivalentemente, suficiente supor que as
tcnicas para controle de integridade, expostas na seo anterior, sejam adequadas para
contornar eventuais falhas de maneira satisfatria e transparente. Na realidade, claro, ambos
os mecanismos devem operar de forma integrada. A hiptese acima colocada simplesmente
para isolar os problemas.
6.3.1 Colocao do Problema
Quando transaes manipulam dados concorrentemente, certos problemas, chamados de
anomalias de sincronizao, podero ocorrer. Exemplos so acessos a dados inconsistentes,
perdas de atualizaes e perda da consistncia do banco. Por exemplo, considere duas
- 20 -
transaes, T
1
e T
2
, ambas debitando uma determinada quantia a um saldo S. Seja a seqncia
de aes:
1) T
1
l o saldo S;
2) T
2
l o saldo S;
3) T
2
debita a quantia, escrevendo o novo valor de S;
4) T
1
debita a quantia, escrevendo o novo valor de S;
O valor final do saldo neste caso refletir apenas a quantia debitada por T
1
, sendo a
atualizao submetida por T
2
perdida.
O exemplo acima tambm serve para ilustrar porque controle de concorrncia, embora
semelhante, no equivalente ao dilema de gerenciar acesso a recursos partilhados em um
sistema operacional. De fato, na seqncia acima, cada transao respeita o princpio de
acesso exclusivo ao objeto partilhado S. Porm, isto claramente no suficiente pois uma
atualizao perdida. Assim sendo, um mecanismo de controle de concorrncia no dever
se limitar a implementar acesso exclusivo a objetos do banco de dados.
O problema fundamental a ser resolvido pelos mtodos de controle de concorrncia
colocado da seguinte forma. Assuma que todas as transaes preservam a consistncia lgica
do banco de dados e terminam, quando executadas seqencialmente. Um mtodo de controle
de concorrncia dever, ento, garantir que em toda execuo concorrente das transaes:
1) cada transao termina;
2) cada transao executada sem interferncia das outras, e sem que anomalias de
sincronizao ocorram.
Estes objetivos devero ser atingidos permitindo-se um mximo de concorrncia possvel, de
forma transparente para os usurios, e para qualquer conjunto de transaes acessando
qualquer parte do banco de dados.
Note que o controle de concorrncia e a gerncia de transaes so tarefas que se
complementam. Cabe ao gerente de transaes escalonar as aes de uma transao de tal
forma que esta seja processada corretamente, conforme a especificao do usurio. Por outro
lado, cabe ao mecanismo de controle de concorrncia arbitrar a intercalao das aes de
transaes diferentes de tal forma a que todas as transaes terminem, sejam processadas sem
que uma interfira com a outra e sem que anomalias de sincronizao ocorram.
O resto desta subseo abordar em mais detalhe o critrio de correo imposto aos
mecanismos de controle de concorrncia.
A idia do critrio de correo comumente aceito bem simples. Seja T um conjunto de
transaes. Inicialmente observa-se que uma execuo seqencial ou serial das transaes em
T, ou seja, uma execuo em que as transaes so processadas uma aps a outra terminar,
em uma ordem qualquer, necessariamente correta. Isto fcil ver pois em uma execuo
serial no h processamento concorrente.
O prximo passo postular que uma execuo concorrente E das transaes em T ser
considerada correta se for computacionalmente equivalente a alguma execuo serial das
transaes. A execuo E ser chamada neste caso de serializvel. A noo de equivalncia
- 21 -
computacional usada aqui exige que o estado final do banco de dados seja o mesmo em E e S
e que as transaes leiam os mesmos dados em E e S (assumindo que E e S comeam no
mesmo estado inicial do banco de dados) e, portanto, executem a mesma computao em E e
S.
A postulao deste critrio de correo para execues concorrentes justificada pois, como
S serial, as transaes em T so naturalmente executadas sem que uma interfira com a outra.
fcil justificar que anomalias de sincronizao no ocorrem em S. Como E
computacionalmente equivalente a S, as transaes so executadas em E sem que uma
interfira com a outra e sem que anomalias de sincronizao ocorram. Os prximos exemplos
ilustraro estes conceitos.
Suponha que P e C representem os saldos da poupana e da conta corrente de um
determinado cliente (armazenadas em um banco de dados centralizado, por simplicidade).
Considere duas transaes cujos efeitos desejados so:
T
1
: se houver saldo suficiente na poupana, transfira $5.000,00 da poupana para a conta
corrente;
T
2
: se houver saldo suficiente na conta corrente, debite um cheque de $10.000,00.
Suponha que a seqncia de aes elementares sobre o banco de dados gerada pela execuo
da transao T
1
(supondo que haja saldo suficiente) seja:
T
11
: leia o saldo P para X;
X := X - 5.000;
T
12
: leia o saldo C para Y;
Y := Y + 5.000;
T
13
: escreva o novo saldo Y em C;
T
14
: escreva o novo saldo X em P.
Apenas aquelas aes que acessam o banco de dados receberam rtulos pois so estas que
nos interessaro a seguir. Suponha que a seqncia de aes elementares sobre o banco de
dados gerada pela execuo da transao T
2
(supondo que haja saldo suficiente) por sua vez
seja:
T
21
: leia o saldo C para Z;
Z := Z - 10.000;
T
22
: escreva o novo saldo Z em C.
Primeiro considere uma execuo puramente serial em que T
2
processada antes de T
1
. Esta
execuo pode ser abstrada pela seguinte seqncia de rtulos das operaes sobre o banco
de dados:
S = T
21
T
22
T
11
T
12
T
13
T
14
Considere agora uma execuo concorrente abstrada pela seguinte seqncia de rtulos:
L = T
11
T
21
T
22
T
12
T
13
T
14
- 22 -
Esta execuo L no serial, porm serializvel por ser equivalente a S. Isto fcil de ver
pois a ao T
11
em L pode ser comutada com T
21
e T
22
sem que o resultado do processamento
de T
1
seja alterado e sem que o estado final do banco de dados seja modificado. De fato, T
11
l o saldo P enquanto as aes de T
2
afetam apenas o saldo C. Logo, T
11
l o mesmo saldo P
em L e em S.
Por fim, considere uma execuo concorrente abstrada pela seguinte seqncia de rtulos:
N = T
11
T
12
T
21
T
22
T
13
T
14
Esta execuo N no serial e tambm no serializvel por no ser equivalente nem a S,
nem a uma execuo serial S em que T
1
processada antes de T
2
. De fato, T
12
l o saldo
inicial C, que posteriormente escrito por T
13
. Desta forma, a atualizao expressa por T
2

perdida e o banco de dados final (em N) no reflete a execuo de T
2
. Logo N no pode ser
equivalente S ou S, ou seja, no serializvel.
6.3.2 Mtodos de Controle de Concorrncia
Nesta subseo sero discutidos dois dos principais mtodos usados para implementar
controle de concorrncia. O primeiro dos mtodos a ser discutido utiliza bloqueio aos dados
para garantir que toda execuo concorrente serializvel. J o segundo mtodo impe uma
ordenao "a priori" s transaes e garante que toda execuo concorrente equivalente
execuo serial das transaes na ordem imposta.
Mtodos baseados em Bloqueios
Uma parte dos problemas levantados na seo anterior residia no fato de que os estados
intermedirios gerados por uma transao eram visveis s outras transaes. A idia bsica
dos mtodos de bloqueio consiste simplesmente em impedir que tais estados se tornem
visveis bloqueando o acesso a eles. A soluo no to imediata como parece, no entanto.
H dois aspectos envolvidos no uso de mtodos de bloqueio que precisam ser equacionados:
como usar bloqueios para atingir apenas execues serializveis, e como gerenciar o bloqueio
aos dados.
Deve ficar claro, neste ponto, que apenas usar bloqueios para gerenciar o acesso aos objetos
partilhados no suficiente para criar um controle de concorrncia correto. Por exemplo,
considere o seguinte protocolo de bloqueio:
1) antes de ler ou atualizar em um objeto, este deve ser bloqueado;
2) aps a leitura ou atualizao, o objeto poder ser liberado.
Este protocolo obviamente incorreto, pois permite gerar, por exemplo, a execuo N
apresentada no final da seo anterior, que no serializvel.
O protocolo de bloqueios mais comumente usado para garantir serializao chamado de
bloqueio em duas fases e dita o seguinte:
1) uma transao deve sempre bloquear os objetos antes de acess-los, e eventualmente
liber-los antes do seu trmino;
2) depois de liberar o primeiro objeto, uma transao no poder bloquear novos objetos.
- 23 -
Este protocolo assim chamado pois, pela segunda regra, cada transao passa por duas
fases: em uma primeira fase objetos so apenas bloqueados e em uma segunda fase objetos
so apenas liberados. O protocolo pode ser implementado tanto para um banco de dados
centralizado quanto para um banco distribudo, conforme ser visto no Captulo 8.
Podemos provar que toda execuo concorrente permitida pelo protocolo de bloqueio em
duas fases serializvel usando o seguinte raciocnio. Seja E uma execuo concorrente de
um grupo T de transaes. Suponha que todas as transaes em T terminam em E e que
seguiram o protocolo de bloqueio em duas fases em E. O ponto em que cada transao T
i
libera o primeiro objeto em E chamado de ponto de bloqueio de T
i
. Considere a execuo
serial S em que as transaes so processadas na ordem dos pontos de bloqueio em E.
Teremos ento que S e E sero equivalentes pois, dado o uso de bloqueios, possvel comutar
a ordem das operaes em E para que se transforme em S sem alterar a computao das
transaes ou o estado final do banco de dados. Logo, E serializvel.
A guisa de exemplo, considere novamente as transaes T
1
e T
2
da seo anterior acessando
um banco de dados centralizado. Considere agora que elas bloqueiam explicitamente os
dados seguindo a poltica do protocolo de bloqueio em duas fases. Suponha que a seqncia
de aes elementares sobre o banco de dados, incluindo as aes de bloqueio e liberao,
gerada pela execuo da transao T
1
(supondo que haja saldo suficiente) seja:
B
11
: bloqueie o saldo P para T
1
T
11
: leia o saldo P para X
X := X - 5.000
B
12
: bloqueie o saldo C para T
1
T
12
: leia o saldo C para Y
Y := Y + 5.000
T
13
: escreva o novo saldo Y em C
L
11
: libere o saldo C
T
14
: escreva o novo saldo X em P
L
12
: libere o saldo P
Suponha que a seqncia de aes elementares sobre o banco de dados gerada pela execuo
da transao T
2
(supondo que haja saldo suficiente) por sua vez seja:
B
21
: bloqueie o saldo C para T
2
T
21
: leia o saldo C para Z
Z := Z - 10.000
T
22
: escreva o novo saldo Z em C
L
21
: libere o saldo C
- 24 -
A execuo concorrente, abstrada pela seguinte seqncia de rtulos, seria permitida pelo
protocolo de bloqueios:
L = B
11
T
11
B
21
T
21
T
22
L
21
B
12
T
12
T
13
L
11
T
14
L
12
Esta execuo serializvel conforme discutido na seo anterior. Isto pode ser visto de outra
forma, ilustrando o raciocnio da prova de correo do protocolo de bloqueio em duas fases.
O bloqueio de P para T
1
desde B
11
at L
12
implica em que nenhuma ao de T
2
ou qualquer
outra transao pode acessar P durante este perodo, pois a transao em questo teria que
bloquear tambm P, o que no permitido. Isto garante que as aes T
21
e T
22
no afetam o
valor de P lido por T
11
. Logo T
11
pode ser comutado com estas aes sem que o
processamento de T1 em E se altere. Neste caso particular, esta observao basta para mostrar
que, assim sendo, E equivalente seguinte execuo serial (obtida comutando-se &T11.
com &T21. e &T22. em E):
S = B
21
T
21
T
22
L
21
B
11
T
11
B
12
T
12
T
13
L
11
T
14
L
12
Considere agora uma outra execuo concorrente, abstrada pela seguinte seqncia de
operaes:
N = B
11
T
11
B
12
T
12
( B
21

O protocolo de bloqueios no permitiria que B
21
fosse executada no ponto indicado pois o
saldo C est bloqueado para a transao T
1
. A transao T
2
espera ento pela liberao de C,
sendo que a execuo poderia prosseguir da seguinte forma, por exemplo:
N = B
11
T
11
B
12
T
12
T
13
L
11
B
21
T
21
T
22
L
21
T
14
L
12
Note que esta segunda execuo tambm serializvel.
No exemplo acima, o bloqueio aos dados foi incorporado as transaes de tal forma a seguir a
tcnica de duas fases. No entanto, o protocolo de bloqueio em duas fases pode ser
implementado de forma transparente aos usurios, conforme discutido no Captulo 8. A mais
imediata destas implementaes em um ambiente distribudo segue a seguinte idia:
1) quando uma consulta enviada para ler dados de um banco local, os dados so
bloqueados automaticamente antes de execut-la;
2) quando uma mensagem PREPARE_SE recebida na primeira fase do protocolo bifsico,
os dados que sero modificados so bloqueados, aqueles que foram apenas lidos podendo
ser liberados, antes do n responder a mensagem;
3) aps as atualizaes terem sido instaladas no banco, caso o n receba uma mensagem
CONFIRME, ou aps o n ter recebido uma mensagem CANCELE, os dados atualizados
localmente so liberados.
Na discusso sobre o protocolo de bloqueio em duas fases assumiu-se que todas as transaes
terminam. O uso de bloqueios por si s no garante esta propriedade. De fato, um impasse
criado sempre que uma seqncia de transaes T
1
,, T
n
, T
1
, onde T
i
espera por T
i+1
,
formada. Esta situao ser chamada de bloqueio mtuo. Mecanismos adicionais devero
existir para detetar e resolver bloqueios mtuos. O mtodo de resoluo usualmente
empregado consiste em reiniciar a transao na seqncia de impasse que consumiu menos
recursos at o momento. Em um banco de dados distribudo, deteo de bloqueios mtuos
- 25 -
especialmente difcil pois poder ser necessrio levantar quais transaes esperam por quais
transaes ao longo de vrios ns. Ou seja, a seqncia de impasse poder se estender ao
longo de vrios ns da rede.
Quanto a gerncia dos bloqueios em si, apenas mencionaremos aqui que, na realidade, so h
necessidade de bloquear o acesso concomitante a um objeto quando se est modificando seu
valor. Posto de outra forma, no h inconveniente em que vrias transaes leiam o valor de
um objeto sem bloque-lo. Isto porque a operao de leitura no muda o estado do banco de
dados. Os problemas aparecem quando uma transao atualiza o valor de um objeto e outra
l/atualiza o mesmo objeto, quando ento o estado do banco de dados modificado. Esta
alterao, se tornada visvel intempestivamente, levaria a inconsistncias. Uma maneira de
concretizar a idia seria postular-se diferentes modos de bloqueios: modo partilhado e modo
exclusivo.
Vrias transaes distintas poderiam bloquear um objeto em modo partilhado, desde que
nenhuma destas transaes fosse atualizar o valor do respectivo objeto. Apenas uma
transao poderia bloquear um objeto em modo exclusivo. Neste caso, a transao
pretenderia modificar o valor do objeto. O protocolo de bloqueio/liberao de objetos teria,
claro, que ser modificado para refletir esta nova mecnica.
Mtodos de Pr-Ordenao
O protocolo de bloqueio discutido na seo anterior garante que toda execuo E de um
conjunto T de transaes serializvel. Mais ainda, sabemos que a ordem de serializao
dada pela ordem em que os pontos de bloqueio foram atingidos em E. Ou seja, os usurios
tm a iluso de que as transaes executaram seqencialmente na ordem dos pontos de
bloqueio. Porm, esta ordem determinada "a posteriori", durante a execuo das transaes
e reflete um entrelaamento arbitrrio das aes elementares destas transaes. No
determinada por nenhum fator sobre o qual o usurio tenha controle direto. Uma transao T
i
poder ser iniciada antes de outra T
j
mas em E tudo se passa como se T
j
tivesse sido
executada antes de T
i
. Basta para isto que o ponto de bloqueio de T
j
tenha sido atingido antes
do ponto de bloqueio de T
i
em E.
O mtodo de pr-ordenao, como o nome indica, tem um comportamento diametralmente
oposto. Uma ordem inicial dada s transaes, digamos de acordo com o instante em que
foram iniciadas. As transaes so processadas concorrentemente, mas o controle de
concorrncia garante que a execuo final equivalente execuo seqencial das transaes
na ordem imposta "a priori".
Mais precisamente, o protocolo de pr-ordenao para um banco de dados distribudo dita o
seguinte:
1) As transaes, quando so submetidas, recebem uma senha ou nmero de protocolo,
nico em toda a rede, dado pelo gerente de transaes do n onde foram submetidas;
2) As aes de uma transao herdam a sua senha;
3) Localmente, em cada n onde uma parte do banco est armazenada, duas aes de
transaes diferentes so processadas em ordem de senhas, exceto se a sua ordem relativa
puder ser invertida sem afetar a computao (isto , se as aes no conflitam).
4) Se uma ao violar a condio do item anterior, rejeitada e a transao correspondente
reiniciada com outra senha.
- 26 -
A correo deste protocolo imediata. Seja E uma execuo concorrente de um grupo T de
transaes. Suponha que todas as transaes terminem em T e que o protocolo de pr-
ordenao tenha sido seguido. Considere a execuo serial S em que as transaes so
processadas na ordem de senha. Teremos, ento, que S e E sero equivalentes pois, como as
aes locais que no podem ser comutadas foram executadas em ordem de senha, possvel
comutar a ordem das outras operaes em E para que se transforme em S sem alterar a
computao das transaes ou o estado final do banco de dados. Logo, E serializvel.
Considere, novamente, as transaes T
1
e T
2
das sees anteriores supostas acessando contas
em um banco de dados centralizado, por simplicidade. A seqncia de aes de T
1
ento
considerada repetida aqui para facilitar referncias:
T
11
: leia o saldo P para X
X := X - 5.000
T
12
: leia o saldo C para Y
Y := Y + 5.000
T
13
: escreva o novo saldo X em P
T
14
: escreva o novo saldo Y em C
A seqncia de aes de T
2
, por sua vez, ser:
T
21
: leia o saldo C para Z
Z := Z - 10.000
T
22
: escreva o novo saldo Z em C
Suponha agora que T
1
e T
2
receberam senhas s
1
e s
2
tais que s
1
<s
2
. Estas senhas so
repassadas para as aes de T
1
e T
2
. Considere uma execuo concorrente de T
1
e T
2
representada pela seguinte seqncia de aes:
L = T
11
T
12
T
13
T
21
T
22
T
14
Esta seqncia seria aceita como est pelo protocolo de pr-ordenao. De fato,
acompanhando a dinmica do processamento, teramos:
T
11
submetida para o protocolo e aceita, j que nenhuma outra ao foi executada.
T
12
e T
13
so submetidas e aceitas pois so da mesma transao que T
11
T
21
submetida. Como T
21
l o saldo C e T
13
escreve neste saldo, a ordem relativa de T
13
e T
21
no pode ser invertida sem alterar a computao. Logo estas operaes tero que ser
processadas em ordem de senha. Mas a senha associada T
21
maior do que a senha
associada T
13
(e T
13
j foi processada). Logo T
21
aceita.
T
22
aceita por motivos semelhantes.
T
14
submetida. A senha associada T
14
menor do que a senha das duas ltimas aes
processadas, T
21
e T
22
. Porm, como T
14
afeta o saldo P e T
21
e T
22
acessam o saldo C, a
ordem relativa de T
14
e T
21
/ T
22
pode ser invertida sem que a computao seja alterada.
Portanto, T
14
aceita e processada.
Considere agora uma seqncia diferente:
N = T
11
T
12
T
21
( T
13

- 27 -
A ao T
13
necessariamente rejeitada pelo protocolo de pr-ordenao, provocando o
reincio de T
1
. De fato, observe inicialmente que a ordem de T
13
e T
21
importante pois T
21
l
o saldo C e T
13
cria um novo valor para C. Logo a ordem relativa de T
13
e T
21
no pode ser
invertida sem afetar a computao. Assim, estas aes tm que ser processadas em ordem de
senha, ou seja, T
21
depois de T
13
, neste caso. Como na seqncia acima T
21
j foi processada
quando T
13
recebida, esta ltima ao rejeitada, forando o reincio de T
1
com um nmero
de senha mais alto.
Usando a notao O para indicar a ao que desfaz o efeito da operao O, a seqncia
acima continuaria da seguinte forma, por exemplo:
N = T
11
T
12
T
21
T
11
T
12
T
22
T
11
T
12
T
13
T
14
Diversas implementaes do protocolo de pr-ordenao, todas transparentes aos usurios,
sero discutidas no Captulo 8. Faremos aqui apenas alguns comentrios sobre o problema de
gerar senhas de forma unvoca e sobre o relacionamento do protocolo de pr-ordenao com
o protocolo bifsico.
Em bancos de dados centralizados senhas podem ser geradas de forma unvoca utilizando-se
o prprio relgio do processador principal. Por outro lado, em um sistema distribudo, se os
gerentes de transaes gerarem senhas desta forma, duas transaes podero potencialmente
receber a mesma senha. Isto violaria o princpio de que cada senha deve estar associada a
uma transao distinta. O dilema solucionado justapondo-se hora local a identidade do n
onde a transao se origina, suposta nica para cada n da rede. Pode-se conseguir, assim,
que transaoes distintas tenham senhas nicas em relao ao sistema como um todo.
Quando o SGBDD faz uso do protocolo bifsico para confirmar intenes problemas
aparecem com o protocolo de pr-ordenao. Note que, na fase dois daquele protocolo, os
ns que participaram da execuo de uma transao no podero mais cancelar,
unilateralmente, os efeitos locais desta transao e devero garantir que, quando a ordem do
coordenador eventualmente chegar para que a transao seja confirmada, estejam preparados
para tornar seus efeitos permanentes no banco de dados local. Este problema pode ser
resolvido alterando-se o protocolo de pr-ordenao para que processe as aes de
PREPARE_SE como se fossem as operaes que atualizam os dados. Uma vez que o n local
emitiu uma mensagem de PREPARADO em resposta a uma mensagem PREPARE_SE, com
senha S e indicando que um objeto X ser atualizado, nenhuma outra operao com senha
maior do que s e que acesse X poder ser processada. Este problema seria solucionado, por
exemplo, bloqueando-se X desde o processamento de PREPARE_SE at que a atualizao
seja efetivada.
Finalmente, necessrio examinar o problema de terminao. No contexto desta
implementao, uma transao T
i
poder no terminar se for reiniciada ciclicamente j que, a
cada vez que uma de suas aes chegou "atrasada", por assim dizer, com relao outra ao
com que conflita, a transao T
i
reiniciada. Uma soluo para este problema consiste em
reiniciar a transao T
i
com uma nova senha bem maior do que a anterior para minimizar as
chances de T
i
ser novamente reiniciada.
A poltica de aumento de senha ainda tem um outro fator determinante. Existe a possibilidade
do processamento de vrias transaes sincronizar-se de tal forma a causar o reincio mtuo
de todas elas. Ou seja, cria-se uma seqncia de transaes T
i0
, T
i1
,, T
I, m-1
, T
i0
tal que T
ij
fora o reincio de T
i , j+1
(soma mdulo m). Se o aumento da senha for o mesmo para todas
estas transaes, corre-se o risco de repetir-se a situao indefinidamente. Para se resolver
- 28 -
este problema (probabilisticamente) basta randomizar o incremento dado as senhas. Este
esquema simples naturalmente no evita completamente o problema de reincio cclico, mas o
torna pouco provvel.
NOTAS BIBLIOGRFICAS
Lindsay [1980] contm uma descrio mais ou menos detalhada das fases de incio, migrao
e trmino de transaes, especialmente desta ltima. A parte de trmino de transaes bem
formulada. Tambm inclui uma boa descrio do mecanismo controle de integridade
envolvendo atas e balizadores. Gray [1978] descreve algumas das estratgias usadas na
implementao do Sistema R, desenvolvido no laboratrio de pesquisas da IBM, em San
Jose. Descreve com algum detalhe o mecanismo de atas, bem como o protocolo bifsico.
Gray et all. [1979] apresenta o mecanismo de recuperao do Sistema R. Lindsay et all.
[1979] proporciona uma descrio detalhada do protocolo bifsico. Lorie [1977] apresenta
um mtodo de imagens transientes. Severance e Lohman .1976] descrevem uma tcnica de
arquivos diferenciais. Randell et all. [1978], Verhofstad [1978], Randell [1979] e Kohler
[1981] contm tutoriais sobre controle de integridade. Bernstein e Goodman [1981] por sua
vez contm um timo tutorial sobre controle de concorrncia. Mais referncias sobre os
tpicos aqui cobertos encontram-se nas notas bibliogrficas dos trs prximos captulos.
- 1 -
Captulo 7. Executando Transaes
Este captulo ser dedicado a estudar os mecanismos que devem ser acionados quando do
incio de uma transao, a expor tcnicas para controlar a migrao de transaes e,
finalmente, apresentar algoritmos ou protocolos que, ao trmino da transao, garantam sua
atomicidade, esta ltima sendo de crucial importncia para o correto funcionamento do BD.
A Seo 6.2 contm uma descrio preliminar das idias que sero detalhadas nas sees
seguintes. A organizao deste captulo compreende uma seo introdutria seguida de trs
outras sees. Na primeira seo, o ambiente distribudo onde a transao opera revisto.
Nas trs sees seguintes os mecanismos que entram em cena quando do inicio, migrao e
trmino de transaes so examinados em detalhe.
7.1 UM N DA REDE
Nesta subseo, partes da arquitetura do sistema sero recolocadas, agora com nfase especial
na interligao entre os mdulos que mais de perto controlam a execuo de transaes.
Desta forma, o leitor poder ter em mente o cenrio geral onde tais execues so
processadas. Detalhes sero discutidos nas subsees seguintes.
Sob o ponto de vista lgico, cada n do sistema pode ser entendido como mostra a Figura 7.1.
Dentre todos aqueles componentes que formam o BD, esto mostrados apenas os elementos
que sero mencionados neste captulo. Seis grandes mdulos so visveis na referida figura:
ambiente de programao local
gerente de transaes
gerente de dados
SGBD local
sistema operacional local
banco de dados local
De acordo com as indicaes da figura, o seguinte desenrolar de operaes seria tpico.
Inicialmente, o usurio obtm acesso ao sistema atravs de um dos ns da rede. Isto significa
que um processo local instalado para servir ao indivduo neste n. Usando de todos os
recursos que o sistema local lhe oferece, tais como editores de texto e depuradores de
programas, o elemento constri um programa aplicativo numa linguagem de programao de
alto nvel. Em seguida, este programa submetido compilao ou preparado para futura
interpretao. Estamos supondo que o programa aplicativo contm comandos da linguagem
de manipulao de dados imersos entre comandos da linguagem de programao e que o
programador responsvel por indicar comeo e fim de transaes. Uma maneira de se obter
este ltimo efeito seria limitar os comandos que descrevem uma transao entre linhas de
cdigo tais como "COMECO_DE_TRANSAO" e "FIM_DE_TRANSAO". No ato de
compilar o programa fonte montado pelo usurio, ou prepar-lo para interpretao, cada
seqncia de comandos da LMD que compe uma transao passada ao gerente de
transaes. Este aciona o processador de comandos da LMD sob seu controle, o qual produz
o plano de execuo daquela transao. O processo de anlise bastante complexo e j foi
objeto de estudos nos Captulos 4 e 5. O plano construdo , ento, devolvido ao processo
controlado pelo usurio que se encarrega de agreg-lo ao cdigo objeto que est gerando, ou
- 2 -
Figura 7.1 - Um N da Rede
forma intermediria que est criando para posterior interpretao. Outra maneira de
proceder seria instruir o processo do usurio para, cada vez que identificar comandos da
LMD em meios aos comandos da linguagem de programao, incorporar ao cdigo que est
gerando indicaes para invocao do gerente de transaes. Assim, o cdigo final conteria
apenas chamadas para o gerente de transaes e no o plano completo para execuo de cada
transao. Obviamente, se o cdigo gerado com intenes de ser reutilizado com freqncia
no futuro esta ltima hiptese deve ser descartada. Note, inclusive, que o processo controlado
pelo usurio pode estar interagindo com o SGBD de maneira conversacional. Neste cenrio,
alguns comandos da linguagem de alto nvel seriam executados, seguidos de um comando na
linguagem de manipulao de dados. Este ltimo repassado ao gerente de transaes
enquanto o processo do usurio espera pela sua concluso. Chegando a resposta esperada, o
ciclo reiniciado at que a conversao seja dada por encerrada e o usurio cancele o
processo local, abandonando o BD. Como uma outra alternativa nesta fase, o programa de
que o usurio necessita poderia j ter sido compilado anteriormente, encontrando-se, agora,
armazenado na biblioteca de programas local. Tudo que necessrio fazer instruir o sistema
local para que recupere o referido programa.
Neste ponto, suponha que o processo controlado pelo usurio, de uma forma ou de outra,
disponha de cdigo, objeto ou em forma intermediria, de um programa aplicativo. Como
ambiente local
de programao
gerente de dados
executor de transaes
controle de integridade
sistema operacional local
gerente de transaes
SGBD local
processador de
comandos da LMD
controle de concorrncia
interpretador para
a LMD local
subprograma PR
comandos da LMD local
programa PR
transao
aes element.
aes element.
BD
local
- 3 -
vimos, este cdigo pode incorporar planos completos para execuo de transaes ou apenas
a informao necessria para a elaborao destes planos durante sua execuo ou
interpretao. O prximo passo seria o processo do usurio dar incio execuo deste
cdigo. Assim que chega a um ponto onde se depara com material referente ao BD, o
processo do usurio repassa este material ao gerente de transaes local. O gerente de
transaes contm dois mdulos importantes: um processador de comandos da LMD e um
executor de transaes. De acordo com os cenrios mencionados acima, h dois casos a
considerar. Se o material entregue j contm o plano da transao, este passa direto ao
executor de transaes, o qual inicia a execuo do referido plano. o caso de um programa
usado com freqncia, cujo cdigo armazenado e posteriormente recuperado a cada
invocao. A outra possibilidade se d quando o material enviado ao gerente de transaes
contm apenas comandos da linguagem de manipulao de dados. Neste caso, estes so
examinados, em primeira instncia, pelo processador de comandos da LMD que produz um
plano de execuo. S ento o resultado entregue ao executor de transaes. Em qualquer
dos dois casos, o resultado final que o executor de transaes recebe um programa
pertencente a classe PR, conforme especificado no Captulo 5. Um tal programa,
relembrando, uma receita que contm, para cada um dos ns que devero participar da
execuo da transao, quais consultas e atualizaes locais deve efetuar, bem como que
resultados, ou tabelas, deve encaminhar a outros ns. Obviamente, a ordem em que estas
operaes sero executadas tambm deve estar indicada no programa. tarefa do executor de
transaes, tendo em mos o programa da classe PR que lhe passado pelo processador de
comandos da LMD, interpretar a receita e despachar tarefas aos vrios ns participantes de
forma orquestrada, garantindo que a receita seguida risca.
Este captulo comea a focalizar os aspectos da execuo de transaes justamente no
instante que o programa PR, suposto como uma transao completa, entregue ao executor
de transaes. A primeira tarefa deste ltimo consultar a receita do programa PR e separar
partes do programa, despachando-as aos ns remotos apropriados. Isto feito atravs de
trocas de mensagens entre os gerentes de transaes envolvidos. Os gerentes de transaes
que receberam tarefas passam a execut-las e, quando terminam, informam que tal a
situao ao gerente de transaes que solicitou o trabalho. claro que, se for o caso, o
gerente de transaes do n original tambm executar parte do programa. As mensagens
trocadas entre gerentes de transaes devem conter especificaes do trabalho a ser realizado
nos locais remotos. A fim de minimizar os custos de tais comunicaes, que podem ser
elevados, interessante que a descrio do trabalho seja feita em "alto nvel" e, tambm, que
o mximo de informao seja enviado em cada mensagem. Assim procedendo, estaramos
minimizando tanto o nmero de mensagens trocadas quanto o comprimento de cada uma
delas. Ha vrias maneiras de se controlar a migrao de transaes nesta fase. Algumas delas
sero examinadas em detalhes em sees posteriores deste captulo.
Se o BD for heterogneo, a solicitao de trabalho recebida pelo sistema local de cada n vir
codificada em forma de comandos padronizados da linguagem de manipulao de dados
pivot. Deve, portanto, ser traduzida para a linguagem de manipulao de dados usada no
particular n para o qual foi endereada. Sob esta hiptese, o gerente de transaes local, ao
receber a mensagem de trabalho, passa esta ao gerente de dados local, que se encarrega de
ajust-la s condies locais. Uma vez que o gerente de dados obtenha um programa PR,
descrevendo parte da transao original, e o tenha ajustado linguagem de manipulao de
dados local, o resultado passado ao SGBD local. Este ltimo deve apelar para um
compilador ou interpretador desta linguagem que possibilite traduzir as instrues de trabalho
em aes elementares. neste ponto que o SGBD local gera cdigo de acesso s vrias
estruturas do BD local, de acordo com os mtodos de acessos de que dispe localmente.
- 4 -
Lembre que aes elementares manipulam objetos fsicos do BD. Os problemas de
endereamento e acesso, portanto, devem estar equacionados quando chegamos a este ponto.
Uma vez mapeada em aes elementares, a solicitao de trabalho passa execuo sob o
controle do SGBD local. Para cada solicitao de trabalho que recebeu, o SGBD local cria
um agente local, ou um processo local, que vai se desincumbir da execuo das aes
elementares que compem esta solicitao de trabalho. responsabilidade do SGBD local
coordenar a operao de cada agente local com os mdulos de controle de integridade e
controle de concorrncia, ambos sob sua tutela, de forma a possibilitar uma execuo
ordenada e segura a cada transao. at este ponto que vai o interesse deste captulo, sem
entrar no mrito dos mecanismos de controle de integridade e controle de concorrncia, visto
que sero alvo de atenes nos captulos seguintes.
Completando o quadro da Figura 7.1, temos os agentes locais a gerarem chamadas para o
sistema operacional local. Como o SGBD local lida a nvel de operaes elementares, estas
chamadas contm endereos fsicos de objetos bem definidos. O sistema operacional local,
por sua vez, ao atender estas chamadas completa o acesso movendo objetos do BD local para
a memria principal e vice-versa.
Com relao aos mecanismos de controle de concorrncia, ser suposto que operem a
contento e sem problemas. Sob a tica do presente captulo, tudo que se pretende fazer
seguir a vida de uma transao desde o momento em que o executor de transaes inicia o
processo at sua completa execuo. A interao entre os mecanismos de controle de
concorrncia e os algoritmos de migrao e trmino de transaes por ser mais tnue e,
portanto, mais fcil de ser visualizada, ser mencionada apenas quando oportuna. Mesmo
porque, lembre-se, a funo bsica do controle de concorrncia proporcionar a iluso de que
apenas uma transao executa de cada vez.
No que se refere aos mecanismos de controle de integridade, o que se pretende expor a
interao entre estes e aqueles mecanismos que entram em cena quando do incio, migrao e
trmino de transaes. A perfeio imposta neste ponto aos primeiros no deve esconder sua
interao com os ltimos. Apenas que, no momento, no ser detalhada nenhuma das tcnicas
de controle de integridade, porque isto tarefa para o Captulo 9. Entretanto, simplesmente
supor recuperao total na presena de falhas no suficiente para garantir o processamento
ordenado de transaes em ambientes distribudos, como veremos adiante. necessrio que
protocolos especficos sejam invocados e aes concretas sejam tomadas, especialmente
quando da migrao e trmino de transaes, mesmo estando os mecanismos de controle de
integridade funcionando a toda prova. O que vamos supor a respeito dos mtodos de controle
de integridade, por ora, que provem proteo total e cabal contra quaisquer tipos de falhas.
Embora o sistema esteja sujeito a falhas, quando estas ocorrem estes mecanismos sero
sempre capazes de recuperar toda a informao que lhes foi confiada como sendo vital, no
importando o tipo de falha que se abata sobre o SGBD ou a freqncia com que estes eventos
ocorram.
7.2 INCIO DE TRANSAES
Voltando Figura 7.1, estamos focalizando agora o gerente de transaes quando recebe, do
processo controlado pelo usurio, um conjunto de comandos da LMD descrevendo uma
transao. O n onde isto se passa, isto , o n onde reside o processo do usurio, ser
chamado de n de origem da transao. Os comandos recebidos so, ento, passados ao
processador de comandos da LMD, um mdulo controlado pelo gerente de transaes do n
de origem. A seguir, o processador de comandos da LMD cria um programa da classe PR
- 5 -
descrevendo o plano global de execuo da transao. Este plano prev, eventualmente, a
cooperao de vrios outros ns remotos na execuo da transao. Cada um destes ns ser
chamado de n participante. claro que o prprio n de origem tambm participar da
execuo da transao, caso isto esteja previsto no plano global de execuo desta transao.
A responsabilidade de distribuir este plano para os ns participantes compete ao executor de
transaes, outro mdulo controlado pelo gerente de transaes do n de origem. Retraduzir
instrues recebidas do n de origem, refletindo o particular dialeto da LMD usado em um n
participante, tarefa delegada ao gerente de dados deste n participante. A partir desta
retraduo, o SGBD do n participante compila estas instrues para aes elementares
coerentes com o modelo fsico presente neste n. Este mesmo SGBD controla a execuo
destas aes elementares. Para tal, o SGBD do n participante cria e instala um agente local,
munido do respectivo descritor de transao, cuja tarefa ser invocar e executar as referidas
aes elementares.
O agente local se constitui, simplesmente, em mais um processo que criado junto ao
sistema local. instalado pelo SGBD local e este tem poderes para ativ-lo ou extingu-lo,
conforme suas convenincias. O descritor de transao nada mais que um registro residente
na memria do correspondente agente local e composto de campos que sero utilizados no
decorrer da execuo da transao. Tanto o SBGD como o executor de transaes tm acesso
a cada agente local e seu respectivo descritor que porventura estejam ativos nos locais onde
residem. Cada vez que um n participante recebe mensagem solicitando trabalho local em
favor de determinada transao, um agente local e um descritor so instalados neste n
participante para atenderem referida solicitao. Desta maneira, pode-se assumir que cada
transao ativa em um dado n ter um ou vrios agentes locais operando localmente em seu
favor, quer seja este seu n de origem ou no. Outro ponto importante que o agente local,
como todo outro processo em execuo localmente, pode residir, em determinados intervalos
de tempo, na memria principal do sistema. Em caso de falhas primrias, seu contedo ser,
portanto, suposto irrecupervel. H de haver, claro, mecanismos que resguardem
informao suficiente para que o SGBD de cada n, ao voltar vida, tenha condies de
tratar as transaes a que serviu de maneira adequada, evitando inconsistncias. Na seo
seguinte, sero discutidos mecanismos para coordenar estes algoritmos locais de modo a
preservar a ordem em todo o sistema.
So estes os campos que compem o descritor de uma transao: identificao e estado de
retorno.
O campo de identificao preenchido com informao que identifica a transao,
univocamente, perante todo o sistema. Se este for o n de origem da transao, a
identificao deve ser fabricada localmente. Se o presente n apenas mais um n
participante para o qual a transao migrou, ento a mensagem que requisitou trabalho a este
n dever, de alguma forma, transmitir a identificao que j fora associada a esta transao
em seu n de origem. Assim, ao migrar de um local para outro a transao mantm sua
identidade original. Caso uma identificao nica apenas no mbito local de cada n fosse
suficiente, um contador local ou mesmo o valor do relgio do processador central, desde que
devidamente protegidos contra falhas, serviriam como fonte de identificadores unvocos. Para
produzir uma identificao unvoca globalmente, pode-se justapor a este valor local a
identidade que o n de origem da transao detm como membro da rede de comunicao de
dados onde est imerso o BD distribudo. Esta identidade suposta nica, o que razovel
pois servir de endereo para troca de mensagens entre os ns. Este esquema tem a vantagem
adicional de levar, junto com a identidade da transao, a identificao de seu n de origem.
De fato, este benefcio ser til mais tarde e, portanto, ser tido que tal o caso.
- 6 -
A necessidade de uma identificao global pode ser compreendida em vista do fato de que a
transao pode migrar para outros ns. Como entre dois particulares ns podem circular
mensagens em favor de vrias transaes requisitando trabalho ou reportando resultados,
necessrio que cada mensagem identifique a particular transao que a gerou, caso contrrio
no haveria meios de se associar resultados a transaes. Mais ainda, o controle de
integridade em cada n participante deve ter a capacidade de, ao retornar aps uma falha,
identificar que aes elementares foram executadas em benefcio de quais transaes. S
assim poder desfazer/refazer os efeitos locais desta transao, caso isto seja necessrio.
Pense, por exemplo, no mecanismo de atas onde cada ao elementar l registrada para fins
de controle de integridade. Como transaes distintas originadas em ns diferentes podem
migrar para um n comum, a identificao global evita confuses quando um SGBD local
tenta agrupar, lendo a partir da ata, as aes elementares que pertencem a uma mesma
transao. H outras situaes, de normalidade mesmo, quando necessitamos cancelar
transaes e, em conseqncia, recorrer ata para inverter os efeitos de aes elementares.
Uma delas se configura durante a execuo do protocolo bifsico quando, mesmo na ausncia
de falhas locais em determinado n participante, o SGBD residente no local de origem decide
pelo cancelamento global da transao devido a falhas em outros ns. Bloqueios globais so
outro exemplo de eventos que provocam cancelamentos no forados por falhas no sistema.
Nestes casos, novamente, consultas ata seriam necessrias para obter-se as aes
elementares da transao que foi eleita para cancelamento e, em seguida, desfazer-se seus
efeitos.
O campo de estado de retorno usado pelo protocolo bifsico para confirmar intenes que
executar neste n quando do trmino da transao. A finalidade precisa deste campo de
estado de retorno ficar clara quando abordarmos a descrio daquele protocolo.
Sumariamente, este campo conter os diferentes "estados" por que passar o protocolo
medida que for executado. Por ora, basta destacar que deve ser iniciado como
DESCONHECIDO.
O incio de execuo da transao pode ser tomado como aquele instante quando o executor
de transaes do n de origem recebe, do processador de comandos da LMD, o programa da
classe PR que descreve a transao. Porm, antes de iniciar a distribuio do plano de
execuo aos ns participantes, o executor de transaes deve tomar uma providncia
importante: instruir o SGBD local para que, atravs dos mecanismos de controle de
integridade, armazene a lista de ns participantes e a identificao da transao em local
seguro. Esta atitude ser vital mais tarde quando forem analisados, na presena de falhas, o
protocolo bifsico e a migrao de transaes. A migrao da transao pode, aps garantida
a segurana destes dois itens, ser iniciada pelo executor de transaes do n de origem o qual
principia a despachar mensagens aos ns participantes. Quanto lista de ns participantes, o
executor de transaes no deve ter dificuldades em obt-la visto que, nesta fase, j dispe do
plano global de execuo desta transao. Basta inspecionar este plano para obter a referida
lista.
Resumindo, o seguinte se passa no local de origem quando da iniciao de uma transao, a
comear pelo instante em que o executor de transaes do n de origem recebe o plano de
execuo desta transao:
1) executor de transaes cria uma identificao global para a transao;
2) executor de transaes compila a lista de todos os ns participantes com respeito a esta
transao;
- 7 -
3) executor de transaes instrui o SGBD local para acionar os mecanismos de controle de
integridade para que registrem em lugar seguro:
a) a identificao desta transao;
b) a lista de ns participantes que recebeu;
4) SGBD local retorna ao executor de transaes uma mensagem informando do sucesso da
operao;
5) executor de transaes da origem est pronto para iniciar a migrao da transao.
A transao est ativa neste n a partir do instante em que o passo 3 se completar.
J em um n participante, o processo de iniciao desencadeado quando cada mensagem
solicitando trabalho em benefcio desta transao recebida. Estamos incluindo nesta
categoria tambm o n de origem da transao, quando a este delegado execuo de
algum trabalho local em favor da transao. A nica diferena que, neste caso, obviamente,
mensagens no seriam trocadas pois estamos operando em um mesmo n.
Os passos so os seguintes:
1) executor de transaes recebe uma mensagem, vinda de outro executor de transaes,
solicitando trabalho;
2) se esta a primeira solicitao de trabalho em favor desta transao, o executor de
transaes instrui o SGBD local para que registre em lugar seguro que esta transao est
agora ativa neste n;
3) executor de transaes instrui o SGBD local para criar um agente local para esta
solicitao contendo, em memria prpria, um descritor cujos campos so iniciados
assim:
a) campo de identificao recebe a identificao da transao que veio junto com a
mensagem que requisitou o trabalho;
b) campo de estado de retorno recebe o valor DESCONHECIDO;
4) este n esta pronto para iniciar a execuo local desta solicitao de trabalho.
A transao s estar ativa neste n quando o passo 2 se completar por ocasio da chegada da
primeira mensagem solicitando trabalho em favor desta transao.
Note que, sendo ou no esta a primeira solicitao de trabalho em benefcio desta transao,
no so tomadas quaisquer providncias por parte do n remoto no sentido de registrar, em
lugar seguro, que esta solicitao de trabalho est sendo atendida. Entretanto, aps a
execuo da primeira ao elementar que venha a modificar o valor de qualquer objeto do
BD, este fato ser automaticamente registrado. Lembre-se de que precisamos registrar os
efeitos de cada ao elementar executada, junto com a identidade da respectiva transao,
para a contingncia do n local ser atingido por uma falha e precisarmos desfazer efeitos
referentes a aes elementares invocadas no passado. Os mecanismos de controle de
integridade se encarregaro de, caso haja o registro, tomar as medidas cabveis. O sistema
local pode, entretanto, falhar naquele intervalo entre o instante de recebimento da mensagem
solicitando trabalho e o momento em que os efeitos da primeira ao elementar so
registrados a salvo, em local seguro. Neste caso, o sistema local desconheceria a existncia da
mensagem solicitando trabalho quando estivesse se recuperando de uma eventual falha. Em
- 8 -
conseqncia, no tomar atitude nenhuma, podendo deixar o n solicitante a esperar
indefinidamente por uma resposta que no vir. Suporemos que, quando da chegada de
qualquer mensagem, esta posta a salvo em rea prpria e que sobreviva a falhas
:hp1.antes:ehp1. de enviarmos ao n remetente a confirmao (do ingls, "ack") de que a
referida mensagem foi recebida. Assim, os prprios protocolos de comunicao se
encarregaro de reenviar a mensagem caso o sistema falhe antes de salv-la. Tendo-a salvo,
claro, estar disponvel para inspeo aps o sistema retornar operao normal.
7.3 MIGRAO DE TRANSAES
Aps terem sido iniciadas no local de origem, transaes podem migrar para outros ns da
rede. A migrao tem lugar quando um certo n requisita que outro n remoto efetue
trabalho, ou computaes, em benefcio de determinada transao. O n remoto, por sua vez,
envia ao solicitante um aviso quando termina de executar a tarefa que lhe foi delegada. No
modelo que assumiremos no ser necessrio que o n remoto envie "resultados" ao
solicitante. Toda transferncia de arquivos ou tabelas ser explicitamente prevista no plano
global da transao cuja execuo est sendo controlada pelo n de origem.
Equivalentemente, pode-se encarar o sinal de "fim de execuo" como sendo o "resultado"
que o n remoto envia ao n solicitante. A cada mensagem enviada, porm, o n que a remete
espera uma resposta explcita por parte do n recebedor. Assim, meramente obter
confirmaes (do ingls, "acks") vindas do n recipiente no ser suficiente para o n
remetente. Ser preciso que o primeiro construa e despache uma mensagem especfica para
cada mensagem recebida do segundo. Para esta troca de informaes o SGBD faz uso de uma
rede de comunicao de dados que est a sua disposio. No transcorrer desta seo, em
primeiro lugar, ser examinado o ambiente em que o SGBD opera, em relao a esta rede de
comunicao. Em seguida, os tipos de mensagens trocadas sero descritos. Depois, o
ambiente em que se processam as migraes, com suas limitaes e liberdades, ser
enfocado. Finalmente, a prpria migrao de transaes ser abordada tanto na ausncia
como na presena de falhas que podem interromper o processamento normal de qualquer dos
ns envolvidos.
7.3.1 A Rede de Comunicao de Dados
Ser suposto que os SGBD locais operem a rede de comunicao a nvel de programa
aplicativo. Isto pressupe que todos os detalhes dos protocolos que implementam a
comunicao sero tidos como totalmente transparentes aos SGBDs. Em particular,
problemas tais como:
mensagens perdidas quando em curso
mensagens entregues adulteradas
mensagens entregues em endereos errados
mensagens duplicadas
mensagens entregues fora de ordem
sero supostos como devidamente resolvidos em nveis inferiores quele da camada
aplicativa onde o SGBD atua. Qualquer bom texto tratando a respeito de redes de
computadores e dos respectivos protocolos de comunicao de dados dar uma viso
satisfatria dos problemas encontrados e das solues propostas. As notas bibliogrficas no
fim deste captulo contm sugestes neste sentido. Em qualquer caso, o SGBD toma como
certo que toda mensagem ser entregue sem adulteraes, ao destinatrio correto e dentro de
- 9 -
um intervalo de tempo finito. Alm do cenrio de normalidade, h dois outros que podem ser
encontrados:
1) Reposta alguma jamais se materializa junto ao n que gerou a requisio. Ento,
forosamente, o n recipiente falhou no hiato compreendido entre o instante quando
recebeu a mensagem e antes que pudesse gerar uma resposta explcita;
2) Resposta do n solicitado tarda em vir. Ento pode-se concluir que:
y a rede de comunicaes est com elevados ndices de trfego, causando atrasos, ou
y n recipiente est com carga alm do normal e, portanto, lento ao responder. Ou ambos.
Na prtica, e difcil distinguir os dois casos. Visualizando a situao sob o ponto de vista do
n que enviou a mensagem, este no tem condies de separar as duas hipteses, uma vez
que dispe apenas da prpria rede como nico veculo para sondar o meio exterior. No h
como distinguir entre "tardando em chegar" e "no vir jamais". A nica maneira de amenizar
o problema envolveria, de uma forma ou outra, a operao de relgios ou contadores locais
que medissem a passagem do tempo desde que a mensagem foi entregue rede. Iniciados
quando a mensagem enviada, disparariam alarmes (do ingls, teria ocorrido um "timeout")
assim que o intervalo sem resposta se tornasse longo demais. Isto dispararia atitudes
especficas por parte do SGBD que enviou a mensagem tais como o envio de outra
mensagem, mais curta, indagando a respeito das condies no local de destino, ou mesmo o
simples reenvio da mensagem original. Estes mecanismos, especialmente quando
implementados de maneira "ad hoc", devem ser abordados com cautela, pois podem produzir
efeitos colaterais, muitas vezes no previstos, contribuindo para tornar o quadro geral ainda
mais complexo e confuso. Neste nvel introdutrio, estas tcnicas no sero utilizadas ou
descritas em maiores detalhes. Exemplos concretos de seu uso podem ser encontrados nas
referncias que tratam de protocolos de comunicao em redes de dados citadas ao fim deste
captulo. No que segue, este problema ser ignorado e um "tempo finito" tido como
satisfatrio, uma hiptese que pode ser mais ou menos razovel dependendo a que se preste o
BD em questo.
7.3.2 As Mensagens
H dois tipos de mensagens envolvidas, quais sejam, mensagens de trabalho e mensagens de
resposta. Como o prprio nome indica, o gerente de transaes local, detectando a
necessidade de trabalho ou informao que devam ser requisitados a um certo n remoto,
constri uma mensagem de trabalho e a despacha para este n remoto. Uma tal mensagem de
trabalho envolve os seguintes campos: identificao e descrio.
A identidade de toda transao ativa em cada n suposta conhecida do gerente de
transaes local uma vez que este responsvel por coordenar a execuo de cada uma delas.
Desta forma, no deve haver dificuldade em copiar esta identidade para o campo de
identificao da mensagem de trabalho. Este campo contm, assim, a identidade global da
transao. O campo de descrio informa exatamente o que deve ser executado remotamente
em favor desta transao, incluindo aqui tambm as mensagens PREPARE-SE, CONFIRME
e CANCELE. Estas mensagens dizem respeito apenas ao protocolo bifsico para confirmar
intenes e sero ignoradas no momento. Sero incorporadas ao cenrio geral na ltima seo
deste captulo. A particular maneira como a descrio de trabalho codificada neste campo
imaterial para a discusso que segue. Note, porm, que descrever o trabalho em uma
"linguagem de alto nvel" teria a vantagem de encurtar o comprimento das mensagens
- 10 -
trocadas. Os SGBD remotos seriam responsveis por compilar a descrio do trabalho a ser
executado para aes elementares executveis localmente.
Ao receber uma mensagem de trabalho, o n recipiente observa o protocolo de iniciao
descrito na seo anterior. Isto feito, o agente local trata de se desincumbir das tarefas que lhe
foram confiadas. Uma vez completo o trabalho solicitado, o executor de transaes acionado
constri uma mensagem de resposta contendo os campos: identificao; remetente; veredicto.
O campo de identificao contm a identificao da particular transao a que se refere a
mensagem. No espao de remetente colocada a identidade do n que responde alm de
outras informaes especficas da tarefa executada, como veremos adiante. Finalmente, no
campo de veredicto ser colocada uma indicao a respeito do que ocorreu durante a
execuo do trabalho requisitado. H cinco possibilidades: CANCELADO, EFETUADO,
PREPARADO, IMPOSSIBILITADO ou COMPLETADO. As trs ltimas alternativas so de
uso exclusivo do protocolo bifsico para confirmar intenes e tambm sero postas de lado
nesta seo.
Para todos os efeitos lgicos, tudo se passa como se construir e enviar mensagens, quer de
trabalho ou de resposta, fosse uma "ao elementar" invocada em benefcio da transao em
questo. Como veremos, estes atos recebero tratamento similar as aes elementares
prprias no que diz respeito a proteo contra falhas.
7.3.3 A rvore de Execuo
O plano de execuo da transao descrito por um programa P, da classe PR, recebido pelo
executor de transaes do n de origem. A todo tal programa corresponde uma rvore de
execuo, A(P). As folhas de A(P) sero rotuladas com as operaes bsicas de P, quais
sejam, consultas, atualizaes e transferncias de tabelas. Os ns intermedirios de A(P)
recebero o rtulo de ";" ou de "//". A estrutura de A(P) pode ser lida diretamente a partir da
descrio de P. Mais precisamente, a construo de A(P) pode ser descrita pelo seguinte
procedimento recursivo:
1. se P for da forma P = O, onde O e uma das operaes bsicas, ento A(P) ser formada
por de um nico n rotulado com O ;
2. se P for da forma P = R
1
; ... ; R
n
, ento o procedimento invocado recursivamente para
se obter A(R
i
), para todo i, 1 i n . Isto findo, A(P) formada por uma raiz, rotulada
com ";", tendo como descendentes diretas as n rvores A(Ri), na ordem 1 ... n.
3. se P for da forma P = R
1
// ... // R
n
, o procedimento invocado recursivamente para se
obter A(R
i
), para todo para todo i, 1 i n . Tendo obtido A(R
i
), ento A(P) formada
por uma raiz, rotulada com "//", a qual esto ligadas como descendentes diretas as n
rvores A(R
i
).
Como um exemplo simples, seja
P = (( Q
i
; ( T
i,j
// T
i,k
)) // ( Q
j
; T
j,k
)) ; Q
k
onde Q
i
indica uma consulta a ser processada pelo n i e T
n,m
indica uma transferncia de
tabela do n n para o n m. Ento, P pode ser escrito na forma P = P
1
;P
2
onde
P
1
= (( Q
i
; ( T
i,j
// T
i,k
)) // ( Q
j
; T
j,k
)) e P
2
= Q
k
- 11 -
Ento, de acordo com o passo 2, devemos invocar o procedimento recursivamente para obter
A(P
1
) e A(P
2
). Como P
2
= Q
k
uma operao bsica, segundo o passo 1, A(P
2
) obtida
simplesmente rotulando-se um n com Q
k
. Aps a recurso ter completado A(P
1
), teramos a
rvore como mostra a Figura 7.2 esquerda.
Resta construir A(P
1
). Mas A(P
1
) da forma P
1
= P
11
// P
12
onde
P
11
= Q
i
; ( T
i,j
// T
i,k
) e P
12
= Q
j
; T
j,k

Devemos, segundo o passo 3, apelar de novo recurso a fim de obtermos A(P
11
) e A(P
12
).
Uma vez isto feito, teramos A(P) na forma mostrada direita na Figura 7.2. Embarcando na
recurso para construir A(P
11
), obtemos P
11
= P
111
// P
112
onde
P
111
= Q
i
e P
112
= T
i,j
// T
i,k
e, de acordo com o passo 2, formaramos a rvore indicada na Figura 7.3, esquerda.
A rvore de execuo de P
111
obtida imediatamente pelo passo 1. Um nvel de recurso a
mais e teremos P
112
. Neste ponto, o resultado seria como indicado direita na mesma figura.
Restaria apenas P
12
. O passo 2 seria aplicvel novamente e o resultado final mostrado na
Figura 7.4, concluindo o exemplo.
Da ltima figura est claro como a hierarquia presente em A(P) reflete a estrutura de
parntesis embutida em P. A particular maneira como o exemplo foi ilustrado, ou seja,
construindo-se o nvel mais alto seguido do detalhamento dos nveis mais baixos, no reflete
fielmente a maneira de operar do procedimento recursivo. Este ltimo caminha em sentido
inverso, isto , constroi primeiro as subrvores mais elementares para s depois interlig-las a
uma raiz comum. O resultado final, claro, ser o mesmo.
Considere, agora, as rvores de execuo mostradas na Figura 7.5. A rvore da esquerda
corresponde ao programa P dado por P = ( P
1
// (P
2
//P
3
) // P
4
) o qual, obviamente,
equivalente ao programa P' = ( P
1
// P
2
// P
3
// P
4
) representado pela rvore de execuo
direita, na mesma figura. A concluso a se tirar que, em geral, um n, seja x, com rtulo
"//", tendo como descendente imediato outro n, seja y, tambm com rtulo "//", representa
redundncia desnecessria. A rvore de execuo pode ser refeita eliminando-se o n y e
colocando-se as subrvores imediatas de y como descendentes imediatos de x. Este processo
pode ser repetido at que em nenhum caminho da raiz principal at uma folha encontremos
dois rtulos "//" consecutivos. O mesmo pode ser dito com respeito ao rtulo ";". Em
concluso, pode-se obter, para cada programa P da classe PR, uma rvore de execuo na
forma cannica. Esta forma cannica caracterizada pelo fato de que em toda sequncia de
rtulos encontrados ao se percorrer o nico caminho desde a raiz at uma folha, os rtulos
"//" e ";" aparecem alternadamente. Um programa P da classe PR tido como um programa
na forma cannica se a rvore de execuo A(P), obtida aplicando-se o procedimento
recursivo descrito acima, for da forma cannica. Suporemos que o processador de comandos
da LMD ao construir um programa da classe PR ou, equivalentemente, sua rvore de
execuo, produzir sempre uma estrutura na forma cannica. Note que, dado um programa
qualquer ou sua rvore de execuo construidos pelo processador de comandos da LMD,
seria bastante fcil anexarmos um outro mdulo a este processador que reduziria o produto
final a sua forma cannica.
- 12 -
Figura 7.2 - Construindo uma rvore de execuo - I
Figura 7.3 - Construindo uma rvore de execuo - II
;
A(P11) A(P12)
A(P1)
Qk
// Qk
;
;
A(P12)
Qk
// Qk
;
A(P111) A(P112)
;
A(P12)
//
;
Qi
Tij
//
Tik
- 13 -
Figura 7.4 - Construindo uma rvore de execuo - III
Figura 7.5 - Duas rvores de execuo equivalentes
// Qk
;
Qj Tjk
;
Qi
;
Tij Tik
//
//
P1
//
P2 P3
// P4 P2 P3
P4
P1
- 14 -
importante observar tambm que para cada programa P da classe PR o mtodo descrito
acima produz um nica rvore A(P). A recproca tambm vale, ou seja, para cada rvore A
produzida pelo algoritmo podemos reconstruir o nico programa do qual A a rvore de
execuo. Esta bijeo garante que podemos substituir o plano de execuo da transao, P,
pela sua rvore de execuo, A(P), sem quaisquer prejuzos. Como ilustrao do processo
operando de maneira inversa, o leitor pode verificar que a rvore da Figura 7.6 representa o
seguinte programa da classe PR
P = (( Q
1
; T
1
) // Q
2
// (( A
1
; Q
3
; T
2
) // T
3
))
Existe um outro ponto a considerar. Na prtica, cada rvore A(P) seria implementada como
uma estrutura de dados multiligada. No deve ser inferido, porm, como ilustrado na Figuar
7.4, que todas as rvores de execuo tero estrutura binria. Isto se deve apenas a uma
particularidade do exemplo que foi ento discutido. Em princpio, cada n da rvore de
execuo pode ter qualquer nmero de descendentes diretos. Em consequncia, na
implementao real cada n da rvore dever ter uma lista de ponteiros, um para cada
descendente direto deste n. H mtodos clssicos para se representar rvores cujos ns
podem ter multiplos descendentes de modo a limitar o nmero de ponteiros em cada n. A
Figura 7.7 usa de uma destas representaes para reconfigurar a rvore apresentada na Figura
7.6.
A metodologia para se obter a rvore binria simples
1. as ligaes de cada n com seu descendente imediato mais esquerda so mantidas; as
ligaes com os demais descendentes imediatos desaparecem
2. introduzida uma ligao entre cada dois descendentes imediatos consecutivos de um
mesmo n
As linhas tracejadas na figura so ligaes auxiliares, tambm chamadas de alinhavos. H um
alinhavo indo de cada ltimo descendente imediato de um n at seu ancestral imediato. Esta
particular maneira de transformar rvores gerais em rvores binrias tem a vantagem de que a
cada rvore geral corresponde uma nica rvore binria e vice-versa. As notas bibliogrficas
contm referncias a textos que tratam este assunto em detalhe. Suporemos, de ora em diante,
que a rvore de execuo produzida pelo processador de comandos da LMD seja sempre na
forma binria. Como j acabamos de alertar, isto no implicar em perda de generalidade.
Desta forma, poderemos nos referir ao descendente imediato esquerdo e descendente
imediato direito de cada n da rvore sem introduzir ambigidades.
7.3.4 A Migrao
De posse das rvores de execuo, a intuio que guiar o executor de transaes durante a
migrao de transaes fica transparente. O racional bastante simples. O ponto de partida
sempre um programa da classe PR enviado pelo processador de comandos da LMD ao
executor de transaes local. O n de origem da transao controla todo o processo. De
incio, envia mensagens de trabalho a quantos ns participantes for possvel de modo a atingir
o mximo de paralelismo. A seguir, espera pelas mensagens de resposta destes ns
confirmando o sucesso de cada operao. medida que respostas venham chegando, o n de
origem repete o processo descobrindo que novas operaes podero ser executadas em
paralelo enviando-as, em seguida, para os ns participantes onde devem executar. Aps
aguardar novas mensagens de resposta, o ciclo repetido at completar o processo de
migrao desta transao.
- 15 -
Figura 7.6 - Uma rvore de execuo
Figura 7.7 Uma rvore de execuo com estrutura binria
//
Q2
T1
T2
Q1
; //
T3
;
Q3 A1
//
Q1
T1
Q2
//
;
T3
;
A1
Q3
T2
- 16 -
Durante o processo de migrao, e na ausncia de falhas, o n de origem executa os seguintes
passos bsicos.
1. iniciao;
2. envio de mensagens;
3. execuo de computaes locais, se houver;
4. anlise de mensagens recebidas;
5. se a migrao da transao ainda no terminou, retorne ao passo 2, caso contrrio passa a
gerenciar o trmino da transao.
J um n participante, operando como um escravo, perfaz os seguintes passos eternamente
(falhas recebero um tratamento especial):
1. os agentes locais executam suas tarefas, se houver;
2. quando chegarem mensagens de trabalho, o executor de transaes local inicia e instala os
respectivos agentes locais, liberando-os em seguida para que executem suas tarefas;
3. quando um agente local terminar seu trabalho, comunica tal fato ao executor de
transaes local. Este ltimo envia uma mensagem de resposta ao n de origem da
transao, reportando o veredito cerca da execuo local.
Note, em primeiro lugar, que esta sistemtica vale para cada transao que esteja ativa no BD
a cada instante. Em particular, pode haver vrias transaes com o mesmo n de origem ou
usando os mesmos ns remotos comuns. Em qualquer caso, as transaes so
individualizadas pela identificao que recebem ao passarem pela fase de iniciao executada
pelo gerente de transaes de seu respectivo n de origem. responsabilidade dos
mecanismos de controle de concorrncia garantir a no interferncia de aes elementares
pertencentes a transaes distintas e executadas contra o BD fsico local. Isto posto, podemos
assumir a iluso de que apenas uma transao de cada vez est ativa em todo o BD. Assim,
para entendermos o processo de migrao, basta examinarmos a operao do executor de
transaes em seu n de origem, bem como a operao de um n participante tpico.
Para facilitar o entendimento, ser apresentado a seguir um mecanismo algo simplificado e,
portanto, com certas ineficincias. Quando este estiver claro, as necessrias correes sero
mencionadas e o quadro estar completo. As duas principais hipteses simplificadoras que
assumiremos momentaneamente dizem respeito a operao de um n participante e a falhas.
Talvez a diferena mais gritante esteja no fato de que falhas sero, de momento, ignoradas.
Em adio, no cenrio simplificado, o n de origem envia apenas operaes bsicas aos ns
remotos. Mais tarde, o n de origem ter liberdade para enviar subprogramas completos
envolvendo vrias operaes bsicas.
Tomando primeiro o caso de um n remoto e assumindo que receba apenas operaes
bsicas, no h o que detalhar em relao aos passos bsicos descritos acima para este tipo de
n. A parte de iniciao e instalao de agentes locais j foi discutida na subseo anterior.
Quanto a execuo de uma operao bsica, basta lembrar que o gerente de dados local a
traduz para a LMD local, entregando a traduo ao SGBD local. Este, por sua vez, gera aes
elementares e aciona o agente local, j instalado, para que as execute. Em princpio, a
construo de mensagens de resposta pode ficar a cargo do agente local, e seu envio pode ser
delegado ao executor de transaes. Este ltimo tambm pode ser o mdulo responsvel por
receber mensagens de trabalho e encaminhar seu processamento entre os mdulos locais.
- 17 -
Os mesmos comentrios valem com relao aos passos 1 e 3 do algoritmo bsico apresentado
acima para o n de origem exceto que o passo 1, de iniciao, um pouco mais elaborado,
conforme vimos na subseo anterior. O tratamento do trmino de transaes, previsto no
passo 5, ser alvo da prxima subseo. Resta examinar os passos 2 e 4. O primeiro
corresponde a como proceder para identificar quais as operaes bsicas que podem ser
encaminhadas em paralelo. O segundo diz respeito a como reestruturar a rvore de execuo
com base nas mensagens de resposta que porventura cheguem. Analisaremos estes passos em
seguida. Lembre que estamos trabalhando com rvores na forma cannica e binrias.
Em primeiro lugar, vamos ao algoritmo para decidir, a cada instante, quais operaes bsicas
podem ser enviadas em paralelo para execuo nos vrios ns remotos. O procedimento
consiste em visitar cada n da rvore seguindo uma ordem bem definida. O percurso atravs
da rvore guiado pelo rtulo de cada n. H duas maneiras de se obter o mesmo resultado
final, qual seja, a remessa do maior nmero de operaes que podem ser executadas em
paralelo neste momento segundo previsto na rvore de execuo que temos em mos. Pode-se
acumular as operaes bsicas em uma lista medida que o algoritmo percorre os ns da
rvore e, ao final, despachar todas as operaes aos respectivos ns remotos. Ou pode-se
acionar um mdulo separado para que, medida que estas operaes sejam identificadas, este
ltimo j as despache a ns remotos apropriados. Ficaremos com a segunda alternativa. Esta
opo torna o algoritmo um pouco mais simples e dispensa a lista de ns. Na realidade, no
h diferenas drsticas entre as duas alternativas. Lembre que o algoritmo para identificar os
ns executa em um nico processador, aquele do n de origem. Alm disso, a rvore de
execuo deve conter algumas dezenas, no mximo centenas, de ns. Assim, se adotssemos
a primeira alternativa, construindo a lista de ns, a execuo do algoritmo seria, de qualquer
modo, bem mais rpida que o processo de se enviar mensagens atravs da rede. Para a rede
de comunicaes tudo se passa como se uma fila de mensagens a serem enviadas se
acumulasse instantaneamente, independente do processo de formao da lista de ns. Outro
aspecto importante que a ordem com que as mensagens vo sendo enviadas imaterial.
Lembre que a lista produzida nesta fase constitui-se apenas de operaes que podem ser
executadas em paralelo.
O algoritmo para despachar mensagens ser apresentado recursivamente abaixo atravs do
procedimento ENVIAR_MENSAGENS. Na descrio do procedimento, P o programa PR
a ser analisado, A a raiz da rvore de execuo de P e O uma das operaes bsicas.
1) rtulo de A O: despache O ao n apropriado, junto com seu endereo na rvore de
execuo, e retorne;
2) o rtulo de A "//":
a) siga pelo ponteiro esquerdo de :f/A./ Seja R a raiz da subrvore encontrada;
b) invoque ENVIAR_MENSAGENS(R) recursivamente;
c) se o ponteiro direito de R for um alinhavo, retorne;
d) caso contrrio, atribua a R a raiz da subrvore indicada por este ponteiro
e) retorne ao passo 2b.
3) o rtulo de A ";":
a) siga pelo ponteiro esquerdo de A. Seja R a raiz da subrvore encontrada;
b) invoque ENVIAR_MENSAGENS(R) recursivamente;
c) retorne.
- 18 -
No passo 2 do algoritmo visitamos sucessivameete cada um dos descendentes imediatos da
raiz A. J no passo 3 devemos apenas visitar o descendente imediato mais esquerda da raiz
visto que as operaes especificadas por seus descendentes devem ser executadas na ordem
indicada. Ao construir a mensagem de trabalho, suporemos que o endereo da operao a ser
efetuada, relativo a rvore binria de execuo, seja tambm includo nesta mensagem. Isto
facilitar a anlise das mensagens de resposta relativas a cada solicitao de trabalho. Uma
posio na rvore binria pode ser facilmente indicada atravs de uma sequncia de
caracteres "e" e "d". Neste esquema "e" significaria " esquerda" e "d" indicaria " direita". O
n rotulado "T
j,k
" na Figura 7.4, por exemplo, teria sua posio indicada por edd.
Um exemplo completo servir para clarificar o algoritmo. Assuma que O
1
a O
8
sejam
operaes bsicas e tome P como o programa abaixo
P = (( O
1
// ( O
2
; O
3
); O
4
) // O
5
// ( O
6
; O
7
; O
8
))
A rvore de execuo de P, A(P), mostrada na Figura 7.8 . Os ns esto numerados de 0 a
12 para facilitar referncias. Vamos agora examinar a invocao
ENVIAR_MENSAGENS(A(P)). O mecanismo de recurso ser simulado usando-se uma
pilha auxiliar. O contedo da pilha, a cada instante, refletir as invocaes pendentes. A raiz
de A(P) rotulada "//" e, de acordo com o passo 2, devemos invocar o algoritmo
recursivamente sobre as subrvores cujas raizes so localizadas sobre os ns 1, 2 e 3. Em
consequncia, este ser o contedo da pilha, com 1 no topo. Isto ser indicado como PILHA
= 1,2,3. Desempilhando um n obtemos 1, equivalendo a invocao
ENVIAR_MENSAGENS(A(R)), onde R a subrvore cuja raiz o n 1. Como o n 1
rotulado ";", o passo 3 indica que devemos invocar ENVIAR_MENSAGENS sobre o n 7
apenas. Em termos da pilha, teramos PILHA = 7,2,3. Desempilhando, obtemos o n 7 e o
passo 2 modifica a pilha para PILHA = 9,10,2,3. A prxima chamada recursiva teria como
argumento a rvore com raiz sobre o n 9. Agora o passo 1 despacha a operao bsica O
1
para seu n remoto e reduz a pilha a PILHA = 10,2,3. A prxima invocao de
ENVIAR_MENSAGENS produziria PILHA = 11,2,3 , usando-se o passo 3. Segundo o passo
1, as prximas duas chamadas resultariam no envio das operaes bsicas O
2
e O
5
para
execuo remota e deixariam a pilha na forma PILHA = 3. Mais uma invocao do algoritmo
produziria, pelo passo 3, PILHA = 4. A ltima chamada recursiva enviaria O
6
a seu destino,
esvaziando a pilha. Isto completaria a execuo de ENVIAR_MENSAGENS(A(P)). A
sequncia de mensagens enviadas seria O
1
, O
2
, O
5
e O
6
. Examinando o programa P e a rvore
A(P), podemos constatar que estas seriam exatamente as operaes bsicas que poderiam ser
executadas em paralelo quando a transao iniciasse sua migrao. A Figura 7.8 ilustra o
fato, destacando estas operaes.
Uma vez enviadas as mensagens de trabalho, o n de origem se ocupa de suas obrigaes
locais e aguarda mensagens de resposta. Observe que algumas dentre as operaes bsicas
despachadas podem ter sido escaladas para executar no prprio local de origem. Tambm no
est excludo o cenrio onde um determinado n recebe vrias operaes bsicas para
execuo durante esta fase. importante salientar que o processo assncrono. No exemplo
que acabamos de analisar, isto implica em que as mensagens de resposta no esto obrigadas
a chegar em qualquer ordem pr-especificada. Na prtica, isto depender da carga de cada n
remoto que for acionado.
- 19 -
Figura 7.8 - Despachando operaes binrias em paralelo.
Voltando ao procedimento original que coordena a migrao de transaes a partir do n de
origem, resta examinar o passo 4, qual seja, anlise das mensagens de resposta que chegam.
A idia eliminar da rvore cada n cuja mensagem de resposta tenha chegado e seja
positiva. Isto verificado observando-se o campo de veredito da mensagem de resposta: se
contiver EFETUADO, ento a resposta positiva, se for CANCELADO, negativa.
Enquanto essas eliminaes sucessivas resultarem em que subrvores inteiras j tenham sido
completamente executadas, o processo de eliminao deve ser propagado para os ancestrais
do n. Finalmente, aps o processo de eliminao, a parte da rvore afetada deve ser
reanalisada para se determinar quais as prximas operaes que podem ser executadas em
paralelo. Para tal, o procedimento ENVIAR_MENSAGENS usado. Chamaremos o
processo de anlise de mensagens de resposta de RECONFIGURAR. Note que a mensagem
de resposta contm um campo de identificao e outro de rementente. A partir do primeiro o
executor de transaes do n de origem pode localizar a correspondente rvore de execuo.
Suporemos que no segundo campo o n remetente inclua o endereo, em relao a rvore de
execuo binria, da operao bsica que acabou de completar. O n remetente conhece este
endereo pois esta informao veio com a mensagem de trabalho. A descrio precisa de
RECONFIGURAR segue abaixo. Nesta descrio, A a rvore de execuo e END aponta
para o n a que se refere esta mensagem de resposta. O rtulo O indica uma operao bsica
enquanto que X, Y e Z so variveis auxiliares.
//
//
O4
Q5
;
;
O6
Q7
O8
O1
;
O2
Q3
0
1
7
9 8 3
2
10
11
12
4
5
6
- 20 -
1) se END for a raiz da rvore, ento RECONFIGURAR e a migrao desta transao esto
terminadas. Caso contrrio, partindo de END, siga pela direita at encontrar um n com
alinhavo. Seja Z o n para onde o alinhavo aponta;
2) END no o descendente imediato esquerdo de Z:
a) a partir de Z, siga pela esquerda e depois sempre pela direita at encontrar um n cujo
ponteiro direito aponte para END. Seja Y este n.
b) elimine END da rvore. Basta atribuir ao ponteiro direito de Y o valor do ponteiro
direito de END, mesmo que este seja um alinhavo.
3) END o descendente imediato esquerdo de Z:
a) O ponteiro direito de END no um alinhavo:
i) caminhe uma vez pela direita a partir de END. Seja X o n encontrado;.
ii) elimine END da rvore atribuindo X ao valor do ponteiro esquerdo de Z;
iii) se o rtulo de Z for ";", execute ENVIAR_MENSAGEM(X);
b) O ponteiro direito de END um alinhavo:
i) enquanto o ponteiro direito de END for um alinhavo e END for distinto da raiz da
rvore, caminhe pelo alinhavo. Chame de END o n encontrado.
ii) se END for a raiz da rvore, RECONFIGURAR e tambm a migrao da
transao esto terminadas.
iii) se END no for a raiz da rvore:
(1) siga sempre pela direita at encontrar um n com alinhavo. Seja Z o n para
onde o alinhavo aponta;
(2) seja X o n para onde o ponteiro direito de END aponta;
(3) elimine END da rvore. Basta atribuir X ao valor do ponteiro esquerdo de Z ;
(4) se Z for rotulado ";", execute ENVIAR_MENSAGENS(X)
Antes de apresentar um exemplo h certos comentrios que sero teis. Lembre que o
objetivo eliminar END da rvore. O caso trivial quando toda a rvore de execuo se
resume em apenas um n rotulado com uma operao bsica previsto no passo 1. Ignorando
este caso simples, o passo 1 posiciona Z sobre o ancestral imediato de END. A situao
mostrada na Figura 7.9. Note que END no pode ter descendente esquerda pois uma
operao bsica. Partindo de END e caminhando pela direita at encontrar um n com
alinhavo nos leva ao n W. O alinhavo de W aponta para Z. Isto feito, h duas possibilidades
segundo END ou no o descendente imediato esquerda de Z. O passo 2 trata da segunda
possibilidade. Em 2a, alcanamos primeiro R e, seguindo pela direita, achamos Y. A parte 2b
elimina END da rvore segundo indica a linha tracejada na referida figura. Outro fato a
observar que, na situao do passo 2, o rtulo de Z deve, necessariamente, ser "//". Portanto,
todos os "irmos" de END, isto , os ns de R a W na Figura 7.9, j foram inspecionados pelo
procedimento ENVIAR_MENSAGENS e no devemos repetir o processo neste ponto. Esta
observao crucial. O passo 3 se encarrega do caso quando END o descendente imediato
esquerdo de Z. Observe que END s pode ser o descendente imediato esquerdo de Z, como
mostrado na Figura 7.10, porque Z foi alcanado a partir de um alinhavo no passo 1.
- 21 -
Figura 7.9 - Eliminando uma operao bsica . Caso I
Figura 7.10 - Eliminando uma operao bsica. Caso II
Z
END
X
W
Z
R
Y
END
T
W
- 22 -
Figura 7.11 - Eliminando uma operao bsica. Caso III
Figura 7.12 - Migrao de uma Transao - I
X
W
Z3
Z2
Z4
Z1
END
//
//
O4
Q5
;
;
O7
Q8
O1
;
O2
Q3
0
1
7
9 8 3
2
10
11
12
5
6
- 23 -
A mesma figura serve ao caso 3a. Nesta situao, o n X alcanado imediatamente. Para
eliminar END, basta executar o passo 3ai, conforme indica a linha tracejada. Agora devemos
examinar o rtulo de Z, o ancestral imediato de END. Podemos encontrar tanto "//" como ";".
Se for encontrado "//", os "irmos" de END j foram inspecionados por
ENVIAR_MENSAGENS e no h mais nada a fazer. Caso contrrio, o rtulo ";" e
devemos examinar a prxima subrvore da sequncia. Sua raiz o novo descendente
imediato de Z, esquerda. O passo 3aiii se encarrega disto. Finalmente, quando END for o
descendente imediato esquerdo de Z e, alm disto, seu ponteiro direito for um alinhavo,
chegamos ao caso 3b. Estamos num ponto interessante. Veja a Figura 7.11. Se o rtulo de Z
1
for "//", ento todos os descendentes imediatos de Z
1
j executaram suas tarefas, responderam
e foram eliminados da rvore de execuo. Ou ento o rtulo de Z
1
";" e END o ltimo n
da sequncia de descendentes imediatos de Z
1
. Em qualquer caso, toda a subrvore com raiz
em Z
1
pode ser agora eliminada. Note que a mesma situao pode estar acontecendo com Z
1
e
seu ancestral imediato Z
2
, e assim por diante. O efeito do passo 3bi subir na rvore at
encontrar aquele ancestral de END que ainda tenha outros descendentes imediatos que no
terminaram de executar suas tarefas. claro que se tal n no encontrado chegaremos a raiz
da rvore e, ento, todos os ns j terminaram suas tarefas e o processo de migrao est
completado. Na figura, o passo 3bi repetido 3 vezes at chegarmos a Z
3
. A partir da as
prximas aes j so conhecidas.
Reconsidere a rvore de execuo mostrada na Figura 7.8. J vimos que numa primeira
invocao de ENVIAR_MENSAGENS seriam despachadas as operaes bsicas O
1
O
2
, O
5
e
O
6
. Indicaremos isto com OP = { 1, 2, 5, 6 }. As mensagens de resposta chegaro em ordem
imprevisvel. Suponha que a mensagem de resposta do n 4 chegue primeiro. Executando
RECONFIGURAR(4), passaramos pelo passo 3a, obtendo a rvore da Figura 7.12 e
despacharamos O
7
, resultando em OP = { 1, 2, 5, 7 }. Em seguida chegam as mensagens de
resposta relativas aos ns 2 e 11. A invocao de RECONFIGURAR(2) e
RECONFIGURAR(11) resultaria na rvore da Figura 7.13 e em OP = { 1, 3, 7 }. Chegando a
mensagem de resposta relativa ao n 12 e, em seguida, quela correspondente ao n 5, a
situao evolui para a Figura 7.14 com OP = { 1, 8 }. A mensagem de resposta relativa ao n
9 produziria a rvore da Figura 7.15 e OP = { 4, 8}. O processo completado com as
mensagens de resposta vindas dos ns 8 e 6. O leitor est convidado a repetir a anlise
supondo outras ordens de chegada para as mensagens de resposta.
Os procedimentos ENVIAR_MENSAGENS e RECONFIGURAR completam uma primeira
verso do metodo bsico usado pelo n de origem para controlar a migrao de transaes,
como havamos posto logo n incio desta subseo. Uma das ineficincias que havamos
ento mencionado pode ser agora apreciada.
Considere a rvore de execuo A mostrada na Figura 7.16. Nesta figura Q
m
representa uma
consulta que deve ser dirigida ao n m e T
nm
uma transferncia de tabelas do n n para o n
m. Suponha que o n de origem seja k. Ao invocar ENVIAR_MENSAGENS o executor de
transaes em k vai, ao longo do tempo, mandar 4 mensagens para o n i: uma para cada um
dentre Q
i1
, Q
i2
, T
ij
e T
ik
. Desta forma, os custos inerentes a cada mensagem que enviada,
tais como espao para endereos, para cdigos corretores / detetores de erros, mltiplas
confirmaes (do ingles "akcs") exigidas pelos protocolos de comunicao, seriam
duplicados 4 vezes neste exemplo simples. Sem falar na degradao do tempo de resposta do
sistema em consequncia de mais mensagens enviadas. Seria bem mais racional se toda a
subrvore de execuo com raiz sobre o n 2 fosse enviada ao n i numa nica mensagem de
trabalho. Em paralelo, a subrvore com raiz em 1 seria enviada ao n j.
- 24 -
Figura 7.13 - Migrao de uma Transao - II
Figura 7.14 - Migrao de uma Transao - III
//
//
O4
;
;
O7
Q8
O1
;
O3
0
1
7
9 8 3
10
12
5
6
//
//
O4
;
;
O8
O1
0
1
7
9 8 3
6
- 25 -
Figura 7.15 - Migrao de uma Transao - Concluso
Figura 7.16 - Enviando Subrvores Completas a Ns Remotos
//
//
Tij
;
Oi2
Tik
Oi1
0
2
3
4
6
5
7
Oj
1
//
O4
;
;
O8
0
1
8
3
6
- 26 -
Note que este esquema tambm economiza trabalho local em i pois este teria que iniciar e
instalar apenas um agente local para esta transao. Gostaramos, portanto, de poder
determinar no apenas quais as operaes bsicas que podem ser enviadas em paralelo a cada
instante, mas quais sub-rvores podero ser despachadas em paralelo a cada momento.
Vamos agora descrever uma maneira simples de se identificar sub-rvores completas a serem
despachadas a ns remotos. Para tal, o executor de transaes do n de origem deve, logo
antes de iniciar a migrao da transao, invocar o procedimento recursivo MARCAR que
ser descrito em seguida. Este procedimento incorpora um algoritmo para marcar cada n da
rvore de execuo com a identidade de um n remoto. A idia que se um n i marcado
com a identidade de outro n j ento toda a subrvore da qual i a raiz deve ser enviada ao
n j durante a fase de migrao. Lembre-se, porm, que estamos interessados em identificar
subrvores mximas no sentido de que no enviaremos ao n j a subrvore com raiz em i se o
ancestral imediato de i tiver todos os seus descendentes imediatos, alm de i, tambm
endereados a j. Neste caso, a subrvore "maior" com raiz no ancestral imediato de i ser
enviada a j. Ou talvez uma subrvore ainda mais abrangente, da qual o ancestral imediato de i
apenas um n interno, dever ser encaminhada ao n j. Observe tambm que certos ns
tero parte de seus descendentes imediatos despachados a determinados ns e parte a outros
ns. Nestes casos, tais ns no sero marcados com a identidade de nenhum outro n, pois
que a subrvore de que so raizes sera desmembrada e remetida a vrios ns distintos. O
procedimento MARCAR identifica tais ns com um "*".
Alm deste passo de identificao, o procedimento MARCAR altera localmente a estrutura
da rvore de execuo. A razo para estas alteraes est ilustrada na Figura 7.17.
esquerda temos parte de uma rvore de execuo. A raiz um n rotulado "//", o qual
detm 5 descendentes imediatos, cada um deles, possivelmente, ter toda uma subrvore
ligada a seu ponteiro esquerdo. Como mostra a figura, os ns receberam os nmeros de 1 a 6
guisa de identificao e as subrvores foram chamadas de T
1
a T
5
. Suponha que, por algum
processo, chegou-se a concluso que o n 2 a raiz de uma subrvore que deve ser executada
remotamente pelo n i. Idem, o n 5 identifica uma outra subrvore que deve ser enviada ao
n k, enquanto que 3, 4 e 6 so raizes de subrvores que devem ir para o n j. Isto mostrado
na Figura 7.17, indicando-se o n de destino logo acima da raiz da subrvore. Note que o n
1 recebeu a marca "*" pois seus descendentes imediatos so raizes de subrvores que devem
seguir para ns remotos distintos. Para minimizar o nmero de mensagens enviadas, a rvore
de execuo transformada como indicado na mesma figura, direita. Foi criado um novo
n, n, e os ns 3, 4 e 6, originalmente endereados a j, foram agrupados como descendentes
imediatos de n. Note que a marca de n deve ser, obviamente, j. O ponto importante a observar
que esta manobra se torna possvel porque o n 1 rotulado com "//". Isto indica que a
ordem de execuo de seus descendentes imediatos imaterial.
Dado este fato, a subrvore direita na figura operacionalmente equivalente original,
esquerda. Agora, a subrvore maior com raiz em 1 pode ser executada enviando-se apenas 3
mensagens: uma para o n i descrevendo a subrvore com raiz em 1, outra para k
descrevendo a subrvore com raiz em 5 e uma terceira para j, descrevendo a subrvore com
raiz em n. Antes da transformao, estaramos enviando 5 mensagens para executar a as
mesmas operaes. A Figura 7.18 ilustra a mesma idia aplicada a um n rotulado ";". O
mesmo mecanismo ainda usado apenas que devemos agora respeitar a ordem de execuo
das subrvores, conforme especificado inicialmente. Por esta razo, o novo n agrupa apenas
as subrvores que tinham os ns 2 e 3 como raizes originais.
- 27 -
Figura 7.17 - A transformao local operada por MARCAR - I
Na descrio do procedimento MARCAR, em seguida, A representa a raiz da rvore de
execuo e O uma operao bsica.
1) se A est rotulada com O: marque este n com a identidade do n remoto onde esta
operao bsica deve executar e retorne;
2) se A est rotulada com "//":
a) recursivamente, invoque MARCAR sobre cada um dos descendentes imediatos de A;
b) se todos os descendentes imediatos de A tem a mesma marca, ento marque A de
forma idntica e retorne;
c) caso contrrio:
i) execute GRUPARP(A);
ii) marque A com "*" e retorne.
3) se A est rotulada com ";":
a) recursivamente, invoque MARCAR sobre cada um dos descendentes imediatos de A ;
b) se todos os descendentes imediatos de A tem a mesma marca, ento marque A de
forma idntica e retorne;
c) caso contrrio:
i) execute GRUPARS(A);
ii) marque A com "*" e retorne.
T1
//
T2
T3
T5
1
i
j
k
j
j
T4
2
3
4
5
6
T1
//
//
T2
T5
1
i
j
j
j
j
T3
2
n
3
4
6
k 5
T4
* *
- 28 -
Figura 7.18 - A transformao local operada por MARCAR - II
A lgica do procedimento transparente e dispensa maiores comentrios. Est claro que
GRUPARP tem como funo agrupar os descendentes imediatos de um n interno rotulado
"//". J GRUPARS perfaz a mesma tarefa quando o rtulo do n em questo ";". A
descrio dos procedimentos GRUPARP e GRUPARS constitui-se num bom exerccio em
estruturas de dados. O leitor deveria tentar esquematiz-los antes de ler a soluo proposta
abaixo.
Seja R a raiz de uma rvore de execuo. Uma soluo simples para GRUPARP usaria uma
tabela auxiliar onde cada linha indica um grupo distinto de ns que ser construdo. Cada
linha formada por 4 campos: CONT, IDENT, INIC e FIM. Os campos INIC e FIM so
ponteiros para o comeo e fim de uma lista encadeada de ns que formaro um grupo. O
campo de CONT um simples contador que indicar o nmero de ns j arrebanhados para
um mesmo grupo. O campo IDENT conter o endereo do n remoto para onde este grupo
ser despachado. Finalmente, x, y, Z e i so variveis auxiliares.
1) desa pela esquerda de R, achando o n Z.
2) enquanto Z for diferente de x faa:
a) seja i a marca de x;
b) no existe na tabela uma linha cujo campo IDENT i :
i) em uma linha vaga, marque o campo IDENT como i e o campo CONT como 1. Os
campos INIC e FIM devem apontar para Z ;
T1
//
T2
T3
T5
1
i
j
k
j
j
T4
2
3
4
5
6
T1
//
//
T2
1
i
j
j
j
T3
2
n
3
4
T4
k
j
T5
5
6
* *
- 29 -
c) existe na tabela uma linha cujo campo IDENT seja i :
i) incremente CONT de 1 ;
ii) seja x o n apontado por FIM. O ponteiro direito de x e tambm de FIM devem
apontar para Z ;
d) siga pelo ponteiro direito de Z. Chame de Z o n encontrado.
3) para cada linha da tabela cujo campo de CONT maior que 1 :
a) crie um novo n rotulado com "//". Seja y este n.
b) o ponteiro esquerdo de y recebe o valor de INIC ;
c) o ponteiro direito do n apontado por FIM recebe um alinhavo apontando para y ;
d) INIC recebe um ponteiro para y .
4) seja n o nmero de linhas utilizadas na tabela auxiliar.
5) percorra, em sequncia, as linhas da tabela, desde a linha 1 at a linha n-1, e faa o
seguinte:
a) seja i a presente linha ;
b) o ponteiro direito do n apontado pelo campo INIC da linha i deve receber o valor do
campo INIC da linha i+1 .
6) o ponteiro direito do n apontado pelo campo INIC da linha n deve receber o alinhavo
apontando para R .
7) o ponteiro esquerdo de R deve apontar para o n indicado no campo INIC da linha 1
A execuo da rotina GRUPARP aplicada raiz da rvore de execuo indicada esquerda
na Figura 7.17 dever produzir a rvore indicada direita na mesma figura. Deixamos a
cargo do leitor convencer-se de que GRUPARP produz as transformaes desejadas.
A rotina GRUPARS poderia ser bastante semelhante a GRUPARP. Como agora estamos
forados a observar a ordem sequencial especificada na rvore original, pode-se, entre outras
melhorias, dispensar a tabela auxiliar e construir os grupos medida que os ns so visitados.
Por uma questo de completude, GRUPARS est detalhada abaixo. Aqui, R ainda a raiz da
rvore original e X, Y, T e N so variveis auxiliares:
1) posicione T = R ;
2) desa pelo ponteiro esquerdo de R. Seja X o n encontrado .
3) posicione Y = X ;
4) enquanto o ponteiro direito de y no for um alinhavo e a marca de x for idntica a marca
de Y, siga pelo ponteiro direito de Y. Chame de Y o n encontrado.
5) se X for distinto de Y, ento :
a) crie um novo n, N, rotulado com ";" e cuja marca idntica a de X ;
b) o ponteiro esquerdo de N deve apontar para X ;
c) X posicionado sobre o n indicado pelo ponteiro direito de Y ;
d) o ponteiro direito de Y deve receber um alinhavo apontando para N ;
e) se T for idntico a R, ento o ponteiro esquerdo de T deve apontar para N, caso
contrrio, o ponteiro direito de T aponta para N.
- 30 -
f) se X for
i) idntico a R, ento N recebe um alinhavo para R; retorne;
ii) distinto de R, ento:
(1) o ponteiro direito de N aponta para X ;
(2) posicione T em N e Y em X ;
(3) volte ao passo 4 .
6) se X for idntico a Y ento:
a) se o ponteiro direito de X indicar R, ento retorne.
b) caso contrrio:
i) posicione T sobre X ;
ii) siga pelo ponteiro direito de X. Chame de X o n encontrado.
iii) posicione Y sobre X ;
iv) volte ao passo 4.
tambm deixada ao leitor a tarefa de familiarizar-se com a lgica de GRUPARS. Em
particular, a Figura 7.18 pode servir como teste em uma simulao manual das instrues
deste procedimento.
Note que o n de origem invoca o procedimento MARCAR apensa uma vez, quando do
incio da migrao. Isto feito, aciona a rotina de ENVIAR_MENSAGENS a fim de despachar
mensagens de trabalho para ns remotos. As mensagens contm, em geral, a descrio de
partes da rvore de execuo. Ao receber mensagens de resposta, o n de origem invoca o
procedimento RECONFIGURAR para eliminar partes da rvore de execuo. Note que
RECONFIGURAR, ao eliminar a raiz de uma subrvore est, na realidade, retirando toda
esta subrvore da rvore original. O prprio procedimento RECONFIGURAR invoca
ENVIAR_MENSAGENS novamente, quando ento novas mensagens so despachadas e o
ciclo se repete. ENVIAR_MENSAGENS e RECONFIGURAR precisam ser levemente
modificadas.
No caso de ENVIAR_MENSAGENS, agora no mais precisamos descer recursivamente a
nvel de uma operao bsica, mas paramos quando encontrado um n intermedirio cujo
rtulo seja diferente de "*". Esta modificao fcil de ser introduzida e o resultado
mostrado abaixo. Para evitar ambiguidades, chamaremos o procedimento modificado de
N_ENVIAR_MENSAGENS. Supomos que o procedimento MARCAR j foi executado e
todos os ns da rvore detm uma marca, indicando o endereo remoto onde a subrvore com
raiz neste n deve executar, quando for o caso. Na descrio do procedimento, P o
programa PR a ser analisado, A a raiz da rvore de execuo de P, O uma operao bsica
e R uma varivel auxiliar
1) A rotulada O: despache O a seu n remoto, junto com seu endereo relativo rvore de
execuo, e retorne.
2) A rotulada "//":
a) se a marca de A for "*", ento:
i) siga pelo ponteiro esquerdo de A. Seja R a raiz da subrvore encontrada;
- 31 -
ii) invoque N_ENVIAR_MENSAGENS(R) recursivamente;
iii) se o ponteiro direito de R for um alinhavo, retorne;
iv) caso contrrio, siga por este ponteiro direito. Chame de R o n encontrado;
v) retorne ao passo 2a.ii;
b) caso contrrio, envie A completa para o n remoto cuja identidade a marca de A.
3) A rotulada ";":
a) se a marca de A for "*", ento invoque N_ENVIAR_MENSAGENS(R)
recursivamente, onde R a subrvore cuja raiz dada pelo ponteiro esquerdo de A;
caso contrrio, envie A completa para o n remoto cuja identidade a marca de A .
A modificao sobre RECONFIGURAR se deve ao fato de que precisa invocar N_ENVIAR_
MENSAGENS e no mais ENVIAR_MENSAGENS. Chamando de N_RECONFIGURAR a
nova verso, teremos a rotina abaixo onde A a rvore de execuo e END uma varivel
que aponta para o n cujo endereo veio com a mensagem de resposta. O rtulo O indica uma
operao bsica enquanto X, Y e Z so variaveis auxiliares:
1) se END for a raiz da rvore, ento N_RECONFIGURAR e a migrao desta transao
esto terminadas. Caso contrrio, partindo de END siga pela direita at encontrar um n
com alinhavo. Seja Z o n para onde o alinhavo aponta ;
2) END no o descendente imediato esquerdo de Z :
a) a partir de Z, siga pela esquerda e depois sempre pela direita at encontrar um n cujo
ponteiro direito aponte para END. Seja y este n;
b) elimine END da rvore. Basta atribuir ao ponteiro direito de y o valor do ponteiro
direito de END, mesmo que este seja um alinhavo.
3) END o descendente imediato esquerdo de Z :
a) O ponteiro direito de END no um alinhavo:
i) caminhe uma vez pela direita a partir de END. Seja x o n encontrado.
ii) elimine END da rvore atribuindo x ao valor do ponteiro esquerdo de Z;
iii) se o rtulo de Z for ";", execute N_ENVIAR_MENSAGEM(x)
b) O ponteiro direito de END um alinhavo:
i) enquanto o ponteiro direito de END for um alinhavo e END for distinto da raiz da
rvore; caminhe pelo alinhavo. Chame de END o n encontrado.
ii) se END for a raiz da rvore, N_RECONFIGURAR e tambm a migrao da
transao esto terminadas.
iii) se END no for a raiz da rvore:
(1) siga sempre pela direita at encontrar um n com alinhavo. Seja Z o n para
onde o alinhavo aponta;
(2) seja x o n para onde o ponteiro direito de END aponta;
(3) elimine END da rvore. Basta atribuir x ao valor do ponteiro esquerdo de Z ;
(4) se Z for rotulado ";", execute N_ENVIAR_MENSAGENS(x) .
- 32 -
Observe que cada agente local instalado em n remoto deve, agora, perfazer uma tarefa algo
mais complexa do que simplesmente executar uma operao bsica. Precisa executar uma
rvore de execuo em princpio to complexa quanto aquela do n de origem. A nica
diferena que todas as operaes bsicas sero executadas localmente. Antes de consolidar
todo o processo, porm, vamos examinar um outro ponto muito importante.
Em relao a situao simplificada inicial, resta um tipo de evento que merece ateno: so as
falhas que podem se abater tanto sobre o n original quanto sobre os ns remotos. Ha vrios
aspectos a serem mencionados. Em primeiro lugar, uma falha primria em qualquer n
remoto destroi o contedo da memria principal, levando consigo todos os agentes locais e
respectivos descritores que se encontravam ativos quando do instante da falha. Em segundo
lugar, e necessrio que o n de origem seja informado a respeito do fato que um n remoto
falhou. Para compreender este ponto, suponha que tal no fosse o caso. Neste cenrio, o n
remoto falha e se recupera. A seguir, chega a prxima mensagem de trabalho endereada a
este n remoto. Este ltimo, simplesmente, responderia com a instalao de um agente local
para operar em favor da transao, como faria se no tivesse falhado. Apenas que, como j
perdeu os descritores e agentes locais relativos a esta transao, tudo se passaria no local
remoto como se esta fosse a primeira mensagem de trabalho para esta transao. Tanto o n
de origem quanto este n remoto prosseguiriam executando normalmente, embora parte do
trabalho desta transao no local remoto j tivesse sido perdido quando da falha. Em terceiro
lugar, note que tambm podem ocorrer falhas em cascata. Neste caso, o sistema volta a falhar
no exato instante em que est a se recuperar de uma falha anterior. preciso que os
algoritmos levem este fato em conta e que, ao serem invocados, no provoquem
inconsistncias. Em quarto lugar, lembre que a cada n, remoto ou no, facultado cancelar
uma transo, unilateralmente e a qualquer instante, desde que antes de iniciada a segunda
fase do protocolo bifsico para confirmar intenes, como veremos na prxima subseo.
Transaes podem ser canceladas unilateralmente devido a um nmero de causas, entre elas a
necessidade de quebra de bloqueios globais, ou mesmo locais. Finalmente, vale ressaltar que
estaremos preocupados apenas com falhas primrias. Falhas secundrias e tercirias afetam a
memria secundria do sistema e sero alvo de estudo no Captulo 9.
A seguir vamos descrever a rotina completa que deve ser seguida pelo executor de transaes
em cada n. Alm de introduzir o tratamento contra falhas, o algoritmo no faz mais
distino entre n remoto ou n de origem, descrevendo o processo de execuo de
transaes de maneira indistinta quanto a funo original de cada n.
EM OPERAO NORMAL: assincronamente,
1) os agentes locais esto operando em favor de vrias transaes, sob o controle do SGBD e
do do executor de transaes locais;
2) ao receber uma rvore de execuo do processador de comandos da LMD presente neste
n, o executor de transaes local:
a) computa a lista de ns participantes;
b) aciona os mecanismos de controle de integridade para por a lista de ns a salvo, junto
com a identificao da transao;
c) invoca o procedimento MARCAR sobre a rvore de execuo;
d) invoca o procedimento N_ENVIAR_MENSAGENS sobre a rvore de execuo.
3) ao receber uma mensagem de resposta m referente a uma transao T, o executor de
transaes local investiga o campo de veredito de M :
- 33 -
a) se constar EFETUADO, invoca o procedimento N_RECONFIGURAR tendo como
parmetros a rvore de execuo de T e o endereo de um n interno da rvore,
endereo este que veio codificado no campo de remetente de M ;
b) se constar CANCELADO e o protocolo bifsico ainda no foi invocado em favor de T
i) pe a salvo um registro indicando que o protocolo bifsico deve ser invocado,
forando o cancelamento de T ;
ii) inicia a execuo do protocolo bifsico para confirmar intenes;
iii) aps execuo do protocolo bifsico, T est completa e pode desaparecer do BD ;
4) quando o executor de transaes deteta que a fase de migrao de uma transao T est
completa:
a) coloca a salvo um registro indicando que iniciou a execuo do protocolo bifsico
com vistas a T ;
b) embarca na execuo do protocolo bifsico;
c) aps a execuo do protocolo, T est terminada e desaparece do BD;
5) para toda mensagem de trabalho M recebida por este n, o executor de transaes local :
a) verifica se esta transao j consta como ativa neste n consultando sua tabela de
transaes ativas. Em caso negativo, registra em lugar seguro o fato de que agora esta
transao j est ativa neste n, adicionando tambm sua identidade tabela de
transaes ativas;
b) inicia e instala um agente local para servir a esta requisio;
c) extrai a rvore de execuo do campo de descrio de M ;
d) invoca o procedimento EXTRAIOP sobre esta rvore;
6) cada vez que o executor de transaes identifica que as tarefas requisitadas em uma
mensagem de trabalho esto completas:
a) constri uma mensagem de resposta, preenchendo o campo remetente com a
identidade deste n remoto mais o endereo, relativo a rvore de execuo original, da
raiz da subrvore que recebeu para executar. O campo identificao preenchido com
a identificao da transao e, finalmente, o campo de veredito com EFETUADO;
b) envia a mensagem de resposta ao n de origem;
c) extingue o agente local correspondente;
7) se algum agente externo vlido decide pelo cancelamento de uma transao T originria
neste n, ento:
a) registra em lugar seguro que o protocolo bifsico ser invocado em favor de T ;
b) aciona o executor de transaes para que este invoque o protocolo bifsico com
inteno de forar o cancelamento da transao;
8) se algum agente externo vlido decide pelo cancelamento de uma transao T/ que est
executando remotamente n, ento:
a) constri uma mensagem de resposta com campo de remetente preenchido com a
identidade deste n, campo de identifio refletindo a identidade da transao e
campo de veredito CANCELADO;
b) envia a mensagem ao n de origem.
- 34 -
EM CASO DE FALHA: ao se recuperar de uma falha, o mecanismo de controle de
integridade acionado e assume o controle. Os registros de que dispe so recuperados. Para
cada registro encontrado, indicando que trabalho foi iniciado em favor de uma transao T se:
1) encontra um outro registro indicando que o protocolo bifsico para esta transao j foi
iniciado, ento o controle de integridade repassa esta informao ao executor de
transaes para que este ltimo complete a estratgia prescrita pelo protocolo bifsico;
2) se o protocolo bifsico em favor de T ainda no foi iniciado e T estava executando
remotamente neste n, ento:
a) constri uma mensagem de resposta com campo de remetente preenchido com a
identidade deste n, campo de identifio refletindo a identidade da transao e
campo de veredito CANCELADO;
b) envia a mensagem ao n de origem;
3) se o protocolo bifsico em favor de T ainda no foi iniciado e T tinha neste n seu n de
origem, ento:
a) registra em lugar seguro que o protocolo bifsico ser invocado em favor de T;
b) aciona o executor de transaes para que este invoque o protocolo bifsico com
inteno de forar o cancelamento da transao.
O procedimento EXTRAIOP uma verso simplificada do procedimento
ENVIAR_MENSAGENS. Note que, agora, sabemos que as operaes bsicas recebidas
atravs de mensagens sero todas executadas no presente n remoto. Se A representar a raiz
da rvore de execuo e O for uma das operaes bsicas, EXTRAIOP procede como
indicado abaixo.
1) A rotulada O: instale e inicie um agente local para esta transao. Repasse O para este
agente e retorne;
2) A rotulada "//":
a) siga pelo ponteiro esquerdo de A. Seja R a raiz da subrvore encontrada.
b) invoque EXTRAIOP(R) recursivamente.
c) se o ponteiro direito de R for um alinhavo, retorne;
d) caso contrrio, atribua a R a raiz da subrvore indicada por este ponteiro;
e) retorne ao passo 2b.
3) A rotulada ";":
a) siga pelo ponteiro esquerdo de A. Seja R a raiz da subrvore encontrada;
b) invoque EXTRAIOP(R) recursivamente;
c) retorne.
O resto desta subseo ser dedicado a uma discusso do algoritmo que acabamos de
apresentar. Em primeiro lugar, vamos examinar o processo de execuo de transaes em
operao normal. uma consolidao das observaes que fizemos at agora a respeito do
incio, migrao e trmino de transaes tanto para ns remotos quanto para ns de origem de
novas transaes. A nica rotina ainda no especificada por completo o protocolo bifsico
- 35 -
para confirmao de intenes. Este ltimo ser detalhado na seo seguinte. Os tens listados
tratam dos vrios tipos de eventos que podem ocorrer, assincronamente, em cada n.
Na ausncia de novas transaes, se mensagens de trabalho no chegam e ainda se as tarefas
locais no se completaram, dispensando mensagens de resposta, temos apenas os agentes
locais a executarem suas funes. o cenrio do passo 1. Parte do trabalho de cada agente
local, a nvel de ao elementar, deve ser resguardado de danos causados por eventuais
falhas. Lembre que cada n deve ser capaz de desfazer/refazer os efeitos das aes
elementares de cada transao que execute localmente. Como isto pode ser conseguido ser
descrito no Captulo 9. Os mecanismos de controle de concorrncia, a serem estudados no
Captulo 8, provem a iluso de que s esta transao est a executar no BD, neste instante.
Podemos, portanto, raciocinar sob esta hiptese.
Os trs prximos tens, 2, 3 e 4, descrevem o comportamento deste n quando uma nova
transao submetida localmente. Os tens 5 e 6 especificam o comportamento deste n
quando solicitado por outro a operar remotamente em favor deste ltimo. O procedimento
adotado quando um agente externo decide cancelar a transao descrito nos passos 7 e 8.
Agentes externos vlidos podem ser, por exemplo, o prprio usurio ou o mdulo
responsvel por levantar bloqueios.
O passo 2 especifica que a lista de ns participantes deve ser protegida. Em seguida, o
procedimento MARCAR acionado para determinar as subrvores mximas que podero ser
despachadas a cada n, conseguindo o mximo de paralelismo possvel. Esta rotina chama,
internamente, as rotinas GRUPARP e GRUPARS que modificam localmente a estrutura da
rvore de execuo. Isto permitir que o prximo mdulo a ser invocado pelo passo 2,
N_ENVIAR_MENSAGENS, despache as subrvores a seus respectivos destinatrios
remotos. Note que uma das subrvores selecionadas pode ser destinada a executar
localmente, no prprio n de origem. Aps enviadas as mensagens de trabalho, o cenrio do
passo 1 volta a se apresentar: os agentes locais, em cada n ativado, se desincumbem de suas
respectivas tarefas. Quando mensagens de resposta comeam a chegar, o cdigo do passo 3
entra em ao. Como estamos supondo que falhas no ocorrem, apenas o caso "a" ser
ativado. O campo de veredito de cada mensagem de resposta conter EFETUADO. A seguir,
o procedimento N_RECONFIGURAR invocado. Este ltimo, ento, elimina da rvore de
execuo toda a subrvore que estava a executar remotamente e cuja mensagem de resposta,
indicando sucesso na execuo, estamos a analisar. Finalmente, a prpria rotina
N_RECONFIGURAR j aciona novamente a rotina N_ENVIAR_MENSAGENS que se
encarrega de despachar novas subrvores para execuo remota.
Sob requisio de trabalho vinda de outro local, cada n se comporta conforme especificado
nos passos 5 e 6. No primeiro, so descritas as aes correspondentes a recepo de
mensagens de trabalho. O executor de transaes local instala um agente local e inicializa seu
descritor. Passa, a seguir, a analisar as especificaes da rvore que veio com a mensagem de
trabalho. Aqui, h duas estratgias bsicas a seguir, a escolha dependendo de fatores locais de
cada n. No procedimento acima, optou-se por invocar a rotina EXTRAIOP sobre esta
rvore. Note que, assim procedendo, poderemos estar criando vrios agentes locais para
operarem em benefcio desta transao, caso EXTRAIOP detete a chance de executar mais de
uma operao bsica em paralelo. O custo envolvido com a criao e coordenao destes
processos locais deve ser ponderado contra a opo de instalarmos apenas um agente local
para esta solicitao. Neste ltimo caso, as operaes bsicas prescritas na rvore de
execuo recebida seriam executadas uma por vez, mesmo que houvesse oportunidade para
explorarmos paralelismos inerentes a natureza do problema. Finalmente, chegamos a situao
- 36 -
onde o executor de transaes deteta que o trabalho solicitado por uma mensagem anterior j
est completo. Devemos executar o passo 6. Uma mensagem de resposta construida e
encaminhada ao n que solicitou o trabalho. O campo de veredito desta mensagem deve
conter EFETUADO. Claro, se o presente n , tambm, o n de origem da transao, ento a
mensagem pode ser dispensada. Sob estas condies, o executor de transaes deve, agora,
executar os passos previstos no tem 3.
Para terminar esta subseo, vamos discutir os pontos mais relevantes no combate a falhas.
responsabilidade do controle de integridade invocar aes especificas quando o sistema est a
se recuperar de falhas. Embora deixemos os detalhes para o Captulo 9, cabe, neste ponto,
uma viso simplificada das operaes que sero executadas. Ao retornar de uma falha cada
n tem condies de:
1) recuperar a identidade de cada transao que migrou para este n e ainda no foi
confirmada ou cancelada;
2) recuperar a identidade e a lista de ns participantes de cada transao que originou neste
n e ainda no terminou sua execuo;
3) refazer/desfazer cada ao elementar de toda transao que foi ativada sobre este n;
4) recuperar o texto de mensagens que ainda no processou e para as quais j enviou as
correspondentes confirmaes de recebimento.
Os passos 2 e 5 garantem os dois primeiros tens. Note que o protocolo de comunicaes s
deve liberar a confirmao de recebimento da mensagem (o "ack") aps o n recipiente ter
salvo a prpria mensagem. Do contrrio, a confirmao poderia ser enviada e, antes da
mensagem ser analisada, o sistema local pode cair, pondo a perder o texto da mensagem. A
confirmao funciona como um recibo, assinado pelo recipiente, de que a mensagem chegou
e est a salvo. O terceiro tem garantido pelo modo de operar de cada agente local, os quais
tomam cuidados especiais para preservar a capacidade de desfazer/refazer aes elementares.
Isto feito usando os mecanismos de controle de integridade, conforme detalhado no
prximo captulo.
Tome agora um n que est se recuperando de uma falha. Abstraindo detalhes, o processo de
recuperao envolveria, a grosso modo e alm de outras medidas, as operaes indicadas
anteriormente. Cada transao que executou remotamente neste n ter seu n de origem
avisado deste fato, pois receber uma mensagem de resposta cujo campo de descrio contm
CANCELADO. A identidade do n de origem pode ser obtida analisando-se a prpria
sequncia de caracteres que formam a identificao da transao. A execeo feita quelas
transaes que j tenham embarcado na execuo do protocolo bifsico se justifica na medida
em que este protocolo deve operar de forma robusta com relao a possveis falhas. Desta
forma, uma vez iniciado, o protocolo ira at o fim, garantindo a confirmao ou
cancelamento da transao, conforme o caso. O efeito das mensagens de CANCELADO
junto a cada n de origem ser, primeiro, registrar em lugar seguro que esta transao esta
sendo cancelada. Em seguida, o n de origem inicia a execuo do protocolo bifsico para
cancelar a transao globalmente. Isto previsto no passo 3. Ao se verificar uma falha
remota, portanto, estamos elegendo por cancelar a transao globalmente. Note que, se um n
remoto voltar a cair durante esta fase de recuperao, tornar a enviar mensagens de resposta
com veredito de CANCELADO ao n de origem, causando com que mltiplas mensagens
referentes a "mesma" falha sejam recebidas por este ltimo. Conforme estipulado no passo 3,
porm, antes de iniciar a execuo do protocolo bifsico com o intuito de cancelar esta
transao, um registro deste fato posto a salvo no local de origem. Quando o n de origem
- 37 -
receber mltiplas mensagens causadas por este tipo de falhas em cascata, o passo 3b detetar
que o protocolo bifsico j inciou, evitando sua reexecuo. Observe que este esquema
tambm funciona se mensagens mltiplas forem causadas por falhas em vrios ns remotos
que participaram da execuo de uma mesma transao. Para transaes originrias no local
da falha, o passo 3 estipula a imediata execuo do protocolo bifsico com o intuito de
cancelar a transao. Novamente, antes de iniciar a execuo do protocolo, um registro
salvo indicando este fato. Se o n volta a falhar durante este perodo de recuperao, apenas
as transaes ali originrias para as quais o protocolo ainda no tinha sido ativado que
passaro por este processo. A robustez do prprio protocolo bifsico garante os resultados
deste ponto em diante.
7.4 TRMINO DE TRANSAES
Esta ltima seo discute o protocolo bifsico para confirmar intenes. A importncia do
protocolo reside no fato de que se coloca como o ltimo mdulo que invocado durante a
vida de uma transao. responsvel por garantir a propriedade de atomicidade inerente ao
conceito de transao. No fosse a eventualidade de falhas que podem vir a perturbar a
operao normal do sistema, obter o consenso de todos os ns participantes quanto a cancelar
ou confirmar determinada transao seria tarefa muito simples. A imprevisibilidade das
falhas, aliada ao efeito danoso de destruirem o contedo da memria principal, torna o
problema de se chegar a uma deciso consensual bem mais complexo.
Nesta seo estamos assumindo que os mecanismos de controle de integridade funcionem a
toda prova, protegendo todo registro que lhe seja confiado contra quaisquer tipos de falhas.
Mais ainda, estes registros podero ser recuperados intactos quando o sistema que falhou
estiver no processo de recuperao para voltar operao normal. No importando o tipo ou
a severidade da catstrofe, suporemos que sempre poderemos recuperar qualquer informao
vital que se fizer necessria. Para isto, necessrio que este tipo de informao seja
reconhecida pelos algortmos que descreveremos e, tambm, que seja expressamente passada
aos mecanismos de controle de integridade antes do instante crucial quando assumimos que
sobrevivam a falhas. S desta maneira poderemos estar seguros de que estes registros estaro
efetivamente protegidos. Note-se que, muitas vezes, a informao a resguardar est localizada
em um n remoto, forando troca de mensagens para que o n em questo tenha como certo
que o n remoto j tomou as devidas providncias. Este fato um dos mais srios
complicadores que se apresentam quando tentamos desenvolver um protocolo bifsico, visto
que d margem a que os mltiplos ns envolvidos falhem, talvez vrias vezes, permitindo que
situaes complexas se desenvolvam. Seguindo este racional, o princpio bsico que norteia
as aes preventivas que sero tomadas para garantir proteo contra falhas pode ser
resumido no seguinte paradigma.
Ao nos depararmos com informao vital
1. tentamos salvar tudo que for necessrio, repassando a informao aos mecanismos de
controle de integridade;
2. s aps o sucesso desta operao, podemos continuar do ponto onde havamos parado
anteriormente.
Como veremos adiante, uma das inconvenincias que pode resultar deste tipo de
procedimento que os vrios ns envolvidos no processo estaro sujeitos a receber mltiplas
mensagens descrevendo o "mesmo" evento. Tipicamente, o remetente falhou e, ao se
recuperar da falha, torna a falhar pela segunda vez. Ao retornar da segunda falha, refaz uma
- 38 -
srie de aes, entre as quais o envio de mensagens que j tinham sido despachadas quando
se recuperava da primeira falha. o prprio processo de recuperao que leva um n a repetir
mensagens, e no um mau funcionamento da rede de comunicao de dados. Tendo em
mente o paradigma posto acima, podemos recolocar o esquema bsico para trmino de
transaes, descrito no Captulo 6, como abaixo. Nesta descrio, e em todo o resto desta
seo, assumiremos que o n de origem da transao estipulado como o coordenador da
operao. A razo simples: o n de origem o nico que dispe da lista de todos os ns
participantes. Mais ainda, esta lista est a salvo neste n.
NUMA PRIMEIRA FASE
1) coordenador:
a) registra em lugar seguro que iniciar o envio de mensagens exploratrias;
b) envia, a todos os ns participantes, mensagens de consulta na tentativa de saber se
todos esto aptos a executar o protocolo;
c) espera pelas mensagens de resposta dos ns remotos;
2) cada n participante:
a) ao receber a mensagem tenta registrar os efeitos locais da transao em lugar seguro;
b) pe a salvo um registro indicando o sucesso ou insucesso da operao;
c) se foi bem sucedido, responde ao coordenador que est preparado para prosseguir.
Caso contrrio, responde que no poder continuar;
d) espera pelo veredito final do coordenador.
NUMA SEGUNDA FASE
1) coordenador:
a) baseado nas respostas encaminhadas pelos ns participantes, determina o veredito
final com relao ao destino da transao;
b) registra o veredito final em lugar seguro;
c) envia a todos os ns participantes uma mensagem descrevendo seu veredito final;
d) espera por mensagens, uma de cada n participante, confirmando que tomou as
medidas estipuladas de acordo com o veredito final;
e) aps a chegada de todas as mensagens confirmatrias, o executor de transaes local
termina o processamento em favor desta transao, a qual desaparece do BD;
2) cada n participante:
a) ao receber o veredito do coordenador, age de acordo com este;
b) coloca a salvo um registro, indicando o destino desta transao;
c) envia ao coordenador uma mensagem de resposta, confirmando que agiu de acordo
com o veredito que recebeu;
d) cancela os agentes locais que operavam em benefcio desta transao.
Repare como feito um esforo para observar o paradigma, exposto anteriormente, que fora
o registro da inteno antes de executar qualquer ao correlata.
Vamos agora embarcar na descrio do protocolo bifsico em detalhe. Antes, porm,
- 39 -
lembraremos os pontos principais que sero importantes para a compreenso do mesmo. Com
relao aos protocolos responsveis pela comunicao entre os ns da rede, relembrando,
suporemos que so confiveis ao ponto de podermos assumir que toda mensagem
despachada:
chega a seu destino correto em tempo finito;
no entregue em endereo errado;
no deturpada ao ser transmitida;
no tem sua ordem trocada, isto , mensagens partindo de um mesmo emitente para um
mesmo recipiente chegaro na mesma ordem que foram enviadas;
no duplicada.
Outro aspecto importante com relao aos protocolos de comunicao de dados diz respeito
ao envio de confirmaes ("acks") pelo n recipiente. A confirmao s enviada aps a
mensagem estar a salvo, em lugar seguro, no destinatrio. Suponha que uma mensagem M
enviada do n x para o n y. Se, quando M chegar, y no est em operao normal e o
contedo de M perdido, ento o protocolo de comunicao se encarregar de reenviar M,
visto que x no recebe qualquer confirmao em tempo hbil com relao a M. O mesmo se
passa se, quando M chega a y, este est operando normalmente mas falha antes de ter
conseguido salvar M em lugar seguro. Ainda neste caso, x no recebe a confirmao e o
protocolo de comunicao de dados tomar a iniciativa de reenviar M a y. Este esquema
garante que, se y falhar, toda mensagem M para a qual j tenha enviado a confirmao de
recebimento estar a sua disposio para anlise quando retornar a operao normal, ou
mesmo durante o processo de recuperao, s desaparecendo quando y a l e descarta. Na
realidade, assim procedendo, estamos evitando incorporar ao protocolo bifsico os
mecanismos de contagem de tempo (relgios e "timeouts" associados), necessrios para
garantir os efeitos estipulados. Estamos relegando esta tarefa ao protocolo de comunicao,
visto que este j implementa estes mecanismos como parte de sua operao normal, pois
deles necessita para viabilizar outras tarefas de sua responsabilidade.
No que tange ao cenrio original, os processos de iniciao e migrao de transaes,
descritos nas sees anteriores, garantem os seguintes fatos quando do instante em que o
protocolo bifsico inicia sua execuo:
um registro foi salvo indicando a inteno de iniciar a execuo do protocolo bifsico;
o coordenador salvou a lista de ns participantes, associada identificao da transao;
cada n participante, inclusive o n de origem, registrou os efeitos locais de cada
transao de forma tal que tem capacidade para refazer/desfazer quaisquer destes efeitos,
sempre que julgar necessrio
Outro aspecto da questo diz respeito liberdade delegada a cada n, individualmente, de
cancelar, unilateralmente, qualquer transao. At o momento, este direito poderia ser
exercido a qualquer instante, desde que antes do incio do protocolo bifsico. Ocorre, porm,
que h o perigo de bloqueios globais no sistema. Em tais casos, o mdulo que deteta
bloqueios deve selecionar um certo nmero de transaes que seriam canceladas e
posteriormente automaticamente resubmetidas pelo sistema, nmero este suficiente para
levantar todos os bloqueios existentes naquele instante. Se insistirmos em que transaes no
podem ser canceladas posteriormente ao incio do protocolo bifsico, poderamos,
- 40 -
potencialmente, atingir um cenrio onde teramos bloqueios globais envolvendo apenas
transaes nestas condies. Isto geraria um impasse. Felizmente, a situao pode ser
contornada exigindo-se que transaes no sejam canceladas aps terem registrado a inteno
de entrar na segunda fase do protocolo bifsico. Esta alterao no afeta fundamentalmente
nenhum dos tens discutidos nas sees anteriores, pois no se envolviam com detalhes de
implementao do protocolo bifsico. A razo de passarmos a esta nova condio de
irreversibilidade quanto ao cancelamento unilateral de transaes ficara mais clara no
Captulo 8 que trata do problema de controle de concorrncia. Basicamente, aps passar pela
primeira fase do protocolo bifsico, a transao j requisitou todos os recursos de que
necessitar. Assim, no mais solicitar recursos e, portanto, no poderemos ter bloqueios
constitudos apenas por transaes nestas condies.
Finalmente, importante relembrar que o protocolo deve apresentar robustez contra a
eventualidade de falhas mltiplas. Ou seja, as propriedades bsicas inerentes ao conceito de
transao devem prevalecer mesmo que ns falhem quando esto a se recuperar de falhas
anteriores, no importando quantas vezes esta situao seja cascateada em um mesmo n ou
em mltiplos ns. Est implcita, porm, a hiptese de que, embora qualquer n possa ser
prejudicado por falhas, este n retornar a operao normal em algum ponto no futuro. Do
contrrio, o protocolo poderia entrar em compasso de espera sem fim, o que negaria a
atomicidade da transao, alm de bloquear recursos do sistema eternamente. Note tambm
que o protocolo dever incorporar cdigo para tratamento de falhas e executado pelo
executor de transaes local.
Aps esta discusso preparatria, estamos prontos a iniciar a descrio do protocolo em
datalhe. Faremos uso do campo de estado de retorno que faz parte do descritor de cada
transao, conforme discutido em seo anterior. Para facilitar a leitura do que segue,
relembramos que o campo de descrio das mensagens de trabalho e o campo de veredito das
mensagens de resposta podem conter as seguintes informaes, pertinentes no momento.
O campo de descrio da mensagem de trabalho pode conter:
descrio da rvore de execuo
PREPARE_SE
CONFIRME
CANCELE
O campo de veredito da mensagem de resposta pode conter
EFETUADO
CANCELADO
PREPARADO
IMPOSSIBILITADO
COMPLETADO
- 41 -
O campo de estado de retorno do descritor pode conter
DESCONHECIDO
ATIVO
COLETANDO
CONFIRMANDO
CANCELANDO
PRONTO_SIM
PRONTO_NAO
O protocolo bifsico obtido detalhando-se o esquema bsico apresentado h pouco.
Estamos supondo que qualquer n que ative o protocolo, na qualidade de coordenador, deve
registrar, em lugar seguro e antes de invocar o protocolo, que a transao em questo est
passando do estado de DESCONHECIDO para COLETANDO. Esta mudana tambm
efetivada no campo de estado de retorno do descritor da transao. Na descrio que segue,
optamos por separar as aes de acordo com a natureza de cada n ao invs de agrup-las por
fases. Em cada caso, a atitude de cada n guiada pelo estado de retorno em que se encontra
a transao. Ao entrar em determinado estado de retorno, o sistema executa, em primeiro
lugar, os passos relacionados com a computao local. Em seguida, fica espera de
mensagens. Estas podem chegar de maneira assncrona e em qualquer ordem. Pode ser o
caso, inclusive, de j haver mensagens pendentes aps executarmos os passos relativos
computao local. Em qualquer circunstncia, aps executar a computao local, o sistema
colhe mensagens e, em cada caso, segue os passos correspondentes, segundo previsto no
cdigo do estado de retorno em que se encontra. Tambm foram includos os passos que
devem ser observados se o sistema colhido por uma falha quando j havia invocado o
protocolo em favor de uma certa transao. Neste caso, o controle de integridade, aps
detetar que o protocolo j estava sendo executado, delega ao executor de transaes local a
tarefa de completar sua execuo. Este ltimo verifica o estado de retorno em que se
encontrava a transao imediatamente antes da falha, agindo como se estivesse a mudar,
neste instante, para este mesmo estado de retorno. Isto significa que efetuar a computao
local antes de se voltar para as mensagens que porventura tenham sobrevivido falha. Segue
a especificao do protocolo bifsico.
O COORDENADOR, NO ESTADO DE
1) COLETANDO:
a) efetua computao local:
i) obtm a lista de ns participantes;
ii) envia, a cada n participante, uma mensagem de trabalho onde o campo de
descrio contm PREPARE_SE;
iii) inicia uma tabela com cada um dos ns participantes marcados como
"sem_resposta";
b) processa mensagens de resposta recebidas. Se o campo de veredito for
i) PREPARADO:
(1) marca o n remetente como "com_resposta";
- 42 -
(2) verifica se todo n da tabela j est marcado como "com_resposta". Em caso
afirmativo, registra, em lugar seguro e no campo de estado de retorno do
descritor da transao, que est passando ao estado de CONFIRMANDO;
ii) IMPOSSIBILITADO ou CANCELADO: registra, em lugar seguro e no campo de
estado de retorno do descritor da transao, que est passando ao estado de
CANCELANDO;
2) CONFIRMANDO:
a) efetua computao local:
i) obtm a lista de ns participantes;
ii) envia, a cada n participante, uma mensagem de trabalho onde o campo de
descrio contm CONFIRME;
iii) inicia uma tabela onde aparece cada um dos ns participantes marcados como
"sem_confirmao";
b) processa mensagens de resposta recebidas. Se o campo de veredito for:
i) COMPLETADO:
(1) marca o n remetente como "com_confirmao";
(2) verifica se todo n da tabela j est marcado como "com_confirmao". Em
caso afirmativo, termina o protocolo neste n de origem. A transao sai do
BD.
ii) PREPARADO: envia ao n perticipante uma mensagem de trabalho com campo
de descrio contendo CONFIRME
3) CANCELANDO:
a) efetua computao local:
i) obtm a lista de ns participantes;
ii) envia, a cada n participante, uma mensagem de trabalho onde o campo de
descrio contm CANCELE;
iii) inicia uma tabela onde aparece cada um dos ns participantes marcados como
"sem_confirmao";
b) processa mensagens de resposta recebidas. Se o campo de veredito for
i) COMPLETADO:
(1) marca o n remetente como "com_confirmao";
(2) verifica se todo n da tabela j est marcado como "com_confirmao". Em
caso afirmativo, termina o protocolo neste n de origem. A transao sai do
BD.
ii) PREPARADO ou IMPOSSIBLILITADO: envia ao n participante uma
mensagem de trabalho com campo de descrio contendo CANCELE;
CADA PARTICIPANTE, NO ESTADO DE
1) DESCONHECIDO: ao receber a mensagem de trabalho com campo de descrio
contendo PREPARE_SE, passa ao estado de "ATIVO";
2) ATIVO: efetua computao local:
- 43 -
a) verifica se tem condies locais de confirmar a transao. Isto implica em:
i) resguardar em lugar seguro todos os efeitos locais da transao, garantindo que
podero ser refeitos mais tarde, caso necessrio;
ii) obter todos os recursos do sistema de que vai necessitar para completar a
transao;
iii) verificar se esta transao no foi cancelada localmente;
b) se est em posio de confirmar a transao localmente, registra em lugar seguro e no
campo de estado de retorno do descritor que est a ingressar no estado de
PRONTO_SIM;
c) se no est em posio de confirmar a transao localmente, registra em lugar seguro
e no campo de estado de retorno do descritor que est a ingressar no estado de
PRONTO_NAO;
3) PRONTO_SIM:
a) efetua computao local: envia ao coordenador uma mensagem de resposta com
campo de veredito contendo PREPARADO;
b) processa mensagens de trabalho recebidas. Se o campo de descrio contiver:
i) CONFIRME:
(1) coloca a salvo um registro indicando que a transao foi confirmada;
(2) envia uma mensagem de resposta ao n coordenador cujo campo de veredito
contm COMPLETADO;
(3) termina o protocolo neste n remoto. A transao completou sua execuo
local;
ii) CANCELE:
(1) remove os efeitos locais da transao;
(2) coloca a salvo um registro indicando que a transao foi cancelada;
(3) envia uma mensagem de resposta ao n coordenador cujo campo de veredito
contm COMPLETADO;
(4) termina o protocolo neste n remoto. A transao completou sua execuo
local;
iii) PREPARE_SE: envia ao coordenador uma mensagem de resposta com campo de
veredito contendo PREPARADO;
4) PRONTO_NAO:
a) efetua computao local: envia ao coordenador uma mensagem de resposta com
campo de veredito contendo IMPOSSIBILITADO;
b) processa mensagens de trabalho recebidas. Se o campo de descrio contiver:
i) PREPARE_SE: envia ao coordenador uma mensagem de resposta com campo de
veredito contendo IMPOSSIBILITADO;
ii) CANCELE:
(1) remove os efeitos locais da transao:
(2) coloca a salvo um registro indicando que a transao foi cancelada;
(3) envia uma mensagem de resposta ao n coordenador cujo campo de veredito
- 44 -
contm COMPLETADO;
(4) termina o protocolo neste n remoto. A transao completou sua execuo
local;
5) se a transao no mais consta da tabela de transaes ativas neste n, tabela esta em
poder do executor de transaes: processa as mensagens de trabalho recebidas de acordo
com seu campo de descrio:
a) CONFIRME: envia uma mensagem de trabalho ao coordenador cujo campo de
veredito contm COMPLETADO;
b) CANCELE: envia uma mensagem de trabalho ao coordenador cujo campo de veredito
contm COMPLETADO;
c) CASO CONTRRIO: ignora a mensagem
EM CASO DE FALHA
1) os mecanismos de controle de integridade recuperam o sistema local. Se estes descobrem
que o ltimo registro de estado de retorno referente a uma transao T :
a) DESCONHECIDO: os mecanismos de controle de integridade tomam as medidas
apropriadas em relao a T ;
b) R, diferente de DESCONHECIDO: os mecanismos de controle de integridade
repassam ao executor de transaes a tarefa de concluir a execuo do protocolo
bifsico em favor de T. Aps a volta a normalidade, o executor de transaes
reexecuta as tarefas previstas no estado R como se estivesse entrando neste estado
pela primeira vez.
A descrio acima distingue entre os comportamentos afetos a um n coordenador e a um n
participante. Na realidade, o algortmo executado de forma integrada, pois um mesmo n
pode abrigar tanto transaes a originrias como transaes que para a migraram. A
distino feita a nvel de mensagens. Assim, um n nunca receber uma mensagem de
trabalho identificada com uma transao que tem a seu n de origem e cujo campo de
descrio contm PREPARE_SE. Embora no explicitamente declarado, estamos assumindo
que um n coordenador tambm est sujeito a executar localmente parte das aes referentes
a uma transao. Desta forma, tambm se obrigar a tentar registrar em lugar seguro todos os
efeitos locais desta transao antes de tomar a deciso quanto ao veredito final. Seu voto,
obviamente, tambm deve ser levado em conta no passo 1b do grupo de aes que executa
como coordenador.
Assumindo primeiro um cenrio onde falhas no ocorressem, apenas os grupos do protocolo
referentes a um n coordenador e a um n participante seriam ativados. Neste caso o
coordenador nada mais faz que consultar cada participante quanto as suas condies locais
com vistas a confirmar a transao. Este comportamento est descrito no passo 1 da parte que
cabe ao coordenador no algortmo acima. Cada n participante remete ao coordenador seu
voto de acordo com suas condies locais. So os passos 3a e 4a da parte que diz respeito a
cada n participante. Se todos votam a favor, o coordenador decide pala confirmao e
comunica este fato a cada participante. Se algum votou contra, o coordenador ser forado a
decidir pelo cancelamento, o que comunicado em seguida a todos os outros ns envolvidos.
o passo 3 do cdigo relativo ao coordenador. Finalmente, cada n participante age de
acordo com o veredito recebido do coordenador, segundo os passos 3 e 4 do grupo de aes
- 45 -
que cabe a cada participante. Em qualquer caso, uma mensagem de resposta, com campo de
veredito contendo COMPLETADO, encaminhada por cada n participante ao coordenador.
Aps certificar-se de que todos os ns participantes liqidaram a transao, o n coordenador
faz o mesmo. Neste cenrio simplificado onde no h falhas, o protocolo poderia ser
otimizado dispensando-se o registro de cada estado em lugares de onde pudessem ser
recuperados em caso de falha. No entanto, a consulta a cada n ainda necessria, mesmo na
ausncia de falhas. Para compreender isto, suponha que a transao migrou sem problemas. O
executor de transaes no local de origem inicia a execuo do protocolo bifsico enviando
PREPARE_SE a cada participante. Em paralelo com o envio das mensagens, porm antes
que uma delas chegue a determinado n remoto, a transao cancelada neste n remoto.
Lembre que o sistema pode forar isto a ocorrer para evitar bloqueios. Nesta situao, no
teramos outra alternativa que cancelar a transao em todos os demais ns onde executou. A
consulta iniciada pelo coordenador , portanto, necessria. exatamente no instante quando
entra no estado de PRONTO_SIM ou PRONTO_NAO que no mais permitido a um n
cancelar, unilateralmente, a correspondente transao. Focalizando sobre outro ngulo, pode-
se dizer que a consulta efetivada pelo coordenador funciona como um "sinal" que percorre
todos os ns remotos a alert-los que o perodo de cancelamentos individuais est encerrado,
pelo menos no que tange presente transao.
Passando a admitir falhas, vamos encarar o que ocorre quando um n participante
acometido por um destes eventos. Dependendo de quo adiantado esteja a execuo do
protocolo neste n, podemos ter vrios cursos de ao.
Tome, em primeiro lugar, o caso no qual o n remoto, ao retornar, no se depare com
qualquer registro de que o protocolo bifsico j foi iniciado em benefcio desta transao. Isto
possvel se o n remoto falha antes que tenha chegado a mensagem de trabalho com campo
de descrio PREPARE_SE que lhe endereada pelo coordenador. Imediatamente, o n
remoto envia ao n de origem da transao uma mensagem de resposta com campo de
veredito contendo CANCELADO. Isto era o previsto quando discutimos a migrao de
transaes na presena de falhas. Note que, no que concerne ao sistema local, esta transao
ainda no foi envolvida pelo protocolo bifsico, visto que seu estado de retorno ainda
DESCONHECIDO. De acordo com o passo 1b do protocolo especificado acima, o
coordenador passa ao estado de CANCELANDO e, em seguida, distribui mensagens a todos
os participantes desta transao para que removam seus efeitos locais. O campo de descrio
destas mensagens contm CANCELE. Lembre-se que estamos supondo que os protocolos de
comunicao so robustos com relao a falhas. As confirmaes (ou "acks") necessrios s
so enviados quando as correspondentes mensagens foram "lidas", isto , resguardadas de
falhas. Por conseguinte, podemos tomar como garantido que a mensagem de PREPARE_SE
eventualmente ser analisada pelo n remoto. Mais ainda, a mensagem de CANCELE
tambm j pode ter chegado quando este n remoto comear a processar suas mensagens
aps se recuperar da falha. Ou ento, antes de enviar a mensagem de CANCELE, o
coordenador j falhou e se recuperou vrias vezes. Neste ltimo caso, vrias mensagens de
PREPARE_SE podem estar acumuladas junto ao n remoto. De modo similar, o coordenador
pode ter falhado vrias vezes aps ter entrado no estado de CANCELANDO, esta ltima
mudana de estado tendo sido provocada pela primeira mensagem de CANCELADO que
recebeu do n remoto. Se isto ocorrer, poderemos ter, adicionalmente, vrias mensagens de
CANCELE junto com as mensagens de PREPARE_SE esperando para serem processadas
pelo n remoto.
O que ocorre aps este n remoto voltar operao normal depende da ordem com que estas
mensagens so analisadas. O resultado final, porm, ser sempre o mesmo: o cancelamento
- 46 -
da transao neste n remoto. Se a mensagem com campo de descrio PREPARE_SE
analisada primeiro, o n passa ao estado de ATIVO. Lembre-se que o controle de integridade
no modifica o estado de retorno da transao e, antes da falha, este continha
DESCONHECIDO. O passo 1 do protocolo bifsico, portanto, dita que devemos efetuar a
troca de estados conforme indicado. No estado de ATIVO, descobrimos imediatamente que a
transao foi cancelada localmente. Isto fora a passagem ao estado de retorno de
PRONTO_NAO. Neste estado, uma mensagem de IMPOSSIBILITADO enviada ao
coordenador. Se, neste ponto, o n remoto processa algumas das mensagens de
PREPARE_SE, caso haja tais mensagens pendentes, reenviar ao coordenador mltiplas
cpias da mensagem de IMPOSSIBILITADO. Em algum ponto, porm, uma das mensagens
de CANCELE, ainda pendentes, ser processada. Isto dar ao n remoto uma chance de
cancelar localmente a transao, enviando ao coordenador uma mensagem de
COMPLETADO. A partir deste ponto, as demais mensagens de PREPARE_SE, se houver,
sero ignoradas enquanto que as mensagens de CANCELE daro origem a novas mensagens
de COMPLETADO que so encaminhadas ao coordenador. Lembre-se que, aps enviar a
mensagem de COMPLETADO, o protocolo bifsico terminado. O passo 5, portanto, dita o
comportamento acima, pois esta transao j foi liqidada neste n remoto. Deste ponto em
diante, o comportamento do n remoto ser sempre ditado, no que se refere a esta transao,
pelo passo 5 do grupo de aes que diz respeito a um n participante. O efeito desejado, qual
seja, o cancelamento local da transao, j foi conseguido pelo n remoto. Resta um
problema no que tange ao n remoto. Este pode falhar antes de conseguir completar o passo
4, aps ter lido todas as mensagens de CANCELE de que dispunha originalmente. Entretanto,
cada vez que se registrar um insucesso na execuo das operaes previstas no passo 4, este
ser repetido quando da recuperao do sistema local. Note que, se o n remoto falhar
durante a execuo do passo 4, quando o sistema local se recuperar dever gerar ainda outra
mensagem de IMPOSSIBILITADO, a qual o coordenador, no estado de CANCELANDO,
responder com outra mensagem de CANCELE, dando nova oportunidade ao n remoto de
cancelar a transao localmente. Esta troca de mensagens perdura at que o n remoto
despache sua mensagem de COMPLETADO.
A outra possibilidade seria o n remoto, de incio, processar a mensagem de CANCELE antes
da mensagem de PREPARE_SE. Como o estado de retorno DESCONHECIDO, esta
mensagem ignorada. Esta situao perdura at que a primeira mensagem de PREPARE_SE,
dentre aquelas ainda pendentes, analisada pelo n remoto. Deste ponto em diante, o ciclo
descrito no pargrafo anterior repetido resultando, de novo, no cancelamento local da
transao. Em qualquer circunstncia, a transao cancelada neste n remoto, o que est em
consonncia com o fato de que este n falhou quando operava em favor da transao.
Lembre-se que esta falha poder ter acarretado perdas crticas com relao a esta transao e,
por conseguinte, o seu cancelamento global a nica alternativa.
Suponha agora que o n participante, aps falhar, encontre um registro indicando o estado de
retorno como ATIVO. Segundo o passo 2 do mecanismo de proteo contra falhas, deve
verificar se os efeitos locais da transao sobreviveram intatos e, mais ainda, se tem
condies de requisitar todos os recursos locais porventura necessrios para levar a cabo a
execuo da transao. Quando houver conseguido, e dependendo do caso, o n remoto muda
o estado de retorno para PRONTO_SIM ou PRONTO_NAO conforme o caso, resguardando
tal mudana em local seguro. Note que o n remoto pode falhar vrias vezes antes de
conseguir este intento. Seu estado de retorno, porm, ser sempre recuperado como ATIVO,
forando a repetio destes passos. Uma vez que tenha conseguido passar ao estado de
PRONTO_SIM ou PRONTO_NAO, o n remoto envia, em seguida, mensagens de resposta
ao coordenador com campo de veredito contendo PREPARADO ou IMPOSSIBILITADO,
- 47 -
respectivamente. Falhas repetidas quando nestes estados causam o reenvio da mesma
mensagem ao n coordenador. Este ltimo est em compasso de espera aguardando tais
mensagens, no passo 1 da rotina correspondente aos ns coordenadores. Conclumos que o n
coordenador no deve apenas contar as mensagens de resposta que chegam e cujos campos
de veredito contenham PREPARADO ou IMPOSSIBILITADO. Assim fazendo, ficaria
exposto situao onde um n remoto remete mltiplas mensagens com campo de veredito
PREPARADO enquanto que um outro n remoto, por raz&ot.es de grande carga local,
responde com atraso enviando uma mensagem de resposta com campo de veredito
IMPOSSIBILITADO. Neste caso, o coordenador poderia ser enganado decidindo-se por
confirmar a transao visto que poderia inteirar nmero suficiente de mensagens com campo
de veredito PREPARADO antes que o n sobrecarregado enviasse sua mensagem decisiva.
necessrio que o coordenador identifique que ns remotos j enviaram suas respostas,
ignorando mensagens duplicadas. De forma anloga, possvel que o coordenador tambm
despache vrias cpias de mensagens indicando PREPARE_SE a um mesmo n remoto se
vier a falhar, talvez vrias vezes, quando est no estado de COLETANDO espera das
mensagens de resposta de todos os ns participantes. Sempre que o coordenador envia
mltiplas mensagens de PREPARE_SE a um n remoto, a partir da segunda cpia que
analise o n remoto s poder estar no estado de PRONTO_SIM ou PRONTO_NAO. Isto
porque a primeira verso j forou este n a passar do estado de DESCONHECIDO para o
estado de ATIVO e da para um destes ltimos estados. Em qualquer caso, necessrio que o
n remoto retransmita a correspondente mensagem de PREPARADO ou
IMPOSSIBILITADO, pois a falha no coordenador p&ot.e a perder a relao dos ns
participantes que j haviam sido marcados como "com_resposta". preciso que o
coordenador recomece todo o processo de remarcar. O reenvio de tais mensagens, porm,
previsto nos passos 2 e 3 do grupo de aes correspondentes a um n participante.
Ao concluir esta seo, gostaramos de comentar o que se passa quando o coordenador falha
durante a execuo do protocolo bifsico. A leitura das instrues pertinentes a um n
coordenador no algortmo acima deixam claro que o racional bastante semelhante quele
empregado para ns participantes, e que acabamos de discutir. Se falhar quando o estado de
retorno registrado COLETANDO, o n coordenador forar que novas mensagens de
trabalho, com campo de descrio contendo PREPARE_SE, sejam repetidamente enviadas
aos participantes. Esta multiplicidade de mensagens, entretanto, no prejudicial, conforme
j vimos. Em algum ponto, o coordenador consegue despachar uma mensagem a cada
participante e acumula as respostas correspondentes, forando uma mudana para o estado de
CONFIRMANDO ou CANCELANDO, conforme os votos que tenha recebido. Uma vez
atingidos estes estados, a transao j tem seu destino selado. O coordenador envia
mensagens de trabalho a cada participante com campo de descrio contendo CONFIRME ou
CANCELE, conforme apropriado. Em seguida, fica espera das mensagens de resposta dos
ns participantes indicando que j liqidaram a transao localmente. Esperar por
confirmaes dos participantes importante pois estes podem falhar antes de liqidarem a
transao localmente. Nesta situao, reverteriam aos estado de PRONTO_SIM ou
PRONTO_NAO. No primeiro caso, pelo menos, ficariam sem saber o que fazer, visto que
podem tanto ser chamados a confirmar ou a cancelar a transao. Uma vez completadas todas
as confirmaes, o coordenador pode liqidar a transao no local de origem. Falhas
repetidas do coordenador, quando no estado de CONFIRMANDO causaro a repetio do
envio de mensagens CONFIRME a todos os participantes. Reforamos, novamente, que as
hipteses a respeito dos protocolos de comunicao de dados garantem que as mensagens de
CONFIRME ou CANCELE no s chegaro a seus destinatrios como estes tero a chance
de agir de acordo com o caso, isto , eventualmente as mensagens sero "lidas" por estes ns
- 48 -
remotos. Agora nos deparamos com uma situao semelhante quela quando o coordenador
estava no estado de COLETANDO, isto , pode vir a falhar antes que tenha obtido
mensagens de COMPLETADO de todos os participantes. Se isto ocorrer, aps a falha o
coordenador dever repetir o passo 2, reenviando mensagens de CONFIRME a todos os ns
participantes. Observe que, se o n remoto j liqidou a transao localmente, ento dever
responder ao coordenador com uma mensagem de resposta contendo COMPLETADO em
seu campo de veredito, conforme previsto no passo 5. Se o n remoto ainda no liqidou a
transao, ento poder tentar novamente ao receber a mensagem de CONFIRME vinda do
coordenador, para, em seguida, enviar a mensagem de COMPLETADO ao coordenador. Este
ciclo pode ser repetido quantas vezes for necessrio at que o coordenador consiga obter
confirmaes de todos os participantes e, ento, liqidar a transao localmente. O mesmo
pode ser dito com respeito a falhas repetidas quando no estado de CANCELANDO. Repare,
portanto, que toda mensagem que chegue a um n qualquer e referindo-se a uma transao
que j foi liqidada localmente, ser simplesmente ignorada, exceto quando se tratrar de uma
mensagem de trabalho com campo de descrio contendo CONFIRME ou CANCELE
endereada a um n participante. Neste caso, este ltimo deve enviar uma mensagem de
resposta ao n remetente em cujo campo de veredito deve constar COMPLETADO. Este
esquema evita que entremos numa situao onde teramos confirmaes, confirmaes de
confirmaes, etc., num ciclo sem fim.
Existem outras variaes que implemetam este mesmo estratagema bsico, por vezes
chamado de protocolo bifsico centralizado, que acabamos de apresentar. Referncias neste
sentido sero includas nas notas bibliogrficas ao fim deste captulo. Melhorias,
principalmente no que se refere liberao de determinados recursos bloqueados por
transaes, podem ser introduzidas no esquema que acabamos de discutir. Em vez de
mencion-las agora, porm, ser mais instrutivo esperarmos o momento oportuno quando os
mecanismos de controle de concorrncia estiverem em pauta. O leitor est convidado a tentar
incluir algumas destas otimizaes no esquema bsico do protocolo bifsico apresentado
acima. Caso o protocolo de comunicao de dados no apresente as caractersticas que
assumimos, mormente no que diz respeito ao envio de confirmaes ("acks") somente aps a
mensagem recebida estar a salvo, mecanismos apropriados teriam que ser enxertados na
descrio do protocolo bifsico apresentada acima. Estes enxertos preencheriam aquelas
funes vitais que no so implementadas a contento pelo protocolo de comunicao.
NOTAS BIBLIOGRFICAS
Draffan e Poole [1980] formam uma boa coletnea de artigos. Procuram cobrir todos os
aspectos relativos a banco de dados distribudos, desde a fase de projeto lgico at os
mecanismos mais internos de controle de integridade. Lindsay [1980] contm uma descrio
mais ou menos detalhada das fases de incio, migrao e trmino de transaes,
especialmente desta ltima. O modelo de migrao um tanto geral e mais voltado a
processos distribudos, o que causa alguma diferena com aquele discutido no texto. A parte
de trmino de transaes bem descrita. Tambm inclui uma boa descrio do mecanismo
controle de integridade envolvendo atas e balizadores. Gray [1978] descreve algumas das
estratgias usadas na implementao do Sistema R, desenvolvido no laboratrio de pesquisas
da IBM, em San Jose, California. Discute com algum detalhe o mecanismo de atas, bem
como o protocolo bifsico. Lindsay et all. [1979] proporciona uma descrio detalhada do
protocolo bifsico. Uma anlise de vrios mtodos usados para terminar transaes aparece
em Cooper [1982]. Outros protocolos de trmino de transaes so propostos em Skeen
[1981] e Skeen [1982]. Alguns dentre estes relaxam a condio de que devemos manter o
bloqueio de todos os recursos requisitados pela transao, s liberando-os aps esta ter
- 49 -
completado. Em contrapartida, introduzem outros problemas peculiares. J Mohan, Strong e
Finkelstein [1983] descrevem tentativas recentes de se introduzir protocolos mais robustos,
por outro lado menos eficientes, para se implementar certos aspectos crticos do trmino de
transaes. So os chamados "algortmos Bizantinos". Hammer e Shipman [1979] descrevem
um ambiente distribudo alternativo em relao quele que adotamos e aborda os problemas
de migrao e trmino de transaes neste novo cenrio. Um modelo de transaes e falhas
aparece em Lampson e Sturgis [1976]. Rosenkrantz, Stearns e Lewis [1978] discutem
modelos formais envolvendo controle de concorrncia. No que tange a estruturas de dados
em geral e rvores em particular, Knuth [1968] e tambm Horowitz e Sahni [1976] so
execelentes referncias. Tanembaum [1981] contm uma descrio bem estruturada de
protocolos usados em redes de comunicao de dados, bem como da arquitetura destas redes.
O texto de Menasc e Schwabe [1894], em portugus e mais recente, cobre estes mesmos
tpicos.
- 1 -
CAPTULO 8. CONTROLE DE CONCORRNCIA
Este captulo discute em detalhe o problema de controle de concorrncia em bancos de dados
distribudos. Inicialmente, para motivar a discusso, so listados vrios problemas que
poderiam ocorrer se no houvesse qualquer controle de concorrncia. Estes problemas so
chamados de anomalias de sincronizao. Em seguida, um modelo abstrato de transaes, j
incorporando mecanismos de controle de integridade, introduzido. O critrio fundamental
de correo para algortmos de controle de concorrncia, serializao, o prximo assunto. O
corpo principal do captulo apresenta vrios algortmos para controle de concorrncia,
grupados em dois mtodos principais, bloqueio e pr-ordenao. A apresentao de cada
mtodo acompanhada de uma discusso sobre problemas adicionais, ocasionados pelo
mtodo, que possam impedir o trmino normal das transaes. A discusso acerca do uso de
bloqueios para bancos de dados centralizados apresentada em separado do caso distribudo,
enquanto que o uso de pr-ordenao cobre apenas o caso distribudo.
8.1 INTRODUO
Esta seo apresenta exemplos de anomalias de sincronizao, e introduz os critrios bsicos
de correo para controle de concorrncia e a notao a ser usada no captulo. O modelo de
processamento de transaes adotado nos ltimos captulos tambm aqui revisto.
8.1.1 Anomalias de Sincronizao
Todo mtodo de controle de concorrncia deve evitar certos problemas, chamados de
anomalias de sincronizao, que podem resultar do acesso concorrente irrestrito aos dados.
As principais anomalias so:
perda da consistncia do banco
acesso a dados inconsistentes
perda de atualizaes
Estas anomalias sero ilustradas atravs de exemplos informais que utilizam um banco de
dados centralizado (embora o fato de ser centralizado ou distribudo seja irrelevante para esta
discusso). Os esquemas de relao do banco so os seguintes:
CURSOS[CODIGO,NOME,NMATR] representa os cursos oferecidos em um semestre, onde
NMATR indica o nmero de alunos matriculados em cada particular curso;
TURMAS[MATRICULA,CODIGO] indica que alunos (representados pelo nmero de
MATRICULA) esto matriculados em que cursos (representados pelo CODIGO).
H trs critrios de consistncia para este banco de dados:
C1. o CODIGO de cada curso unico.
C2. todo CODIGO usado em TURMAS deve estar listado em CURSOS
C3. para cada curso c, NMATR contm o total de alunos matriculados em c, conforme
indicado em TURMAS.
- 2 -
Considere agora trs transaes sobre este banco, definidas da seguinte forma:
MATRICULE(m,c ):
COMECO-DE-TRANSACAO
M1. LEIA a tupla t de CURSOS c om CODIGO=c;
if t realmente existir
then begin
M2. ESCREVA a tupla (m,c) em TURMAS;
incremente de 1 o campo NMATR de t;
M3. REESCREVA a tupla t EM CURSOS;
end.
FIM-DE-TRANSACAO
CANCELE(c ):
INICIO-DE-TRANSACAO
C1. REMOVA a tupla de CURSOS com CODIGO=c;
C2. REMOVA todas as tuplas de TURMAS c om CODIGO=c ;
FIM-DE-TRANSACAO
LISTE(m)
COMECO-DE-TRANSACAO
L1. LEIA todas as tuplas de TURMAS com MATRICULA=m;
liste as tuplas lidas;
L2. LEIA todas as tuplas de CURSOS tais que o CODIGO foi lido no comando anterior;
liste todas as tuplas lidas;
FIM-DE-TRANSACAO
importante observar que cada uma destas transaes preserva a consistncia do banco. De
fato, a transao MATRICULE(m,c ) primeiro verifica a existncia do curso c antes de
efetivamente matricular m em c. Da mesma forma, a transao CANCELE(c ) retira o curso c
de CURSOS e todos os alunos matriculados neste curso de TURMAS. No entanto, se estas
transaes forem executadas concorrentemente, sem nenhum controle, anomalias de
sincronizao podero ocorrer.
Por simplicidade, nos exemplos que se seguem, execues concorrentes sero representadas
por seqncias de rtulos correspondendo a comandos que acessam o banco de dados (os
rtulos so aqueles dados aos comandos na definio das transaes). Comandos que no
acessam o banco de dados no influenciam a discusso, sendo, portanto, ignorados. Os
valores dos parmetros das transaes so indicados fora da prpria seqncia de rtulos.
Caso haja mais de uma execuo da mesma transao, cada uma das execues e os rtulos
correspondentes sero distinguidos por subscritos.
- 3 -
Assim a seqncia
M1
1
M2
1
M3
1
L1 L2 C1 C2 M1
2
M2
2
M3
2
indica uma execuo seqencial das transaes MATRICULE
1
(m,c ), LISTE(m), CANCELE(c ) e
MATRICULE
2
(m,c), nesta ordem.
Suponha que o curso INF2045 exista e que o estado inicial do banco de dados seja consistente.
Considere uma execuo concorrente de MATRICULE(82.3827,INF2045) e CANCELE(INF2045),
representada pela seguinte seqncia de comandos:
M1 C1 C2 M2 M3
Esta seqncia viola o segundo critrio de consistncia do banco. De fato, embora M1
corretamente determine que o curso INF2045 existe no estado inicial e, portanto, o aluno cuja
matricula 82.3827 pode nele se matricular, o comando C1 executado imediatamente em
seguida remove este curso. Logo, no estado final do banco de dados, a relao associada a
TURMAS conter a tupla (82.3827,INF2045), sem que haja nenhuma tupla na relao associada a
CURSOS com CODIGO=INF2045. Isto constitui uma violao do segundo critrio de
consistncia. Alm disto, embora no produza erro propriamente, o comando M3 fica sem
ao pois o curso INF2045 no mais existe quando M3 executado.
Este , ento, um exemplo de uma execuo concorrente de transaes que leva a perda de
consistncia do banco, embora cada transao por si s preserve consistncia.
Como um outro exemplo de anomalias de sincronizao, suponha que o aluno 82.5694 est
inicialmente matriculado no curso INF2045. Considere uma execuo concorrente de
LISTE(82.5694) e CANCELE(INF2045) representada pela seguinte seqncia:
L1 C1 C2 L2
Neste caso, o resultado apresentado por LISTE inconsistente pois indica que o aluno 82.5694
est matriculado no curso INF2045, como resultado de L1, mas este curso no listado por L2,
pois foi cancelado por C1. Ou seja, o resultado apresentado por LISTE no satisfaz ao segundo
critrio de consistncia do banco. Temos aqui uma situao de acesso a dados inconsistentes
por parte da transao LISTE.
Para concluir esta seqncia de exemplos, suponha novamente que o curso INF2045 exista
inicialmente. Considere uma execuo concorrente de MATRICULE
1
(82.5782,INF2045) e
MATRICULE
2
(82.4920,INF2045) representada pela seguinte seqncia:
M1
1
M1
2
M2
2
M3
2
M2
1
M3
1
Esta execuo leva a uma perda de atualizao pois o valor final de NMATR para o curso
INF2045 reflete apenas a matrcula de 82.5782, e no a dos dois alunos. Isto se deve ao fato de
M3 incrementar e reescrever o valor lido por M1, e no o valor corrente de NMATR. Isto ,
M1
1
e M1
2
lem ambas o valor inicial de NMATR para o curso INF2045; M3
1
e M3
2
ambas
incrementam este valor; mas M3
1
escreve sobre o valor criado por M3
2
, em lugar de
increment-lo.
(O leitor deve se convencer de que o ltimo exemplo tambm leva perda de consistncia do
banco).
Isto completa a nossa discusso sobre anomalias de sincronizao. A Seo 8.1.2 introduzir
- 4 -
uma classe de execues concorrentes, chamadas de serializveis, onde estes problemas no
ocorrem.
8.1.2 Modelagem do Sistema
O estudo de controle de concorrncia ser feito assumindo-se o mesmo modelo de SGBD
distribudo e de transaes usado nos captulos anteriores. Esta seo recorda os aspectos do
modelo relevantes para a discusso sobre controle de concorrncia.
A nvel lgico, o banco de dados descrito por um esquema conceitual global consistindo de
um conjunto de objetos lgicos. A nvel fsico, o banco descrito por uma srie de esquemas
internos, um para cada n onde est armazenado; cada esquema interno consiste de um
conjunto de objetos fsicos. Os mapeamentos do esquema conceitual global para os esquemas
internos definem a forma de distribuio do banco e a correspondncia entre objetos fsicos e
objetos lgicos. Estes mapeamentos podero determinar que certos conjuntos de objetos
fsicos armazenem cpias dos mesmos dados. Os objetos lgicos so manipulados atravs de
comandos da LMD e os objetos fsicos atravs de aes elementares.
A execuo de uma transao controlada pelo gerente de transaes (GT) do n onde foi
submetida. A nvel lgico, a execuo de uma transao processa-se da seguinte forma:
COMEO-DE-TRANSAO: o GT ao interceptar este comando cria uma rea de trabalho para
a transao;
comandos da LMD: consultas puras acessam objetos lgicos do banco de dados trazendo-os
para a rea de trabalho, se j l no estiverem. Atualizaes sobre os objetos lgicos
so mantidas na prpria rea de trabalho, no se tornando visveis de imediato a
outras transaes;
FIM-DE-TRANSAO: invoca o protocolo bifsico para modificar todas as cpias de todos os
objetos lgicos afetados por atualizaes executadas pela transao. Os valores dos
objetos lgicos so obtidos da rea de trabalho.
Suporemos que em cada n participando do processamento da transao h uma rea de
trabalho da transao.
Todas as operaes a nvel lgico so sempre traduzidas em seqncias de operaes a nvel
fsico. Mais precisamente, uma execuo de um grupo de transaes gera, em cada n onde o
banco est armazenado, uma seqncia de aes elementares, que suporemos serem de dois
tipos:
R(X) ao de leitura que recupera os valores dos objetos fsicos cujo nome est no conjunto
X para a rea de trabalho local da transao que gerou a ao;
W(X) ao de atualizao que escreve os novos valores dos objetos fsicos em X no banco
de dados local.
Assim, a execuo de um comando da LMD (que uma operao a nvel lgico) poder
gerar vrias aes do tipo R(X) para recuperar objetos fsicos que ainda no esto na rea de
trabalho da transao. Porm, um comando da LMD nunca gerar aes elementares do tipo
W(X) pois o banco de dados no alterado de imediato. Apenas quando o protocolo bifsico
atingir a segunda fase, aes elementares do tipo W(X) sero geradas para efetivar alteraes
nos bancos de dados locais.
- 5 -
H duas suposies importantes para controle de concorrncia a se ressaltar aqui:
1. controle de concorrncia ser feito a nvel dos objetos fsicos. Portanto, um mecanismo
de controle de concorrncia dever disciplinar a intercalao das aes elementares de
diferentes transaes em cada n.
2. A semntica das transaes no ser levada em conta pelos mecanismos de controle de
concorrncia.
Como conseqncia, o controle de concorrncia dever depender apenas das seqncias de
operaes de leitura/atualizao sobre os objetos fsicos armazenados nos vrios bancos de
dados locais, ou seja, das seqncias de operaes R(X) e W(X) executadas contra os bancos
de dados locais. Uma execuo concorrente E de um conjunto T de transaes pode, ento,
ser abstrada por um conjunto L= { L
1
,..., L
n
}, onde L
i
a seqncia de aes elementares
R(X) ou W(X) executadas contra o banco de dados do n i que foram geradas em E. O
conjunto L chamado de um escalonamento global para T e a seqncia L
i
chamada do
escalonamento local ao n i para T. Usaremos R
i
(X) ou W
i
(X) para indicar aes elementares
R(X) ou W(X) executadas a favor da transao T
i
em um escalonamento local.
Freqentemente escreveremos R
i
(x
1
,..., x
k
) em lugar de R
i
( { x
1
,..., x
k
} ), e
semelhantemente para aes de atualizao.
Como exemplos destes conceitos, considere um banco de dados distribudo armazenado em
dois ns. Os esquemas internos so modelados por dois conjuntos de objetos fsicos, D
1
= {
x
1
,y
1
} e D
2
= { x
2
}, onde x
1
e x
2
armazenam cpias dos mesmos dados.
Um escalonamento global para duas transaes T
1
e T
2
neste contexto poderia ser
L = { L
1
, L
2
}, onde
L
1
= R
1
(y
1
) R
2
(x
1
) W
2
(x
1
) W
1
(x
1
)
L
2
= R
1
(x
2
) W
1
(x
2
) W
2
(x
2
)
Ou seja, L
1
representa a seguinte seqncia de aes elementares executadas no primeiro n:
T
1
l o objeto fsico y
1
T
2
l o objeto fsico x
1
T
2
escreve no objeto fsico x
1
T
1
escreve no objeto fsico x
1
Para o segundo n, L
2
representa a seguinte seqncia:
T
1
l o objeto fsico x
2
T
1
escreve no objeto fsico x
2
T
1
escreve no objeto fsico x
1
Tanto a teoria de correo quanto o estudo do comportamento dos mtodos de controle de
concorrncia sero baseados em propriedades de escalonamentos globais.
- 6 -
8.1.3 Critrios de Correo
Esta seo define os critrios de correo que guiaro a discusso sobre controle de
concorrncia. Sero considerados critrios pertencentes a trs classes distintas: critrios para
transaes, critrios genricos para o sistema e critrios especficos para os mtodos de
controle de concorrncia.
Os critrios para transaes so simples:
T1. Cada transao, quando executada sozinha, sempre termina;
T2. Cada transao, quando executada sozinha, preserva consistncia do banco de dados;
Estas suposies afirmam apenas que o usurio especificou corretamente cada transao.
Os critrios genricos do sistema por sua vez sero os seguintes:
G1. O sistema deve funcionar corretamente para qualquer conjunto de transaes
acessando qualquer banco de dados;
G2. A resposta do sistema deve ser independente do significado das transaes e dos
valores dos prprios dados armazenados.
A primeira suposio justifica-se com base no fato de estarmos interessados em construir
SGBDDs de uso genrico, e no em sistemas distribudos para aplicaes especficas. Logo,
no razovel supor que as transaes so conhecidas "a priori", ou que o sistema seja
dependente de um particular conjunto de transaes acessando um particular banco de dados.
J a segunda suposio sugere que os mtodos de controle de concorrncia devam trabalhar
apenas com base nos nomes dos objetos fsicos lidos e atualizados, conforme comentado no
final da seo anterior.
Esta discusso nos coloca em posio de definir intuitivamente os critrios de correo
impostos aos mtodos de controle de concorrncia:
C1. Cada transao submetida ao sistema deve eventualmente terminar.
C2. Cada transao deve ser executada atomicamente, sem interferncia das outras
transaes;
O primeiro critrio claro e resume a idia de que o mtodo de controle de concorrncia
dever prover meios para resolver problemas, como bloqueios mtuos, que possam impedir o
trmino normal das transaes. J o segundo critrio, o mais importante de todos, requer uma
discusso pormenorizada para esclarecer o que significa "execuo atmica sem
interferncia". Este ser o assunto da prxima seo.
*8.2 TEORIA DA SERIALIZAO
A teoria da serializao se prope a capturar de forma precisa quando, em uma execuo
concorrente de um grupo de transaes, cada uma delas executada atomicamente sem
interferncia. Execues com esta propriedade so chamadas de serializveis. O objetivo
desta seo ser dar uma definio precisa da noo de execuo serializvel, que essencial
ao entendimento da correo dos mtodos de controle de concorrncia discutidos nas sees
seguintes deste captulo.
- 7 -
Intuitivamente, uma execuo concorrente serializvel se for computacionalmente
equivalente a uma execuo serial das transaes, ou seja, a uma execuo em que as
transaes so processadas seqencialmente, uma aps a outra, em alguma ordem. Para
formular precisamente este conceito intuitivo necessrio definir dois conceitos: o que so
execues seriais e quando duas execues so consideradas computacionalmente
equivalentes.
8.2.1 Execues Seriais
Em termos simples, uma execuo serial se as transaes so executadas seqencialmente.
Ou seja, uma execuo E de T modelada por um escalonamento global L serial se e
somente se
1. para cada escalonamento local de L, para cada par de transaes T
i
e T
j
em T, ou todas as
operaes de T
i
precedem todas as operaes de T
j
, ou vice-versa;
2. para cada par de transaes T
i
e T
j
, se as operaes de T
i
precedem as operaes de T
j
em
um escalonamento local de L, ento o mesmo verdade para todos os outros
escalonamentos locais de L.
Diremos ainda que L um escalonamento serial neste caso.
Como exemplo, considere um banco de dados distribudo armazenado em dois ns cujos
esquemas internos so modelados por dois conjuntos de objetos fsicos, D
1
= { x
1
,y
1
} e
D
2
= { x
2
}. Suponha que x
1
e x
2
armazenem cpias dos mesmos dados. Um escalonamento
serial seria :
S = { S
1
, S
2
}, onde
S
1
= R
1
(y
1
) W
1
(x
1
) R
2
(x
1
) W
2
(x
1
)
S
2
= R
1
(x
2
) W
1
(x
2
) W
2
(x
2
)
Como exemplos de escalonamentos no seriais teramos:
N = { N
1
, N
2
}, onde
N
1
= R
1
(y
1
) R
2
(x
1
) W
2
(x
1
) W
1
(x
1
)
N
2
= R
1
(x
2
) W
1
(x
2
) W
2
(x
2
)
e
N' = { N
1
' , N
2
' }, onde
N
1
' = R
1
(y
1
) R
2
(x
1
) W
2
(x
1
) W
1
(x
1
)
N
2
' = W
2
(x
2
) R
1
(x
2
) W
1
(x
2
)
O primeiro exemplo viola a primeira condio para escalonamentos seriais, enquanto o
segundo exemplo viola a segunda condio.
O mtodo de controle de concorrncia trivial, que s permite execues seriais, obviamente
correto dentro dos critrios estabelecidos anteriormente. No h dvidas de que cada
transao executada atomicamente sem interferncia de outras se este mtodo seguido.
- 8 -
Tambm deve estar claro que em uma execuo serial S anomalias de sincronizao no
ocorrem. Por suposio, cada transao preserva consistncia e termina se executada sozinha.
Logo, se o estado inicial do banco for consistente, o estado do banco aps a execuo da :f/i/-
sima transao em S tambm ser consistente. Assim, se o estado inicial do banco for
consistente, o estado final tambm o ser, o que significa que S preserva consistncia. Pela
mesma razo, nenhuma transao l dados inconsistentes em S pois o faz de um estado
consistente. Finalmente, como cada transao processada aps o trmino da anterior,
obviamente nenhuma atualizao perdida em S.
8.2.2 Equivalncia de Execues
Passemos agora para o problema de definir o que significa duas execues serem
computacionalmente equivalentes. Intuitivamente, duas execues E e E' de um mesmo
conjunto T de transaes so computacionalmente equivalentes se e somente se as seguintes
condies forem satisfeitas, supondo que E e E' comeam no mesmo estado do banco de
dados:
1. E e E' produzem o mesmo estado final do banco de dados;
2. cada transao em T l os mesmos dados em E e E'.
Mais precisamente, seja T um conjunto de transaes e E um execuo de T modelada por um
escalonamento global L. Sejam R(X) e W(Y) duas aes elementares em algum
escalonamento local L
i
de L. Seja x um objeto fsico armazenado em um n i tal que x X
Y. Diremos que R(X) l x de W(Y) em L
i
se W(Y) precede R(X) em L
i
e no h nenhuma
operao W(Z) entre W(Y) e R(X) em L
i
tal que x Z. Seja y X . Diremos que R(X) l o valor
inicial de y em L
i
se R(X) no l y de nenhum W(Y). Similarmente, seja z Y . Diremos que
W(Y) cria o valor final de z em L
i
se W(Y) a ltima operao de atualizao em L
i
tal que z
Y . Estas duas ltimas noes poderiam ser reduzidas primeira se imaginssemos uma
transao inicial que "cria" o estado inicial de E, e uma transao final que "l" o estado final
produzido por E.
Sejam E e E' duas execues para um conjunto T de transaes. Sejam L= { L
1
,..., L
n
} e
L' = { L'
1
,..., L'
n
} escalonamentos globais modelando E e E'. Diremos que E e E' so
equivalentes se e somente, para todo j [1,n]:
1. L
j
e L
j
' contm as mesmas aes elementares, e as aes de cada transao ocorrem na
mesma ordem relativa em ambas.
2. para cada objeto fsico x, para cada R(X) em L
j
tal que x X, R(X) l o valor inicial de x
em L
j
se e somente se o faz em L
j
' ;
3. para cada objeto fsico x, para cada W(Y) em L
j
tal que x Y, W(Y) cria o valor final de x
em L
j
se e somente se o faz em L
j
' ;
4. para cada R(X) em L
j
, para cada W(Y) em L
j
, para cada x X Y , R(X) l x de W(Y) em
L
j
se e somente se o faz em L
j
'.
Diremos ainda que L e L' so escalonamentos equivalentes.
Intuitivamente, esta definio garante que cada transao processada da mesma forma em
ambas as execues pois as operaes de leitura lem os mesmos valores. Alm disto, o
- 9 -
estado final do banco de dados o mesmo, pois o valor final de cada objeto fsico foi
produzido pela mesma operao de atualizao em ambas as execues.
8.2.3 Execues Serializveis
Seja E uma execuo para um conjunto T de transaes modelada por um escalonamento L. E
serializvel se e somente se for equivalente a uma execuo serial. Diremos tambm que L
um escalonamento serializvel.
Portanto, o critrio C2 da Seo 8.1.1.3 pode ser precisamente reformulado como:
C2'. toda execuo de um conjunto de transaes T dever ser serializvel.
Um mtodo de controle de concorrncia dever ento permitir apenas execues serializveis
das transaes. Com isto o mtodo estar garantindo que nenhuma anomalia de sincronizao
aparecer. A justificativa simples: em execues seriais tais anomalias no ocorrem; como
as execues serializveis so computacionalmente equivalentes s execues seriais, elas
herdam, ento, esta propriedade. Se o leitor preferir no analisar a questo em termos de
anomalias de sincronizao, basta argumentar que execues seriais so "naturalmente
corretas" do ponto de vista da execuo das transaes. Portanto, gerando apenas execues
que lhes so equivalentes, a propriedade de correo mantida.
O resto desta seo apresenta uma srie de exemplos envolvendo o conceito de serializao.
Considere inicialmente um banco de dados centralizado cujo esquema interno modelado por
um conjunto de objetos fsicos D = { x , y }. Considere duas transaes, T
1
e T
2
, cujas
execues seqenciais geram, respectivamente, as seqncias de aes elementares:
L
1
= R
1
(X) W
1
(X)
L
2
= R
2
(y) W
2
(X).
H apenas dois possveis escalonamentos seriais neste caso:
S
12
= R
1
(X) W
1
(X) R
2
(y) W
2
(X)
S
21
= R
2
(y) W
2
(X) R
1
(X) W
1
(X).
:exmp. Alm de S
12
e S
21
, que so obviamente serializveis, os seguinte escalonamentos
tambm so serializveis:
E
1
= R
1
(X) R
2
(y) W
1
(X) W
2
(X)
E
2
= R
2
(y) R
1
(X) W
1
(X) W
2
(X).
Ambos so equivalentes a S
12
pois, como R
2
(y) l o valor inicial de y em S
12
, podemos
comutar esta ao com W
1
(x) obtendo E
1
, e depois com R
1
(x), obtendo E
2
. O leitor deve se
convencer que estes so os dois nicos escalonamentos serializveis alm de S
12
e S
21
.
Como um segundo exemplo, considere novamente um banco de dados distribudo
armazenado em dois ns cujos esquemas internos so modelados por dois conjuntos de
objetos fsicos, D
1
= { x
1
, y
1
} e D
2
= { x
2
}. Suponha que x
1
e x
2
armazenam cpias dos
mesmos dados. Um exemplo de um escalonamento serializvel seria
- 10 -
L= {L
1
,L
2
}, onde
L
1
= R
2
(x
1
) R
1
(y
1
) W
2
(x
1
) W
1
(x
1
)
L
2
= W
2
(x
2
) R
1
(x
2
) W
1
(x
2
)
que equivalente ao escalonamente serial em que T
2
executada completamente antes de T
1
ser processada.
Como exemplos de escalonamentos no serializveis teramos
N = {N
1
,N
2
}, onde
N
1
= R
1
(y
1
) R
2
(x
1
) W
1
(x
1
) W
2
(x
1
)
N
2
= R
1
(x
2
) W
1
(x
2
) W
2
(x
2
)
e
N' = {N
1
',N
2
'}, onde
N
1
' = R
2
(x
1
) W
2
(x
1
) R
1
(y
1
) W
1
(x
1
)
N
2
' = W
2
(x
2
) R
1
(x
2
) W
1
(x
2
)
No primeiro exemplo, N no serializvel pois o prprio escalonamento local N
1
j no o
torna equivalente a algum escalonamento serial. No possvel, intuitivamente, trazer R
2
(x
1
)
para junto de W
2
(x
1
) em N
1
sem alterar a computao expressa por N
1
. O segundo exemplo,
N', interessante pois N
1
' e N
2
' so por si s seriais, mas as transaes aparecem na ordem
trocada em cada um. Alm disto, no possvel alterar a ordem das aes sem alterar a
computao final. Este exemplo ilustra o fato de que serializao no pode ser detetada
localmente: mesmo que todos os escalonamentos locais sejam serializveis, o escalonamento
global poder no o ser.
A caracterizao de execues serializveis dada pela definio anterior captura corretamente
o conceito de atomicidade das transaes em um ambiente concorrente, mas ainda no leva a
mtodos de controle de concorrncia. Na verdade possvel provar que apenas testar se um
escalonamento serializvel , provavelmente, computacionalmente intratvel (mais
precisamente, NP-Completo).
8.2.4 Uma Condio Suficiente para Serializao
Nesta seo ser apresentada uma condio suficiente (mas no necessria) para garantir
serializao. Esta condio ser usada nas sees seguintes para provar a correo de
mtodos de controle de concorrncia.
Seja T um conjunto de transaes e L um escalonamento global para T. Seja L
k
um
escalonamento local de L. Duas aes elementares O
i
e O
j
de L
k
conflitam se e somente se
elas agem sobre um mesmo objeto fsico e uma delas uma operao de atualizao.
Operaes conflitantes so importantes pois, se a sua ordem relativa for alterada em L
k
, o
resultado final da execuo poder ser modificado. Considere, por exemplo, as operaes
R(X) e W(X). Suponha que L
k
seja da forma '... R(X) ... W(X) ...'. Logo R(X) obviamente no l
o valor de x X que foi criado por W(X). Se a ordem das operaes for trocada em L
k
para '...
W(X) ... R(X) ...' e entre W(X) e R(X) no houver uma outra operao de atualizao para x
- 11 -
X, R(X) passar agora a ler o valor criado por W(X), possivelmente (mas no
necessariamente) alterando o estado final do banco de dados. Um cenrio semelhante pode
naturalmente ser criado para duas operaes de atualizao. Definiremos ainda que O
i
precede com conflito O
j
em L
k
(denotado por O
i
< O
j
) se e somente se O
i
ocorre antes de O
j
em L
k
e O
i
e O
j
conflitam. Quando mais de uma relao de precedncia por conflito estiver
em jogo, subscritos sero usados para distingu-las.
De posse desta relao entre aes elementares, diremos que T
i
precede por conflito T
j
em L
(denotado por T
i
< T
j
) se e somente se existir um escalonamento local L
k
de L e operaes O
i
e O
j
em L
k
tais que O
i
e O
j
so operaes de T
i
e T
j
respectivamente e O
i
< O
j
. A relao <
ser chamada de relao de precedncia por conflito para T induzida por L. Novamente
quando mais de uma destas relaes estiverem em jogo, subscritos sero usados para
distingu-las.
Podemos, ento, mostrar o seguinte:
TEOREMA 1: Seja T = { T
1
,..., T
m
} um conjunto de transaes e E uma execuo de T
modelada por um escalonamento global L = { L
1
,...,L
n
}. Se a relao de precedncia
por conflito para T induzida por L for uma relao de ordem parcial, ento E
serializvel.
Demostrao
Provaremos que, para todo conjunto T de transaes, para toda execuo E de T modelada
por um escalonamento global L, se a relao de precedncia por conflito para T induzida por
L for uma relao de ordem parcial, ento E serializvel. A prova ser por induo sobre a
cardinalidade de T.
BASE: Suponha que T tenha apenas uma transao. Ento o resultado segue trivialmente.
PASSO DE INDUO: Suponha que o resultado vale para todo conjunto de transaes com
cardinalidade menor do que n. Seja T um conjunto de transaes com cardinalidade n e E
uma execuo de T modelada por um escalonamento global L. Suponha que a relao <
L
sobre T induzida por L seja uma relao de ordem parcial.
Seja T
i
uma transao em T tal que para nenhuma transao T
j
temos que T
j
<
L
T
i
. Construa
uma execuo F de T, modelada por um escalonamento F, onde T
i
inicialmente executada
seqencialmente e depois as outras transaes em T so executadas concorrentemente
exatamente como em E. Assim, cada escalonamento local M
k
de F obtido trazendo-se todas
as aes elementares de T
i
no escanolamento local L
k
de L para a esquerda (e respeitando a
sua ordem relativa). Por construo, a relao <
L
coincide com com a relao <
M
. Alm
disto, como no existe T
j
tal que T
j
<
L
T
i
, no existe uma ao elementar O
j
de alguma
transao T
j
em T, e uma ao elementar O
i
de T
i
em L
k
tais que O
j
<
L
O
i
. Ou seja, nenhuma
ao elementar O
j
que precede alguma ao elementar O
i
de T
i
em L
k
conflita com O
i
Assim,
E' e E so equivalentes.
Construa agora G retirando as aes elementares de T
i
de F. Seja N o escalonamento global
representando G. Teremos ento que G uma execuo do conjunto de transaes U = T - {
T
i
}, que tem cardinalidade menor do que n. Alm disto, a relao <
N
um subconjunto da
relao <
L
pois, por construo, G uma subseqncia de E. Logo, <
N
tambm acclica.
Pela hiptese de induo, podemos ento concluir que G serializvel.
Seja SG uma execuo serial equivalente a G. Construa uma execuo serial SF das
- 12 -
transaes em T processando T
i
primeiro e depois as outras transaes em T na mesma ordem
que em SG. Por construo e pelo fato de SG e G serem equivalentes, SF e F sero ento
equivalentes. Mas E e F eram equivalentes. Logo, SF e E so equivalentes, o que prova que E
serializvel.
Para ver que a condio apresentada no teorema anterior no necessria, considere o
seguinte escalonamento em um banco de dados centralizado:
L = R
1
(x) W
2
(x) W
1
(x) W
3
(x)
Como T
1
< T
2
< T
1
, a relao de precedncia por conflito para as transaes induzida por L
no uma relao de ordem parcial. Mas, por outro lado, L equivalente ao seguinte
escalonamento serial:
S = R
1
(x) W
1
(x) W
2
(x) W
3
(x)
pois os valores de x atualizados por T
1
e T
2
no contribuem nem para a execuo de T
3
, nem
para o estado final do banco de dados j que W
3
(x) escreve sobre eles.
Os mtodos de controle de concorrncia descritos nas sees que se seguem garantiro que a
relao < sempre uma relao de ordem parcial para as transaes em processamento e,
assim, que todas as execues so serializveis.
8.3 MTODOS BASEADOS EM BLOQUEIOS - PARTE I
Esta seo discute o uso de bloqueios para controle de concorrncia em um ambiente
centralizado. Inicialmente os problemas de gerncia de bloqueios e tratamento de bloqueios
mtuos so abordados. Em seguida, um mtodo de uso de bloqueios para atingir apenas
execues serializveis, chamado de bloqueio em duas fases, apresentado. Por fim, a
correo do mtodo provada.
8.3.1 Protocolo de Bloqueio de Objetos
Nesta seo um protocolo de bloqueio/liberao de objetos discutido bem como as questes
de tipos de bloqueio e granularidade dos objetos bloqueados.
Consideremos inicialmente o caso mais simples em que todos os objetos a serem bloqueados
so de uma mesma classe (pginas fsicas, por exemplo). Suponha ainda que s h um modo
de bloqueio, ou seja, que cada objeto s pode estar em dois estados:
bloqueado permite acesso ao objeto apenas pela transao que detm o bloqueio;
livre no permite acesso ao objeto por nenhuma transao.
Neste caso necessrio introduzir apenas duas novas aes elementares ao nosso repertrio
(que contm at o momento apenas R(X) e W(X)):
B(x) bloqueie o objeto cujo nome x;
L(X) libere todos os objetos cujos nomes esto em X;
Note que B(x) afeta apenas um nico objeto, diferentemente das outras aes elementares.
Esta opo torna o tratamento de bloqueios mais simples, conforme veremos.
- 13 -
Para acomodar estas novas aes elementares, uma execuo de um conjunto de transaes
ser representada agora pela seqncia de aes elementares R(X), W(X), B(x) ou L(X)
processadas contra o banco de dados centralizado. Esta seqncia continuar a ser chamada
de um escalonamento.
Estas aes so passadas para o gerente de bloqueios, que mantm uma tabela de bloqueios,
modelada como uma coleo de triplas (x,T,F) onde:
x o nome de um objeto
T o nome da transao que correntemente bloqueia x
F uma fila de espera para x contendo os nomes de todas as transaes que esperam a
liberao de x
Suporemos que as filas de espera seguem a poltica estrita primeiro-a-chegar-primeiro-a-sair.
Esta poltica poderia ser alterada, adotando-se filas com prioridade, por exemplo. Porm,
qualquer poltica adotada dever garantir que uma transao no fica eternamente na fila de
espera.
A noo de um objeto estar bloqueado ou livre implementada atravs de um protocolo de
bloqueio e liberao de objetos definido como ( indica a fila vazia):
1) Inicialmente a tabela de objetos bloqueados est vazia.
2) Ao receber solicitao para bloquear o objeto x para a transao T atravs da ao B(x),
pesquise a tabela de bloqueios procurando uma tripla cujo primeiro elemento seja x:
a) se nenhuma tripla for encontrada (ou seja, se x est livre), bloqueie x para T,
acrescentando a tripla (x,T,) tabela.
b) caso contrrio, acrescente T ao final da fila de espera para x na tripla encontrada.
3) Ao receber solicitao da transao T atravs da ao L(X) para liberar os objetos em X,
para cada x X, pesquise a tabela de bloqueios procurando uma tripla cujos dois
primeiros elementos sejam x, T:
a) se nenhuma tripla for encontrada, ignore a liberao de x.
b) caso contrrio, seja (x,T,F) a tripla encontrada:
i) se a fila F estiver vazia, retire a tripla da tabela, liberando x.
ii) se a fila F no estiver vazia, ou seja, se for da forma T'.F' , passe o controle de x
para T' , substituindo a tripla (x,T,F) na tabela de bloqueios por (x,T',F').
Diz-se que uma execuo (e o escalonamento que a representa) legal se e somente se
obedece ao protocolo de bloqueio/liberao de objetos e uma ao elementar de uma
transao T
i
que acessa um objeto x s processada depois que x for bloqueado para T
i
. De
agora em diante, quando nos referirmos a um escalonamento com bloqueios, estaremos
implicitamente assumindo que legal.
O protocolo bsico de bloqueio/liberao pode ser melhorado incorporando-se modalidades
(ou modos) diferentes de bloqueio. Uma opo seria adotar duas modalidades de bloqueio,
partilhado e exclusivo. Isto significa que agora um objeto poder estar em trs estados:
bloqueado partilhadamente: permite acesso ao objeto por todas as transaes que bloqueiam
o objeto partilhadamente;
- 14 -
bloqueado exclusivamente: permite acesso ao objeto apenas pela transao que o bloqueia
exclusivamente;
livre: no permite acesso ao objeto por nenhuma transao;
Uma forma mais precisa de definir a compatibilidade das modalidades de bloqueio seria
atravs de uma matriz de compatibilidades indicando quando duas transaes podem
bloquear o mesmo dado e quando no o podem fazer:
partilhado exclusivo
partilhado SIM NO
exclusivo NO NO
A justificativa para as modalidades de bloqueio acima definidas simples. Duas ou mais
transaes podero ler o objeto x simultaneamente, sem perigo de conflito, bloqueando-o em
modo partilhado (entrada 'SIM' na matriz de compatibilidades). Por outro lado, se uma
transao atualiza X, conflitar com qualquer outra transao que acesse x. Logo dever
bloquear x em modo exclusivo, no permitindo que nenhuma outra transao bloqueie x em
qualquer modo (entradas 'NO' na matriz de compatibilidades).
Cabe observar que a matriz de compatibilidades se refere a aes de transaes diferentes, e
no se aplica a aes de uma mesma transao. Assim, se uma transao j mantm um
objeto x bloqueado na modalidade partilhada e desejar bloque-lo na modalidade exclusiva,
poder faz-lo se for a nica transao que no momento mantm x bloqueado.
O protocolo de bloqueio/liberao dever ento incorporar a poltica expressa pelas
modalidades de bloqueio. As modificaes, por serem simples, so omitidas neste texto.
Um segundo melhoramento pode ainda ser incorporado ao protocolo de bloqueio/liberao
criando-se uma hierarquia de objetos. Suponhamos que, em lugar de objetos de uma nica
classe, os objetos sejam organizados sob forma de uma floresta. Se um objeto x for um
ancestral de y, diremos que x cobre y. Por exemplo, considere objetos de trs tipos:
segmentos, pginas e palavras. Um segmento ser pai de todas as suas pginas e cada pgina
ser pai de todas as suas palavras.
Dentro deste esquema, uma transao pode bloquear um objeto x se nenhum dos objetos que
x cobre estiver bloqueado. Uma transao ao bloquear/liberar um objeto x, implicitamente
estar bloqueando/liberando todos os objeto que x cobre. Por exemplo, um segmento poder
ser bloqueado se nenhuma de suas pginas e nenhuma das palavras de suas pginas estiverem
bloqueadas.
A justificativa para este tipo de bloqueio est na economia que proporciona em termos de
memria ocupada e tempo adicional gasto na gerncia da tabela de bloqueios. Por exemplo,
em lugar de bloquear, digamos, 90% das 1000 pginas de um segmento, uma transao
bloquearia o segmento inteiro. Sem o uso de bloqueios em objetos hierarquizados seriam
necessrias 900 entradas na tabela de bloqueios. Com bloqueios em objetos hierarquizados,
apenas uma entrada cumpriria a mesma tarefa (embora 100 pginas fossem implicitamente
bloqueadas sem necessidade).
Com isto encerra-se a discusso preliminar sobre bloqueios.
- 15 -
8.3.2 Tratamento de Bloqueios Mtuos
8.3.2.1 Caracterizao de Bloqueios Mtuos
O uso de bloqueios, sem preocupaes adicionais, poder levar transaes a no terminarem.
Mais precisamente, possvel que em determinado ponto da execuo concorrente crie-se
uma seqncia de transaes T
i 0
,T
i 1
,..., T
i m-1
, T
i 0
tal que T
i j
espera por T
i j+1
(soma mdulo
m). Desta forma, nenhuma destas transaes terminar e tem-se uma situao de bloqueio
mtuo. A seqncia chamada de seqncia de impasse.
Bloqueios mtuos so caracterizados definindo-se o digrafo de espera G=(N,A) para o estado
corrente da tabela de bloqueios TB da seguinte forma:
N o conjunto de transaes que ocorrem na tabela TB tanto bloqueando objetos quanto
nas filas de espera;
A o conjunto de arcos ( T
i
, T
j
) tais que h uma tripla (x,T
j
,F) em TB tal que T
i
ocorre
em F (ou seja, T
i
espera por T
j
liberar o objeto x).
fcil observar que bloqueios mtuos no ocorrem no ponto em que G foi construdo se e
somente se G for acclico. Caso contrrio, cada ciclo de G representa uma seqncia de
impasse.
As duas formas bsicas para tratar o problema de bloqueios mtuos, deteo/resoluo e
preveno, sero discutidas nas subsees seguintes.
8.3.2.2 Deteco / Resoluo de Bloqueios Mtuos
O tratamento de bloqueios mtuos por deteco / resoluo consiste em deixar as transaes
processarem normalmente e, periodicamente, iniciar um processo independente P para
detectar / resolver bloqueios mtuos.
Para detetar a existncia de bloqueios mtuos, o processo P simplesmente constroi o grafo de
espera G, testando se G acclico ou no.
Para resolver bloqueios mtuos, o processo P age da seguinte forma. Se h ciclos em G,
transaes so selecionadas de tal forma que ao serem retiradas de G o novo grafo se torne
acclico. Usualmente para cada ciclo de G, selecionada a transao que consumiu menos
recursos at o momento. Cada transao selecionada reiniciada, liberando primeiro os
objetos que bloqueava. Cuidado deve ser tomado, no entanto, para que uma mesma transao
no seja reiniciada repetidamente, o que a impediria de eventualmente terminar. Uma tcnica
para se evitar esta situao seria reiniciar, no a transao que consumiu menos recursos, mas
a transao que foi submetida por ltimo. Assim o sistema garantiria que a transao mais
antiga sempre termina.
8.3.2.3 Preveno de Bloqueios Mtuos
A forma mais simples de evitar bloqueios mtuos consiste em liberar um objeto sempre que a
transao pedir novo bloqueio. Este mtodo, embora usado em certos casos, totalmente
insatisfatrio do ponto de vista de controle de concorrncia pois permite a criao de
execues no serializveis.
Uma outra forma de prevenir bloqueios mtuos consiste em exigir que cada transao
bloqueie todos os objetos que ir acessar atravs de uma nica ao indivisvel, que
- 16 -
executada antes da transao acessar o primeiro objeto. A nica vantagem deste esquema a
sua aparente simplicidade. Porm, ele exige que todos os objetos que uma transao ir
acessar sejam conhecidos inicialmente, o que nem sempre possvel, e que quase sempre
leva a bloquear mais objetos do que o necessrio. Alm disto, este esquema exige para sua
implementao que o protocolo de bloqueio/liberao seja modificado para permitir o
bloqueio de vrios objetos ao mesmo tempo para uma mesma transao (em lugar de apenas
um de cada vez, como anteriormente). A modificao necessria no fcil de implementar e
poder levar mesmo a problemas de bloqueio mtuo. (O leitor dever tentar modificar o
protocolo para perceber este fato. Foi justamente por este problema que decidimos por uma
ao elementar que bloqueasse apenas um objeto).
Um terceiro mtodo, satisfatrio do ponto de vista de controle de concorrncia, seria o
seguinte. Quando uma transao T
i
pede para bloquear um objeto x, que est presentemente
bloqueado para T
j
, um teste executado. Se T
i
e T
j
passarem pelo teste, T
i
poder ento ser
adicionada fila de espera de x. Caso contrrio T
i
ou T
j
so canceladas. Se a transao T
i
que
solicita o bloqueio sempre a escolhida, o mtodo chamado de no-preemptivo.. Se a
transao T
j
que detm o bloqueio sempre a escolhida, o mtodo chamado de preemptivo.
O teste escolhido dever sempre garantir que bloqueios mtuos no iro ser criados ao
adicionar T
i
fila de espera de x. Em termos do grafo de espera, isto significa que a adio do
arco (T
i
,T
j
) ao grafo no ir criar ciclos. H vrios testes possveis com esta propriedade. O
mais simples seria sempre reiniciar T
i
ao solicitar o bloqueio, que geraria um desperdcio
grande de recursos. Dois testes mais razoveis, baseados em prioridades dadas s transaes,
seriam :ol atomic. Verso no-preemptiva: deixe T
i
esperar por T
j
se e somente se T
j
tiver
prioridade menor do que T
i
; caso contrrio cancele T
i
. Verso preemptiva: deixe T
i
esperar
por T
j
se e somente se T
j
tiver prioridade maior do que T
i
; caso contrrio cancele T
j
.
Estes testes garantem a ausncia de bloqueios mtuos. De fato, considere a verso no-
preemptiva. Se houvesse um ciclo no grafo de espera, haveria uma transao com prioridade
maior do que ela mesma (pois uma transao s espera por outra com prioridade menor). Para
o caso da verso preemptiva, o raciocnio o mesmo, exceto que uma transao s espera por
outra com prioridade maior.
No entanto, como no h restries sobre a forma de associar prioridades s transaes, o
teste no garante que uma transao termine: ela poder ser continuamente cancelada. Um
esquema que evitaria este problema seria definir a prioridade de uma transao como a
data/hora em que a transao foi submetida. A transao com menor data/hora considerada
como a de maior prioridade ou a transao mais velha do sistema. Supondo que duas
transaes no so submetidas no mesmo instante, cada transao receber uma prioridade
nica.
Este esquema, acoplado com qualquer um dos testes anteriores, garante que toda transao
sempre termina. De fato, ambos os testes garantem que a transao mais velha (de mais alta
prioridade) no sistema sempre termina e que toda transao, em um espao finito de tempo,
se tornar a transao mais velha ativa no sistema (pois as mais velhas sempre vo
terminando).
Tcnicas preemptivas requerem um cuidado adicional. Caso a transao j tenha sido
confirmada, ou seja, caso uma deciso j foi tomada para instalar as modifioes produzidas
pela transao no banco de dados, a transao no poder ser cancelada. Para evitar este
problema, deve-se garantir que, ao atingir esta fase, a transao detenha todos os bloqueios
que precisa. Assim, no esperar por nenhuma outra transao, o que implica em que no
- 17 -
participa de nenhuma seqncia de impasse e, portanto, ir terminar normalmente.
8.3.3 Protocolo de Bloqueio em Duas Fases
Considere agora o problema de usar bloqueios para criar um mtodo de controle de
concorrncia correto, ou seja, que garanta que, para toda execuo concorrente E permitida
pelo mtodo
1) todas as transaes iniciadas em E terminam;
2) E serializvel.
No caso do uso de bloqueios, violaes da primeira condio resultam da criao de
bloqueios mtuos ou do cancelamento repetido da mesma transao, o que j foi discutido na
seo anterior. Consideraremos, portanto, este problema como resolvido, concentrando a
ateno no problema de serializao.
O uso de bloqueios por si s no suficiente para atingir serializao. Por exemplo, considere
o seguinte protocolo:
1) bloqueie cada objeto antes de acess-lo;
2) libere cada objeto imediatamente aps acess-lo.
Este protocolo obviamente incorreto pois permitiria a criao de qualquer intercalao das
aes das transaes. Para transformar qualquer escalonamento sem bloqueios em um
escalonamento satisfazendo a este protocolo, basta envolver cada ao de leitura ou
atualizao O
i
( x
1
,..., x
k
) entre as aes B
i
(x
1
) ,..., B
i
(x
k
) e L
i
( x
1
,..., x
k
) .
Apresentaremos nesta seo um exemplo de um protocolo baseado em bloqueios que garante
serializao, cuja correo provada na seo seguinte. O protocolo chama-se bloqueio em
duas fases e definido da seguinte forma:
1) Cada transao dever bloquear cada objeto antes de acess-lo e liberar todos os objetos
que bloqueou at terminar;
2) Uma vez que uma transao liberar um objeto, no mais poder bloquear outros objetos
da em diante.
O nome deste protocolo advm do fato de que, para cada transao, h uma primeira fase em
que os objetos que a transao precisa so gradualmente bloqueados e uma segunda fase em
que todos os objetos so gradualmente liberados. O ponto do escalonamento em que se d a
liberao do primeiro objeto da transao chamado de ponto de bloqueio da transao.
Adotando a representao de uma execuo atravs de escalonamentos com as aes R(X),
W(X), B(x) e L(X), um escalonamento modelando uma execuo que satisfaz ao protocolo de
bloqueio em duas fases seria:
L = B
1
(x) R
1
(x) B
2
(y) R
2
(y)W
1
(x) L
1
(x) B
2
(x) L
2
(y) W
2
(x) L
2
(x)
O escalonamento abaixo, por sua vez, viola o protocolo de bloqueio em duas fases:
M = B
1
(x) R
1
(x) B
2
(y) R
2
(y) L
1
(x) B
2
(x) L
2
(y) W
2
(x) L
2
(x) B
1
(x) W
1
(x) L
1
(x)
Note que, em M, a transao T
1
libera x aps R
1
(x), voltando bloque-lo antes de W
1
(x), o
- 18 -
que constitui uma violao da condio 2 do protocolo. Note ainda que L serializvel, mas
no F.
Como ltimo exemplo, considere o seguinte escalonamento (sem bloqueios e liberaes):
N = R
1
(x) W
2
(x) W
1
(x) W
3
(x)
Este escalonamento serializvel por ser equivalente a
S = R
1
(x) W
1
(x) W
2
(x) W
3
(x)
mas N no satisfar ao protocolo de bloqueio em duas fases, para qualquer adio de
bloqueios / liberaes. Logo as condies impostas pelo protocolo no so necessrias para
serializao (na seo seguinte mostraremos que so suficientes).
Uma implementao centralizada deste protocolo ser discutida mais adiante, deixando para a
Seo 8.4 a apresentao de implementaes distribudas. Antes, porm, convm provar a
correo do protocolo.
*8.3.4 Correo do Protocolo de Bloqueio em Duas Fases
Mostraremos nesta seo que toda execuo concorrente seguindo o bloqueio em duas fases
serializvel, se todas as transaes terminam. Ou seja, o problema de terminao suposto
resolvido por outros mtodos.
Recorde que o banco centralizado e que o ponto de bloqueio de uma transao o ponto do
escalonamento em que se d a primeira ao L(x) da transao. Seja E uma execuo
concorrente de um conjunto T de transaes modelada por um escalonamento L. Suponha que
todas as transaes terminem em E e que elas sigam o protocolo de bloqueio em duas fases.
Defina uma relao em T tal que T
i
T
j
se e somente se o ponto de bloqueio de T
i
precede o ponto de bloqueio de T
j
. Provaremos que
(1) uma relao de ordem total em T.
De fato, como E induz uma ordem total das aes das transaes, em particular, induz uma
ordem total para o conjunto das aes L(X) que primeiro foram executadas pelas transaes.
Esta ltima, por sua vez, gera a relao sobre T.
Considere agora a relao de precedncia por conflito, <, sobre T induzida por L.
Mostraremos agora que
(2) se T
i
< T
j
ento T
i
T
j
Suponha que T
i
< T
j
. Ento existem aes O
i
(X) e O
i
(X) de T
i
e T
j
, respectivamente, tais que
O
i
(X) e O
j
(Y) conflitam e O
i
(X) precede O
j
(Y). Logo, existe um objeto x X Y. Pela
condio 1 do protocolo de bloqueio em duas fases, uma ao B
i
(x) de T
i
ter que preceder
O
i
(X) e, da mesma forma, uma ao B
j
(x) de T
j
ter que preceder O
i
(X). Pelo protocolo de
bloqueio / liberao de objetos, uma ao L
i
(Z) de T
i
tal que x Z ter que suceder O
i
(X) e
preceder B
j
(x). Por definio, o ponto de bloqueio de T
i
ter que preceder ou coincidir com
L
i
(Z). Mas, pela condio 2 do protocolo de bloqueio em duas fases, o ponto de bloqueio de
T
j
ter que suceder B
j
(x). Logo, por transitividade, o ponto de bloqueio de T
i
precede o ponto
de bloqueio de T
j
em L. Assim, T
i
T
j
.
- 19 -
Finalmente, como, por (1), uma relao de ordem total, temos que < uma relao de
ordem parcial. Logo pelo Teorema 1 da Seo 8.2.4, a execuo E serializvel, como se
queria demonstrar.
8.3.5 Uma Implementao Centralizada do Protocolo de Bloqueio em Duas Fases
Esta seo apresenta uma implementao do protocolo de bloqueio em duas fases que
completamente transparente aos usurios. Assumiremos que o modelo de processamento de
transaes adotado no caso centralizado uma simplificao daquele descrito na Seo 8.1.2.
Ou seja, as modificaes a serem efetuadas nos objetos so mantidas em uma rea de trabalho
at que a transao complete o processamento. Neste ponto a transao poder cancelar,
descartando-se as modificaes, ou terminar corretamente, sendo gerado ento uma ao
W(x) para instalar todas as modificaes no banco de dados de forma atmica. Neste cenrio,
uma implementao possvel de bloqueio em duas fases seria
1) as aes de leitura R(x) implicitamente geram uma ao prvia de bloqueio B(x), para
cada x X ;
2) se a transao foi processada normalmente:
a) todos os objetos que tiveram seu valor modificado pela transao so bloqueados
antes que a ao de atualizao final seja executada.
b) aps a ao W(x) ser executada, todos os objetos acessados pela transao so
liberados.
3) se a transao cancelada, todos os objetos que mantinha bloqueados so liberados.
Note que nesta implementao os objetos so mantidos bloqueados at o final da transao,
ou seja, o ponto de bloqueio se d ao final da transao. Esta implementao coerente com
o cenrio previsto nos ltimos captulos em que uma transao pode ser cancelada durante a
execuo. De fato, suponha que a liberao de objetos cujo valor foi alterado seja permitida
antes da transao terminar. Se a transao for cancelada aps liberar um objeto que alterou,
todas as outras transaes que leram aquele valor teriam que ser canceladas tambm e as suas
modificaes desfeitas, mesmo que j tivessem terminado, e assim recursivamente. Ou seja, o
cancelamento de uma transao poderia provocar cancelamentos em cascata de outras
transaes.
Isto conclui a discusso sobre o protocolo de bloqueio em duas fases centralizado.
8.4 MTODOS BASEADOS EM BLOQUEIOS - PARTE II
Esta seo discute implementaes do protocolo de bloqueio em duas fases e algoritmos para
deteo de bloqueios mtuos em um ambiente de bancos de dados distribudos. As
implementaes diferiro essencialmente no posicionamento da tabela de bloqueios ao longo
da rede. O argumento de correo destas implementaes segue diretamente da prova de
correo do protocolo de bloqueio em duas fases para o caso centralizado e, portanto, ser
omitido.
Em todas as implementaes assume-se que as transaes so processadas conforme descrito
na Seo 8.1.2. Em particular, todas as modificaes so armazenadas em uma rea de
trabalho at que a transao execute um comando FIM-DE-TRANSAO, quando o protocolo
- 20 -
bifsico para confirmar intenses invocado para instalar as modificaes criadas pela
transao, ou rejeit-las, cancelando a transao.
8.4.1 Implementao Bsica
Por implementao bsica do protocolo de bloqueio em duas fases em um ambiente
distribudo entenderemos aquela em que a tabela de bloqueios distribuda junto com os
dados. Mais precisamente, para cada n onde h um banco de dados local, haver tambm
uma tabela de bloqueios para controle do acesso aos objetos locais. Esta tabela
implementada como no caso centralizado e gerenciada por uma cpia local do protocolo de
bloqueio/liberao de objetos. Desta forma, se os SGBDs locais j usavam uma tcnica de
bloqueios, nada mais necessrio fazer para controle de concorrncia do banco distribudo,
exceto deteo de bloqueios mtuos.
Os pedidos de bloqueio/liberao so gerados automaticamente dentro do seguinte esquema:
1. um bloqueio B(x) criado imediatamente antes de uma leitura R(X) ser processada
localmente, para cada xX;
2. um bloqueio B(x) criado imediatamente aps uma mensagem PREPARE_SE ser
recebida na primeira fase do protocolo bifsico, para cada objeto x que reside localmente
e cujo valor foi modificado pela transao;
3. uma liberao L(X) criada imediatamente aps uma mensagem PREPARE_SE ser
recebida na primeira fase do p localmente e cujos valores no foram modificados pela
transao;
4. uma liberao L(X) criada aps as modificaes terem sido instaladas no banco, caso o
n tenha recebido uma mensagem CONFIRME, ou aps o n ter recebido uma mensagem
CANCELE, onde X o conjunto dos objetos que residem localmente e cujos valores
foram modificados pela transao;
interessante observar que a implementao acima no toma conhecimento da existncia de
cpias. Se porventura os objetos x
1
,..., x
k
representam cpias do mesmo dado em ns
diferentes, caber ao processador de comandos da LMD e ao gerente de transaes
providenciar para que todas as cpias sejam atualizadas. Para cada n onde reside uma cpia,
o novo valor ser enviado durante o protocolo bifsico. Assim sendo, a existncia de cpias
torna-se transparente ao mecanismo de controle de concorrncia.
8.4.2 Implementao por Cpias Primrias
A implementao distribuda de certa forma desperdia recursos locais por bloquear todas as
cpias de um mesmo objeto lgico. Se recursos locais so escassos e vantajoso economiz-
los em troca de um maior trfego de mensagens, pode-se optar pela implementao usando
cpias primrias. A idia simples. Suponhamos que os objetos fsicos estejam particionados
de tal forma que os objetos em cada partio representem cpias dos mesmos dados. Para
cada partio, designe um objeto fsico como a cpia primria daquela partio. Antes de
acessar qualquer objeto fsico em uma dada partio, a cpia primria correspondente dever
ser bloqueada.
Os pedidos de bloqueio/liberao so gerados automaticamente dentro do seguinte esquema:
- 21 -
1. Antes de uma ao R
k
(X) da transao T
k
ser processada localmente em i, uma mensagem
para bloquear cada objeto x X enviada ao n j que mantm a cpia primria x
p
correspondente x. O n j tenta bloquear x
p
para T
k
e, aps obter sucesso, envia uma
mensagem ao n i confirmando o bloqueio. A ao R
k
(X) espera at que todas as cpias
tenham sido bloqueadas.
2. um bloqueio B(x) criado imediatamente aps uma mensagem PREPARE_SE ser
recebida na primeira fase do protocolo bifsico, para cada cpia x cujo valor foi
modificado pela transao (como todas as cpias de cada objeto tem que ser igualmente
alteradas pela transao, a cpia primria x
p
correspondente a x ser automaticamente
bloqueada para a transao, no havendo necessidade de bloque-la explicitamente);
3. uma liberao L(X) criada imediatamente aps uma mensagem PREPARE_SE ser
recebida na primeira fase do protocolo bifsico, onde X o conjunto de todas as cpias
primrias que residem localmente e cujos valores no foram modificados pela transao;
4. uma liberao L(X) criada aps as modificaes terem sido instaladas no banco, caso o
n tenha recebido uma mensagem CONFIRME, ou aps o n ter recebido uma mensagem
CANCELE, onde X o conjunto de todas as cpias primrias que residem localmente e
cujos valores foram modificados pela transao;
Note que, ao bloquear apenas a cpia primria, o processamento local em cada n tende a
diminuir pois menos bloqueios so realizados. Porm, para se ler a cpia armazenada em i,
uma mensagem extra dever ser enviada ao n j (exceto se i=j ). Portanto, esta
implementao gera um trfego maior na rede apenas para controle de concorrncia.
A ltima observao adquire maior peso se a granularidade dos objetos fsicos for pequena.
Por exemplo, se os objetos fsicos so pginas, para cada pgina a ser lida uma mensagem
teria que ser enviada ao n que contm a cpia primria daquela pgina, o que inaceitvel.
Uma forma de resolver este problema seria agrupar vrios pedidos de bloqueio para um
mesmo n em uma s mensagem. Uma segunda soluo seria adotar bloqueio hierarquizado.
Por exemplo, segmentos inteiros seriam bloqueados em lugar de pginas. De qualquer forma,
o conceito de "cpia" deve estar bem definido na arquitetura do sistema.
8.4.3 Implementao por Bloqueio Centralizado
Em ambas as implementaes anteriores, a tabela de bloqueios tambm distribuda ao longo
da rede. Esta opo torna a deteo de bloqueios mtuos mais difcil pois, para se construir o
grafo de espera, ser necessrio consultar todos os ns em que uma parte da tabela est
armazenada. Se bloqueios mtuos so muito frequentes e necessrio detet-los e resolv-los
rapidamente, uma terceira implementao alternativa torna-se atraente.
Na implementao por bloqueio centralizado, elege-se um n coordenador da rede para
conter toda a tabela de bloqueios. Para qualquer objeto que for acessado, uma mensagem de
bloqueio dever ser enviada ao n coordenador, que responder ento ao n que solicitou o
bloqueio. A implementao bastante semelhante do bloqueio por cpias primrias e ser
omitida.
Esta implementao oferece como vantagem, conforme j mencionado, a facilidade de
deteo/resoluo de bloqueios mtuos pois toda a tabela de bloqueios reside em um nico
n. Assim, a construo do grafo de espera pode ser feita localmente. Por outro lado, esta
implementao apresenta os mesmos problemas da implementao baseada em cpias
- 22 -
primrias, acrescidos de dois outros. Primeiro, o trfego adicional de mensagens para
controle de concorrncia canalizado para o n coordenador, gerando uma sobrecarga
localizada na rede. Segundo, e mais grave, a implementao muito vulnervel a falhas
envolvendo o n coordenador. Se a tabela de bloqueios for perdida ou o n coordenador por
algum motivo no puder ser contactado, todas as transaes correntes tero que ser
canceladas e um protocolo de eleio do novo n coordenador dever ser completado antes
do processamento normal ser reiniciado. Isto significa que vrias das vantagens advindas do
uso de um banco de dados distribudo simplesmente perdem o sentido nesta implementao.
8.4.4 Tratamento de Bloqueios Mtuos no Caso Distribudo
O tratamento de bloqueios mtuos no caso distribudo muito semelhante ao caso
centralizado. As tcnicas preventivas discutidas para o caso centralizado tambm se aplicam
ao caso distribudo. A nica observao adicional se refere gerao de prioridades atravs
da data/hora em que a transao foi submetida. Como h vrios ns, duas transaes podero
receber a mesma prioridade em ns diferentes dentro deste esquema. Uma soluo
consagrada consiste em adotar o par (n,d) como a prioridade da transao, onde n o nmero
do n onde ela foi submetida (assume-se que dois ns no tm o mesmo nmero) e d a
data/hora em que a transao foi submetida. Uma transao que recebeu o par (n,d) ter
prioridade maior que uma transao que recebeu o par (n',d') se e somente se n < n' ou n = n'
e d < d'.
J a deteo/resoluo de bloqueios mtuos, quando se opta pela implementao bsica ou
pela implementao atravs de cpias primrias, merece comentrios especiais. O problema
bsico est em que cada tabela local de bloqueios gera apenas um subgrafo do grafo de
espera. Naturalmente cada um destes subgrafos poder ser acclico sem que o grafo completo
o seja. Em outros termos, no possvel fazer deteo de bloqueios mtuos apenas
localmente. O resto desta seo discute duas formas de implementar deteo de bloqueios
mtuos neste caso.
Seja N um conjunto de ns. Chamaremos de subgrafo de espera local a N ao subgrafo do
grafo de espera induzido pelas tabelas de bloqueios residentes em ns pertencentes a N. Ao
grafo completo chamaremos de grafo de espera global. Similarmente, chamaremos de
bloqueio mtuo local a N a um bloqueio mtuo gerado por um ciclo no subgrafo de espera
local a N. Chamaremos de bloqueio mtuo global a um bloqueio mtuo gerado por um ciclo
do grafo de espera global.
A implementao mais simples consistiria em, periodicamente, cada n i que contm uma
tabela de bloqueios construir o subgrafo de espera local a i e envi-lo para um n central
designado. O n central construiria ento o grafo de espera global, detetando e resolvendo
bloqueios mtuos como no caso centralizado.
O mtodo anterior na verdade induz uma rvore de altura 2, cuja raiz o n central e cujas
folhas so os outros ns. Uma segunda implementao, que chamaremos de algoritmo
hierrquico, generaliza esta observao. Supe-se inicialmente que os ns da rede estejam
logicamente organizados em uma rvore (para propsitos do algoritmo apenas). Por exemplo,
os ns de um mesmo municpio so todos filhos de um mesmo n municipal, os ns
municipais em um mesmo estado so por sua vez filhos de um mesmo n estadual e assim
por diante. Periodicamente (e sincronamente), cada folha f constri o subgrafo de espera local
a f, baseando-se na tabela de bloqueios local, e tenta detetar e resolver bloqueios mtuos
locais a f; em seguida envia o subgrafo para o seu pai. Um n interior n, ao receber os
- 23 -
subgrafos dos seus filhos, e aps construir o seu prprio subgrafo local, faz a unio de todos
estes subgrafos e tenta detetar bloqueios mtuos locais a N, onde N o conjunto dos ns da
subrvore cuja raiz n; em seguida, envia o subgrafo consolidado para seu pai e assim por
diante at a raiz.
8.5 MTODOS BASEADOS EM PR-ORDENAO
Esta seo discute controle de concorrncia por pr-ordenao para bancos de dados
distribudos. Inicialmente o protocolo genrico apresentado e em seguida vrias
implementaes discutidas.
8.5.1 Protocolo de Pr-Ordenao
Como o nome indica, neste protocolo uma ordem imposta "a priori" s transaes, e deve
ser respeitada pela execuo concorrente das transaes. Mais precisamente, o protocolo de
pr-ordenao opera da seguinte forma:
1. Cada transao ao ser iniciada recebe uma senha ou nmero de protocolo, nica ao longo
da rede, de forma transparente aos usurios.
2. Em cada n h um mecanismo de controle de concorrncia local que garante que as aes
conflitantes (veja Seo 8.2.4) geradas pelas transaes so processadas em ordem de
senha.
A correo deste protocolo imediata. Seja E uma execuo concorrente de um conjunto T
de transaes. Suponha que E tenha seguido o protocolo de pr-ordenao. Seja :f/lt/ a
relao de precedncia por conflito sobre T induzida por E. Como as aes conflitantes so
executadas em E na ordem de senha, temos que se T
i
< T
j
ento a senha de T
i
menor do que
a senha de T
j
. Logo, < necessariamente uma relao de ordem parcial sobre o conjunto das
transaes (pois as senhas impe uma ordem total s transaes), o que implica que E
serializvel.
O protocolo de pr-ordenao age ento de forma completamente diferente do protocolo de
bloqueio em duas fases pois, no primeiro, a ordem de serializao das transaes imposta "a
priori", enquanto que no segundo imposta "a posteriori". Esta observao est clara no que
concerne ao protocolo de pr-ordenao. Para compreend-la melhor no caso de bloqueio em
duas fases, recordemos que a prova de correo deste indica-nos que toda execuo
concorrente E seguindo o bloqueio em duas fases sempre serializvel e que a execuo
serial S equivalente a E obtida processando-se as transaes em ordem dos seus pontos de
bloqueio (em E). Assim, na execuo concorrente E, os usurios do sistema tem a iluso de
que tudo se passa como se as transaes fossem executadas seqencialmente na ordem em
que atingiram os seus pontos de bloqueio. Porm, esta ordem no imposta "a priori",
dependendo da prpria dinmica das transaes e da intercalao mais ou menos fortuita das
aes elementares sobre os bancos locais.
interessante fazer tambm uma analogia entre o protocolo de pr-ordenao e uma
disciplina s vezes usada em estabelecimentos (bem organizados) em que o cliente, ao
chegar, apanha uma senha e aguarda a vez para ser atendido. Se houver apenas um
empregado e o cliente for atendido sem interrupo, a situao se torna equivalente a permitir
apenas execues seriais. O caso interessante acontece quando vrios empregados atendem a
- 24 -
vrios pedidos de vrios clientes ao mesmo tempo. A disciplina de senhas (isto , o prprio
protocolo de pr-ordenao) deve necessariamente harmonizar todo o trabalho de tal forma
que o cliente com senha i tenha sempre a iluso de que foi atendido antes do cliente com
senha j, se i<j (e, portanto, no reclame do aparente caos reinante).
As prximas subsees desta seo discutiro implementaes alternativas do protocolo de
pr-ordenao em um ambiente distribudo.
8.5.2 Implementao Bsica
Na implementao bsica, o protocolo opera exatamente como descrito na seo anterior.
A implementao do primeiro passo do protocolo exige que a gerao de senhas ao longo da
rede seja tal que duas transaes no recebam o mesmo nmero de senha. Para tal, conforme
discutido na Seo 8.4.4., poderemos usar como senha o par (n,d) onde n o nmero do n
onde a transao se originou e d a data/hora em que a transao foi submetida.
A implementao do segundo passo bem mais difcil pois requer construir um mecanismo
de controle de concorrncia local que garanta que as aes conflitantes so processadas em
ordem de senha. A seguinte estratgia poderia ser usada neste caso. Para cada objeto fsico x
do sistema so mantidas duas variveis:
R_senha(x) senha da ltima operao R(X) que acessou o objeto
W_senha(x) senha da ltima operao W(X) que acessou o objeto
O mecanismo de controle de concorrncia que controla o entrelaamento das aes
elementares em um dado n seria o seguinte:
1) se a operao uma leitura R(X) com nmero de senha s ento:
a) faa w igual ao maior W_senha(x) para os objetos x X.
b) se w<s, ento processe a leitura e faa R_senha(x) = s, para cada x X.
c) caso contrrio, rejeite a leitura e reinicie a transao.
2) se a operao uma atualizao W(X) com nmero de senha s ento:
a) faa r igual ao maior valor de R_senha(x) para os objetos x X.
b) faa w igual ao maior valor de W_senha(x) para os objetos x X.
c) se max(r,w)<s, ento processe a atualizao, e faa W_senha(x) = s, para cada x X.
d) caso contrrio, rejeite a atualizao e reinicie a transao.
As transaes reiniciadas recebem um nmero de senha maior do que antes.
Esta implementao corretamente processa aes conflitantes em ordem de senha. De fato,
seja E uma execuo seguindo esta implementao e modelada por um escalonamento global
L. Sejam O
i
e O
j
aes em um escalonamento local de L com senhas s
i
e s
j
. Suponha que O
i
precede O
j
e que O
i
conflita com O
j
. Seja x um objeto acessado por O
i
e O
j
(x existe pois estas
aes conflitam). Suponha que O
i
uma leitura (logo O
j
tem que ser uma atualizao). Como
O
i
precede O
j
, temos como resultado dos testes que s
i
< R_senha(x) < s
j
. Logo, O
i
e O
j
foram
- 25 -
processadas em ordem de senha, como se queria demonstrar. O caso em que O
i
uma
atualizao anlogo.
H trs problemas ainda com esta implementao: armazenamento das variveis R_senha e
W_senha, relacionamento com o protocolo bifsico para confirmar intenses, e problemas de
terminao.
Para o primeiro destes problemas, duas solues so sugeridas. Suponhamos, inicialmente,
que os objetos fsicos sejam pginas. A primeira soluo consiste em armazenar as variveis
R_senha(x) e W_senha(x) diretamente na pgina x. Esta soluo fora o protocolo a ler cada
pgina x X apenas para obter o valor de R_senha(x) e W_senha(x), mesmo que a ao R(X)
ou W(X) venha a ser rejeitada. Se a percentagem de aes rejeitadas for baixa, este custo
adicional ser pequeno no cmputo total, pois os acessos s pginas so de qualquer forma
necessrios ao prprio processamento das aes.
Uma segunda soluo para o primeiro problema seria manter em uma tabela parte um certo
nmero de valores das variveis R_senha(x) e W_senha(x) e "esquecer" os valores mais
antigos. Desta forma, memria adicional seria economizada e os valores das variveis
estariam disponveis sem acessar as prprias pginas. Naturalmente que no possvel
simplesmente esquecer valores de senha, o que fora a usar um esquema mais elaborado.
Mais precisamente, a soluo proposta baseia-se nas seguintes estruturas de dados:
R_tabela contm pares (x,R_senha(x)) para os objetos x mais recentemente usados
W_tabela contm pares (x,W_senha(x)) para os objetos x mais recentemente usados
R_max maior valor de R_senha(x) que foi expurgado de R_tabela
W_max maior valor de W_senha(x) que foi expurgado de W_tabela
As tabelas so gerenciadas da seguinte forma. Quando um objeto x lido, um par (x,s)
adicionado a R_tabela, onde s a senha da ao de leitura. Se j houver um par (x,s') em
R_tabela inicialmente, s' simplesmente substitudo por s. Se R_tabela estiver cheia, um par
(y,t) selecionado de acordo com alguma poltica como, por exemplo, selecionar sempre o
par que foi referenciado pela ltima vez h mais tempo. O par (y,t) expurgado da tabela,
dando lugar a (x,s).
No entanto, o par (y,t) no pode ser abandonado sem qualquer cuidado adicional, pois a senha
t de y necessria para o protocolo de pr-ordenao. Para contornar este problema, a
varivel R_max mantida. Assim, ao expurgar (y,t), faz-se R_max := max(R_max,t) .
A implementao do protocolo modificada da seguinte forma. Para se obter o valor de
R_senha(x), pesquisa-se a R_tabela primeiro. Se existir um par (x,r) em R_tabela, r tomado
como o valor de R_senha(x). Caso contrrio, toma-se R_max como o valor de R_senha(x).
Note que o valor verdadeiro de R_senha(x) neste segundo caso menor ou igual a R_max. O
tratamento de W_senha(x) semelhante.
Assim sendo, os testes aplicados na implementao corretamente garantiro que aes
conflitantes so processadas em ordem de senha. Porm, algumas aes sero rejeitadas
desnecessariamente pois R_max e W_max so uma estimativa conservativa de R_senha e
W_senha. A soluo sugerida aqui representa ento um balano entre gastar menos memria
para armazenar R_senha e W_senha ou reiniciar transaes com mais freqncia.
Passemos agora para o segundo problema, o relacionamento com o protocolo bifsico.
- 26 -
Sabemos que durante a primeira fase do protocolo bifsico, mensagens de PREPARE_SE so
enviadas para cada n participante do processamento da transao. Desta forma o protocolo
bifsico determina se a transao deve ser aceita ou cancelada. Se aceita, mensagens
CONFIRME so enviadas em seguida para que os ns atualizem o banco de dados atravs de
aes de atualizao W(X), que necessariamente ter&aoi. que ser executadas. Portanto, a
deciso de aceitar ou rejeitar W(X) (implicando em votar SIM ou NO) dever ser tomada
quando a mensagem de PREPARE_SE chegar e no quando W(X) for efetivamente
processada. Para tal, o mecanismo de controle de concorrncia local deve ser modificado para
fazer os testes necessrios aceitao de W(X) quando a mensagem de PREPARE_SE (que
dever vir com o nmero de senha e o conjunto X) for recebida, e no ao processar W(X).
Alm disto, uma vez que um n votou SIM aceitando a transao, ele ter que garantir que
W(X) ser necessariamente executada. Isto significa que nenhuma ao R(Y) ou W(Z) que
invalide a deciso tomada ao processar PREPARE_SE poder ser executada entre receber
PREPARE_SE e processar W(X). Esta regra pode ser implementada mudando-se W_senha(x)
para , para todo x X, quando PREPARE_SE for aceito, e atualizando-se W_senha(x) para o
valor correto depois de processar W(X), para todo x X. Com W_senha(x) = , para todo x
X, todas as aes que conflitam com W(X) sero rejeitadas. Uma outra forma de implementar
a regra seria combinar bloqueios com as senhas de tal forma a evitar que aes com nmero
de senha maior do que a senha de W(X) e que conflitem com W(X) sejam processadas
indevidamente entre PREPARE_SE e W(X). Tais aes ficariam bloqueadas at que W(X)
fosse executada, em lugar de serem rejeitadas como na soluo anterior. Na verdade, estas
duas solues podero ser combinadas usando mudana de senha para bloquear aes.
Finalmente necessrio examinar o problema de terminao. No contexto desta
implementao uma transao T
i
poder no terminar se for reiniciada ciclicamente. De fato,
neste protocolo, erros de sincronizao ocorrem quando uma ao chegou "atrasada", por
assim dizer, com relao a outra ao com que conflita. A nica forma de corrigir um erro
reiniciar a transao T
i
com uma senha maior do que a anterior (se a transao for repetida
com a mesma senha fatalmente ser reiniciada novamente).
A soluo para este problema consiste em reiniciar a transao T
i
com uma nova senha tal
que seja garantidamente maior do que a senha de qualquer outra transao processada
concorrentemente com T
i
. Desta forma, todas as aes de T
i
passaro pelos testes do
protocolo o que significa que T
i
ir necessariamente terminar. No entanto, como no
simples impor que a senha de T
i
possua esta propriedade em um ambiente distribudo,
prefervel apenas incrementar a senha de T
i
. suficientemente para aumentar a sua chance de
terminar. Dentro do mtodo de gerar senhas proposto nesta seo, isto significa adiantar o
relgio local do n onde a transao foi submetida.
A poltica de aumento de senha ainda tem um outro fator determinante. Existe a possibilidade
do processamento de vrias transaes sincronizar-se de tal forma a causar o reincio mtuo
de todas elas. Ou seja, cria-se uma seqncia de transaes T
i 0
,T
i 1
,..., T
i m-1
,T
i 0
tal que T
i j
fora o reincio de T
i j+1
(soma mdulo m). Se o aumento da senha for o mesmo para todas
estas transaes, corre-se o risco de se repetir a situao indefinidamente. Note que esta a
contra-partida de bloqueio mtuo quando a forma de corrigir erros de sincronizao
baseada no reincio de transaes. No entanto, existe uma forma simples de minimizar a
chance de uma situao de reincio mtuo se formar: basta randomizar o incremento dado s
senhas quando reiniciar transaes. Este esquema simples naturalmente no evita
completamente o problema de reincio cclico, mas o torna pouco provvel.
- 27 -
8.5.3 Implementao Conservativa
Uma segunda forma de implementar o protocolo de pr-ordenao, desta feita bem simples,
seria processar as aes localmente em ordem de senha, quer elas conflitem ou no, mas de
tal forma que uma transao nunca seja rejeitada. Como no h necessidade de detetar
conflitos, o controle de concorrncia pode ser feito a nvel lgico ou fsico com igual
simplicidade. Por esta razo esta ser a nica implementao descrita a nvel lgico, ou seja,
a nvel dos subcomandos atuando sobre os objetos lgicos, embora possa ser convertida para
atuar a nvel fsico, ou seja, a nvel das aes elementares como todas as outras.
Nesta implementao, em cada n i onde o banco armazenado e para cada gerente de
transaes g que envia subcomandos para i so mantidas duas filas:
R_fila(g) fila contendo os subcomandos que apenas lem do banco local enviados por g
para o n i;
W_fila(g) fila contendo os subcomandos que modificam o banco local enviados por g
para o n i;
Exige-se que um gerente de transaes g envie os subcomandos para as filas R_fila(g) e
W_fila(g) em ordem de senha. Localmente, o mecanismo de controle de concorrncia
procederia da seguinte forma:
1. espere at que todas as filas contenham algum comando;
2. escolha o subcomando com menor senha e processe-o completamente.
A prova de correo desta implementao muito simples. Como todas as aes so
processadas em ordem de senha, em particular as que conflitam o so. Logo, camos no caso
geral do mtodo de pr-ordenao.
Fazendo uma breve comparao com a implementao bsica, a implementao conservativa
mais simples e, ao contrrio da implementao bsica, nunca fora transaes a serem
reiniciadas. Por outro lado, implicitamente bloqueia transaes pois sempre garante que a
escolha de um comando se deu na ordem correta, quer ele gere conflitos ou no (da o nome
de implementao conservativa).
O problema levantado na implementao anterior acerca do relacionamento com o protocolo
bifsico para confirmar intenses tambm ocorre nesta implementao, sendo resolvido de
forma semelhante. Alm deste, a implementao gera um tipo diferente de problema de
terminao e causa problemas de comunicao.
O protocolo, conforme descrito, pode ficar paralizado em um n i simplesmente porque um
gerente de transaes nunca manda nenhum comando para i, o que pode bloquear transaes
indefinidamente. Para resolver este problema os gerentes de transaes devero
periodicamente enviar mensagens de controle a todos os ns com que se comunicam
indicando a senha corrente que pretendem dar s suas transaes (que no esquema desta
seo o par (n,d), onde n o nmero do n onde a transao se originou e d a data/hora
em que a transao foi submetida).
Esta soluo, por sua vez, cria a necessidade de comunicao adicional entre os gerentes de
transaes e ns onde o banco est armazenado, que pode se tornar proibitiva em uma rede de
grandes propores. Para solucionar este ltimo problema, um gerente de transaes g poder
enviar uma mensagem de controle a um n i contendo uma senha n maior do que a sua
- 28 -
corrente indicando que no pretende mandar para i nenhum subcomando com senha menor
do que n. Esta mensagem de controle no precisa ser repetida at que as senhas dadas por g
cheguem a n. Naturalmente, dever haver um mecanismo adicional para revogar esta deciso,
caso g tenha necessidade de enviar a i um subcomando com senha menor do que n.
8.5.4 Implementao Baseada em Verses Mltiplas
Nas duas implementaes at agora discutidas, uma ao de leitura rejeitada sempre que
chegar atrasada, ou seja, sempre que o valor do objeto que ela deveria ter lido j tiver sido
substitudo por um mais novo. Uma forma de minimizar o reincio de transaes por este
motivo seria manter uma srie histrica com todas as verses do valor de cada objeto. Quanto
maior a srie, maior a chance do valor que uma ao de leitura precisa estar disponvel. Por
outro lado, maior o desperdcio de memria por fora do mecanismo de controle de
concorrncia.
Consideremos inicialmente o caso extremo em que a srie histrica com todas as verses de
cada objeto mantida. As seguintes estruturas de dados sero ento mantidas para cada
objeto x:
R_seq(x) seqncia de todas as senhas das aes de leitura para o objeto x.
Verses(x) seqncia contendo todas as verses j criadas para x, representadas por pares
da forma (s,V), onde s a senha da ao que criou a verso V de x.
De posse destas estruturas, o mecanismo de controle de concorrncia local passa a ser o
seguinte:
1) Suponha que a ao uma leitura R(X) com senha r. Para cada x X , escolha o par (s,V)
em Versoes(x) tal que s a maior senha em Versoes(x) menor do que r.
a) V ser ento o valor de x usado no processamento de R(X).
b) r ser inserida em R_seq(x) na posio correta.
2) Suponha que a ao uma atualizao W(X) com senha w. Para cada x X, seja t(x) a
menor senha em Versoes(x) maior do que s.
a) se existe algum x X e existe alguma senha r em R_seq(x) tal que w < r t(x), ento
rejeite a atualizao;
b) caso contrrio, processe a atualizao, criando um novo par (w,V) em Versoes(x),
onde V o valor de x dado por W(X), para cada x X.
Como este protocolo mais sofisticado, convm dar um exemplo. Para efeitos do exemplo
conveniente imaginar que a senha dada a uma transao represente o instante em que foi
submetida. Considere um banco de dados com apenas um objeto fsico x. Suponha que em
um dado momento R_seq(x) e Versoes(x) sejam:
R_seq(x) = (5,8,15,...,92)
Versoes(x) = ((4,V
1
), (10,V
2
), (20,V
3
), ... , (100,V
20
))
- 29 -
Suponha que o protocolo receba uma ao de leitura R(x) com senha r=12. Como temos que
10 < r < 20, o valor lido de x ser V
2
. Ou seja, apesar da ao ter chegada bastante "atrasada"
(a verso corrente de x foi criada por uma transao com senha 100), possvel encaixar a
ao na ordem correta, fornecendo-lhe a verso corrente no instante em que foi submetida. A
senha r=12 inserida em R_seq(x) criando-se R_seq(x) = (5,8,12,15,...,92).
Suponha agora que o protocolo receba uma ao de atualizao W(x) com senha w=7. Esta
ao ter que ser rejeitada pela seguinte razo. Observe R_seq(x) e Versoes(x). Uma leitura
R(Y) com senha r=8 j foi processada (segundo elemento de R_seq(x)) e leu a verso V
1
criada por uma ao com senha 4 (primeiro elemento da seqncia Versoes(x)). Se o
protocolo aceitasse a ao W(x) estaria criando uma nova verso V
1
' com senha 7, que deveria
ento ter sido lida por R(Y). Ou seja, a ao W(X) seria processada depois de R(Y), quando
deveria ter sido processada antes. Logo, W(x) tem que ser rejeitada. Este fato pode ser
detetado pesquisando-se a menor senha em Versoes(x), t=10 neste caso, maior do que w=7.
Como h alguma senha em R_seq(x) entre s=7 e t=10, r=8 neste caso, W(x) ter que ser
rejeitada.
Esta implementao tem a propriedade interessante de nunca rejeitar aes de leitura e
diminuir a rejeio de aes de atualizao. Em outras palavras, o volume de transaes
reiniciadas nesta implementao necessariamente menor que o da implementao bsica.
Por outro lado, a memria adicional necessria a torna proibitiva: manter todas as verses de
todos os objetos no possvel nem razovel para um banco de dados. Uma forma de tornar
esta implementao atraente seria manter as ltimas verses criadas dentro de um esquema
semelhante quele sugerido na implementao bsica. Haveria uma tabela de verses (e de
senhas de operacoes de leitura) mantendo um certo nmero de verses recentes, alm do
prprio banco de dados armazenando a ltima verso de cada objeto. Quando a tabela ficar
completamente ocupada, espao obtido expurgando-se a entrada mais antiga. Assim, a um
custo adicional de memria razovel, poder-se-ia diminuir o volume de transaes
reiniciadas, com benefcio positivo para o sistema.
Por fim, lembramos que os problemas de terminao e relacionamento com o protocolo
bifsico persistem nesta implementao, sendo resolvidos da mesma forma que antes.
8.6 COMPARAO ENTRE OS MTODOS
Nas sees anteriores, dois mtodos bsicos de controle de concorrncia e vrias
implementaes foram discutidas. Esta seo rene comentrios indicando em que situaes
uma ou outra implementao se torna mais adequada.
A Tabela 8.1 resume as principais caractersticas das implementaes dos protocolos de
bloqueio em duas fases e de pr-ordenao, considerando apenas bancos de dados
distribudos.
extremamente difcil comparar efetivamente a performance das vrias implementaes
sugeridas neste captulo. Por outro lado, pode-se adiantar alguns comentrios que, embora
simples, ajudam a avaliar as diversas alternativas.
- 30 -
Tabela 8.1 - Resumo das Caractersticas dos Mtodos de Controle de Concorrncia
Caractersticas
Implementao
Estrutura de
Dados
Mensagens
Adicionais
Existncia de
cpias
Problemas
Terminao
Bsica
tabela de
bloqueios
distribuda
no so
necessrias
no reconhece bloqueios mtuos
difceis de
detectar
Cpias
Primrias
tabela de
bloqueios para
cpias primrias
para bloquear
cpias
primrias
reconhece bloqueios mtuos
difceis de
detectar
Bloqueio
Centralizada
tabela de
bloqueios
centralizada
para bloquear
em um n
coordenador
no reconhece bloqueios mtuos
fceis de
detectar
Bsica
listas de
senhas
no so
necessrias
no reconhece reincio cclico e
mtuo,
de fcil soluo
Conservativa
filas de
subcomandos
para evitar
bloqueios
eternos
no reconhece bloqueios eternos
Pr-
Ordenao
Verses
Mltiplas
listas de
senhas e
verses
no so
necessrias
no reconhece reincio cclico
e mtuo,
de fcil soluo
Inicialmente, convm lembrar que a performance de um mecanismo de controle de
concorrncia pode ser avaliada atravs de vrias medidas diferentes, das quais o tempo de
resposta das transaes ser aqui utilizado. O tempo de resposta das transaes influenciado
por parmetros intrnsicos populao de transaes - taxa mdia de chegada, nmero de
objetos acessados para leitura e atualizao, taxa mdia de servio de processamento e de
servio de entrada/sada - e por parmetros do prprio sistema - nmero de objetos do banco
de dados, alocao dos objetos nos bancos locais, grau de multiprogramao, topologia do
sistema, etc. No que concerne especificamente a mecanismos de controle de concorrncia, os
seguintes parmetros tornam-se importantes:
custo adicional de comunicao, que pode ser estimado pelo nmero mdio de mensagens
passadas apenas para fins de controle de concorrncia;
custo adicional de processamento local, que pode ser medido pelo tempo mdio de
processamento gasto apenas em controle de concorrncia;
custo adicional de processamento das transaes, estimado pelo tempo mdio que uma
transao passa bloqueada, ou pelo nmero mdio de vezes que a transao
reiniciada;
Usaremos estes trs parmetros como indicativo da adequao de um mecanismo de controle
de concorrncia a dois cenrios extremos:
pessimista: caracterizado por uma elevada percentagem de aes conflitantes
otimista: caracterizado por uma baixa percentagem de aes conflitantes
- 31 -
No muito claro, e no h muitos experimentos disponveis para guiar a intuio, o que
significa "baixa percentagem de aes conflitantes". Um indicador aceito considera como
baixa uma percentagem de aes conflitantes que est abaixo de 5%. Se considerarmos que a
freqncia de conflitos ser muito baixa quando as transao acessam poucos objetos em um
banco de dados de tamanho mdio, este limite ser satisfeito por uma vasta gama de
aplicaes. Por outro lado, uma alta percentagem de conflitos significa algo acima de 10%.
Se a freqncia exceder este limite, o volume de bloqueios mtuos e reincios de transaes
poder ser to elevado que o trabalho til do sistema decair consideravelmente.
Consideremos inicialmente o problema de escolher um mecanismo de controle de
concorrncia para um cenrio pessimista. Dado que a percentagem de conflitos alta, o
objetivo bsico neste caso ser diminuir o custo de resolver conflitos. Como a forma mais
dispendiosa de resolver conflitos reiniciar transaes, deve-se escolher um mecanismo que
minimize o volume de transaes reiniciadas.
Com estas caractersticas temos duas implementaes do protocolo de pr-ordenao, a
implementao conservativa e aquela utilizando verses mltiplas. A implementao
conservativa nunca reinicia transaes, mas gera um volume de mensagens adicionais
substancial e implicitamente bloqueia transaes com freqncia. Se estas caractersticas
forem inaceitveis, pode-se optar pela implementao utilizando verses mltiplas, gastando-
se mais memria em troca. Das implementaes do protocolo de bloqueio em duas fases,
apenas a centralizada poder ser adequada, pois em um cenrio pessimista bloqueios mtuos
sero muito frequentes e a implementao centralizada a nica que permite fcil
deteo/resoluo de bloqueios mtuos.
Para um cenrio otimista, qualquer implementao , em princpio, adequada, exceto a
implementao conservativa do protocolo de pr-ordenao pois fora as operaes a serem
processadas em ordem de senha, quer elas conflitem ou no. A implementao bsica, dentre
as do protocolo de pr-ordenao, a mais indicada neste cenrio. Quanto s implementaes
do protocolo de bloqueio em duas fases, a bsica a que se comporta melhor em termos de
mensagens adicionais, sendo interessante neste cenrio.
Isto conclui a nossa breve comparao entre as diversas implementaes. O leitor interessado
dever consultar as referncias deste captulo para maiores detalhes.
NOTAS BIBLIOGRFICAS
Apresentaremos aqui apenas algumas referncias selecionadas dentre uma vasta literatura.
Este captulo baseia-se na maior parte no tutorial sobre controle de concorrncia de Bernstein
e Goodman [1980,1981], que analisa um grande nmero de algoritmos para controle de
concorrncia. A teoria de serializao abordada em detalhe em Papadimitriou, Bernstein e
Rothnie [1977], Papadimitriou [1979], Bernstein, Shipman e Wong [1979] e Casanova
[1980]. Gray [1978] descreve em bastante detalhe uma implementao do protocolo de
bloqueios para o caso centralizado. Gray et all. [1976] analisa o uso de bloqueio com vrias
granularidades. Ries e Stonebraker [1977,1979] e Ries [1979] analisam o efeito do uso de
objetos com granularidades diferentes sobre o desempenho do mecanismo de bloqueios.
Korth [1982,1983] descreve variaes do mtodo de bloqueio. Thomas [1978,1979] analisa
uma outra tcnica para controlar bloqueio a cpias mltiplas. Eswaran et all. e Klug [1983]
exploram a estratgia de bloqueios a nvel lgico (bloqueios por predicados ou expresses da
lgebra relacional). Fussel et all. [1981], Gligor e Shattuck [1980], Leung e Lay [1979] e
Rypka e Lucido [1979] investigam o problema de bloqueio mtuo em BDDs. O algoritmo
- 32 -
hierrquico para deteo de bloqueios mtuos em BDDs foi primeiramente proposto por
Menasc e Muntz [1979]. Obermack [1980] props uma outra forma interessante para
deteo de bloqueios distribudos, que no foi includa no texto por ser no ser diretamente
compatvel com o modelo de processamento de transaes usado. Mtodos de pr-ordenao
so discutidos em Bernstein e Goodman [1980], Rosenkrantz, Stearns e Lewis [1978] e Le
Lann [1978]. Reed [1979], Stonebraker [1979] e Bernstein e Goodman [1983] analisam
algoritmos baseados em verses mltiplas. O mtodo de controle de concorrncia usado no
SDD-1 bastante interessante, combinando uma pr-anlise das transaes com o algoritmo
conservativo de pr-ordenao. Este mtodo descrito por Bernstein et all.
[1978a,1978b,1980]. Bernstein e Shipman [1980] provam a correo deste mtodo. Anlises
comparativas do desempenho de alguns algoritmos de controle de concorrncia podem ser
encontradas em Molina [1978], Menasc e Nakanishi [1979] e Nakanishi [1981].
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 inter-
relacionados. 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.
Figura 9.1 - Transaes Executando
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 T
4
e T
5
estariam incompletas no instante da falha.
Digamos que T
2
e T
6
hajam cancelado enquanto que as demais, T
1
, T
3
e T
7
tenham confirmado.
Neste exemplo, T
3
e T
6
no poderiam estar modificando o valor de um mesmo objeto. O mesmo
pode ser dito quanto a T
1
e T
7
, e assim por diante. J T
1
, T
3
e T
5
poderiam ter sido executadas
envolvendo modificaes sobre o valor de um mesmo objeto.
Tempo
incio falha
T1
T2
T3
T4
T7 T6 T5
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 T
1
, T
2
e T
3
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 T
2
foram enxertadas entre as aes de T
1
, 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 O
1
e O
2
. Tomadas
separadamente, as seqncias relativas a O
1
e O
2
apresentam os blocos completos que
desejamos. As setas 1 e 2 indicam um intervalo de tempo quando a transao T
1
estava
certamente ativa. A seta 3, porm, indica que T
2
modificou o objeto O
1
, tambm modificado por
T
1
, antes que T
1
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.
Tempo
O2 + + + + + + + x x x
O1 + + + + + o o o o o (c)
O + + o o o o o + + x x x x x (b)
O + + + + o o o o o x x x x x (a)
1 2
3
+ = aes elementares de T1
o = aes elementares de T2
x = aes elementares de T3
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.
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
falha
I = Incio
F = Confirmao
C = Cancelamento
CL = Canc. Local
valor inicial
valor final
Legenda:
6
3
1
6
3
6 6
7
LX4
L
7
LX4
L
7
LX4
LX2
G
7
LX4
L
7,L
7
LX5
G
7
LX5
G
7,L
2 2 4 4 7 7 7
VALOR
TA
TC
Desfazendo
VALOR
TA
TC
Refazendo
6
3
1
6
3
6 6 6
4,L
7,L
4,L
7,L
2 2 4 4 7 7
Tempo
I
1
2
F I
2
3
C I
2
4
F I
4
5
CL I
4
6
CL
C I
4
7
F I
7
8
T7 T6 T5 T4 T3 T2 T1
LOG
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.
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.
Tempo
I C
falha
Y
ATA (C)
I = Incio
F = Confirmao
C = Cancelamento
CL = Canc. Local
valor inicial
valor final
Legenda:
Tempo
I
falha
Y
ATA (B)
Tempo
I F
falha
Y
ATA (A)
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 TRMINO
CONFIRMAO CANCELAMENTO
CANC_LOCAL EXECUO
LIDA 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
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:
Tempo
I
F
T9
canc pronto-sim
T8
canc coletando canc-local
11
5 9 13 15
T7
pronto-sim ativo
1
7 12
T6
canc-local
T5
canc canc-local
pronto-no
4
T4
confirmao coletando confirmando
2 6 10 14
T3
8
T2
canc-local
3
T1
TA = { (T
1
, I ) , ( T
2
, I ) , (T
5
, L ) , ( T
6
, L ) }
TC = { T
9
}
TR = {T
5
, T
9
}
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 T
7
e T
4
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 = { (T
1
, I ) , (T
2
, I ) , (T
5
, L ) , (T
6
, L ) , ( T
7
, I ), (T
4
, I ) }
TC = { T
9
}
TR = { T
5
, T
9
}
Note que, neste ponto da ata, T
4
e T
7
so classificadas como transaes incompletas. Este fato
refletido na ao de coloc-las em TA. Em seguida, T
2
cancela localmente. Forosamente, deve
estar em TA. Em conseqncia, sua marca mudada para "local". O prximo evento indica que
T
5
cancela globalmente. Portanto estava em TR e ainda em TA ou TC. Basta retirar T
5
de TR e
tambm de TC, se l estiver. Em adio, T
5
deve ser colocada em TA. Se T
5
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 = { ( T
1
, I ) , (T
2
, L ) , (T
5
, G ) , (T
6
, L ) , (T
7
, I ) , (T
4
, I ) }
TC = { T
9
}
TR = { T
9
}
Na marca do ponto 5, T
8
colocada em TA, marcada como "incompleta". Nos pontos 6 e 7, T
4
e
T
7
so inseridas em TR, uma vez que l no se encontravam. No ponto 8, T
3
acrescentada a lista
TA como "incompleta". Agora as listas seriam na forma:
TA = { ( T
1
, I ) , (T
2
, L ) , (T
5
, G ) , (T
6
, L ) , (T
7
, I ) , (T
4
, I ) , (T
3
, I ) , (T
8
, I ) }
TC = { T
9
}
TR = { T
9
, T
4
, T
7
}
No ponto 9, T
8
inserida em TR. O registro no ponto 10 indica que o estado de retorno de T
4
deve ser alterado em TR. Mais ainda, T
4
deve agora ir para a lista TC. No ponto 11, T
9

eliminada de TC e de TR, sendo colocada em TA como "global". Neste momento, teramos :
TA={( T
1
, I ) , (T
2
, L ) , (T
5
, G ) , (T
6
, L ) , (T
7
, I ) , (T
4
, I ) , (T
3
, I ) , (T
8
, I ) , (T
9
,G )}
TC = { T
4
}
TR = { T
9
, T
4
, T
7
, T
8
}
Confiamos que o leitor possa efetuar as mudanas indicadas pelos pontos 12, 13, 14 e 15,
obtendo o resultado final:
TA = { (T
1
, I ) , (T
2
, L ) , (T
5
, G ) , (T
6
, L ) , (T
3
, I ) , (T
8
, G ) , (T
9
, G ) }
TC = { T
4
, T
7
}
TR = { T
7
}
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 T
1
e T
8
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 Z
1
a Z
7
representam os registros da ata que modificaram valores de objetos em P. O
registro R
1
indica o incio da transao T. A cadeia de ponteiros ligando os registros Z
i
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 Z
1
e Z
7
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 Z
i
's.
Figura 9.6 - Desfazendo Aes de uma Transao Incompleta
O valor inicial do ponteiro de ata de P aponta para Z
4
. Isto significa que o gerente de paginao
elegeu por reescrever P na memria secundria entre os instantes marcados por Z
4
e Z
3
. Como a
transao no chegou a completar, os efeitos de Z
1
a Z
3
foram automaticamente desfeitos quando
o contedo da memria principal foi perdido. Os efeitos de Z
4
a Z
7
, 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 Z
1
, comparamos o valor do endereo
deste registro com o ponteiro da ata de P e descobrimos que Z
1
est a direita daquele ltimo. Isto
indica que Z
1
s foi lanado na ata aps a ltima vez que P foi reescrita na memria secundria.
Podemos, portanto, ignorar Z
1
uma vez que a ao elementar que descreve j est,
automaticamente, desfeita. Ignorando Z
1
, passamos a analisar os registros entre Z
1
e Z
2
. Estes
dizem respeito a outras pginas, diferentes de P. Aps completarmos suas anlises, chegamos a
Z
2
. O mesmo ritual se repete, sendo Z
2
tambm ignorado. Prosseguindo, alcanamos Z
3
,
ignorando-o. Ao chegarmos a Z
4
, porm, o ponteiro de ata de P indica o prprio Z
4
. Neste caso, o
efeito da ao correspondente a Z
4
desfeito.
Em seguida, o ponteiro de ata de P modificado para Z
5
, o prximo registro que alterou valores
em P, indicado pelo ponteiro de pgina do registro em Z
4
. Isto indicado pela seta na posio 2
na Figura 9.6. Aps processar os registros entre Z
4
e Z
5
, chegamos a este ltimo. Os mesmos
passos seriam repetidos, desfazendo-se os efeitos da ao correspondente a Z
5
e colocando-se o
ponteiro de P a apontar para Z
6
. Este ltimo, e em seguida Z
7
, sofreriam sorte igual, tendo os
efeitos das respectivas aes elementares tambm removidos. Finalmente, quando alcanamos o
ponto R
1
, 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.
Tempo
R1 Z7 Z6 Z5 Z4 Z3 Z2 Z1
falha
I
ATA
incio
P
4 3 2 1
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 Z
4
, Z
5
e Z
6
,
desfazendo apenas os efeitos relativos a ao de Z
7
. 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 R
2
e podem
haver, tambm, outros registros que manipulam objetos de P direita de R
2
. 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:
Tempo
R1 Z7 Z6 Z5 Z4 Z3 Z2 Z1 R2 ATA
incio
P
cancelamento
falha
I
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 Z
4
e Z
3
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 Z
3
e Z
4
, 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, Z
1
a Z
3
caracterizariam modificaes referentes a uma transao que foi cancelada e
que no foram tornadas permanentes em memria secundria. Podem, portanto, ser ignoradas. J
Z
4
a Z
7
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 Z
1
a Z
3
foi efetuado em memria principal, sendo, portanto, desperdiado. De qualquer
forma, os efeitos dos registros correspondentes de Z
4
at Z
7
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.
Tempo
B R1 Z7 Z6 Z5 Z4 Z3 Z2 Z1 R2 A ATA
incio
P
cancelamento
falha
I
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 Z
4
e Z
3
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
Tempo
R1 Z4 Z3 L Z2 Z1 R2 ATA
incio cancelamento lida
min I falha
L. Assim procedendo, o registro R
2
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 R
1
, 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 Z
4
e Z
3
.
Assim, os efeitos de Z
3
a Z
1
foram perdidos e devem ser recuperados. J os efeitos de Z
7
a Z
4
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 Z
6
a Z
4
. O primeiro
registro que encontraremos e que no pode ser ignorado Z
3
. 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 Z
4
. 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, Z
3
no caso. Isto
indicado na figura pela seta nmero 2. Prosseguindo, leramos os registros entre Z
3
e Z
4
tomando
as medidas cabveis em cada caso. Quando chegssemos a Z
2
, a situao anterior se repetiria. Os
efeitos da ao indicada em Z
2
seriam refeitos e o ponteiro de pgina de P passaria a indicar Z
2
.
Em seguida, viria Z
1
e, finalmente, atingiramos R
2
quando registros desta transao deixariam de
aparecer na ata. Neste ponto, as aes elementares de T teriam sido reinstaladas no BD.
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
Tempo
R1 Z7 Z6 Z5 Z4 Z3 Z2 Z1 R2 ATA
incio
P
confirmao
falha L
1 2 3 4
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: lista com a identidade de todas as transaes que j haviam iniciado o protocolo bifsico,
junto com o respectivo estado de retorno;
PG: 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 S
1
,..., S
M
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 S
i
S, torna S
i
disponvel para T.
FECHE(S,T)
Para cada S
i
S, assegura que todas as pginas de S
i
que esto na memria principal e
que foram modificadas por T so gravadas na memria secundria, e torna S
i
no
disponvel para T.
Figura 9.11 - Mapeamento entre pginas e setores
LEIA(S
i
,j,F,T)
L a pgina j do segmento S
i
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(S
i
,j,k,T)
Regrava a pgina j do segmento S
i
, 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:
V
i
vetor de ponteiros para o segmento S
i
, de comprimento igual ao nmero de pginas por
segmento, tal que V
i
(j) contm o endereo do setor que mantm a pgina j de S
i
, ou V
i
(j)=
0 se a pgina no est alocada. V
i
est dividido em blocos de tamanho fixo para facilitar a
sua gerncia. Reside na memria secundria e partilhado por todas as operaes.
1 1 1 0 0 1
2 0 1 0
1 2 3 N
L 0 3 0
1 2 3 N
1 2 3 S L
memria
secundria
SETORES
memria
principal
Vi Vj
MAP
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 V
i
.
As operaes bsicas sero ento implementadas da seguinte forma:
ABRA(S,T)
Para cada S
i
S, localize onde esto armazenados os blocos de S
i
.
LEIA(S
i
,j,F,T)
Leia o bloco de V
i
contendo V
i
(j), se j no estiver na memria principal. Obtenha uma
rea de trabalho disponvel k. Se V
i
(j) 0, leia o setor apontado por V
i
(j) para a rea k,
retornando o endereo de k. Se V
i
(j) = 0, a pgina no est alocada; neste caso apenas
retorne o endereo de k.
GRAVE(S
i
,j,k,T)
Leia o bloco de V
i
contendo V
i
(j), se j no estiver na memria principal. Se a pgina j
no estava alocada, ou seja, se V
i
(j) = 0, pesquise em MAP um setor livre s, e faa
MAP(s)=1 e V
i
(j) = s. Caso contrrio, o setor s o prprio valor de V
i
(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 S
i
S, regrave na memria secundria os blocos e pginas de S
i
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(S
i
,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 S
i
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]=(d
0
,r
0
) e D(1)[j]=(d
1
,r
1
) as j-simas entradas de D(0) e D(1),
respectivamente.
b) se d
0
> 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 d
0
= C e d
1
< 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 D
1
,...,D
n
sejam sempre mantidas
coerentes. Para tal, basta introduzir um vetor (C
1
,..., C
n
), tal que C
i
faz o papel de C para a
estrutura D
i
. 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: do incio at atingir a primeira fase do protocolo bifsico.
Estgio 1: 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:
V
i
vetor definido de forma semelhante implementao bsica. Reside na memria
secundria e tal que
V
i
(j) = (0,0) se a pgina j nunca foi alocada; ou
V
i
(j) = (s,t) se s o setor que contm a imagem da pgina j criada por ltimo,
e t a senha da transao que criou esta imagem.
VC
i
vetor duplexando V
i
. Reside na memria secundria.
MAP definido de forma idntica implementao bsica. Reside na memria principal.
L
i
lista de setores ocupados por pginas de S
i
que devero ser liberados quando S
i
for
fechado. Reside na memria principal. (No caso de execuo concorrente, discutido no
final da seo, existir uma encarnao de L
i
para cada transao T que usar S
i
).
B
i
lista de blocos de V
i
que foram alterados pela transao. Reside na memria principal.
(No caso de execuo concorrente, discutido no final da seo, existir uma encarnao
de B
i
para cada transao T que usar S
i
).
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 senha da ltima transao que terminou corretamente.
D D=1 indica que a transao corrente j passou pela primeira fase do protocolo
bifsico mas ainda no terminou, e
D=0 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 V
i
(j) = (s,t) e que VC
i
(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 VC
i
(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 V
i
(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 S
i

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 S
i
, seja V
i
(j) = (s,t) e VC
i
(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 S
i
S, localize onde esto armazenados os blocos de V
i
. Inicie uma lista L
i
para
T como vazia.
LEIA(S
i
,j,F,T)
A implementao desta operao no alterada. Ou seja, as transaes sempre lem do
estado transiente.
Figura 9.12 - Estruturas aps GRAVE(S
i
,j,k,T)
GRAVE(S
i
,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 V
i
contendo a pgina j para a memria principal, se l j no
estiver. Suponha inicialmente que V
i
(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 V
i
(j) = (s',d).
Devemos observar neste ponto que cada bloco de V
i
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 B
i
da transao que os alterou at
que T termine.
1 1 1 1 1 0 0 1
2 0 1 0
1 2 3 N
L 0 5 0
1 2 3 N
1 2 3 S L
memria
secundria
SETORES
memria
principal
VCi
VCj
MAP
4 0 1 0 L 0 5 0
Vi Vj
4 5
3 0 CONTROLE
C D
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 L
i
da transao T para ser liberado quando T terminar.
O vetor VC
i
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(S
i
,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 V
i
(1) = (4,3). O segundo argumento de
V
i
(j) no mostrado explicitamente. Note que VC
i
(j) permanece inalterado pois aponta para a
imagem certificada de j. O setor 2 acrescentado lista L
i
(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 V
i
que se encontram ainda na memria principal. Estes blocos so
tambm acrescentados a B
i
.
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 V
i
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 V
i
atualizados, que se encontram na lista B
i
, so tambm gravados em VC
i
. Desta forma, V
i
e
VC
i
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 L
i
.
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 V
i
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 S
i
e que
V
i
(j) = VC
i
(j) = (s,t). Seja d a senha da transao T corrente.
1) T cria uma imagem transiente para j no setor s', fazendo V
i
(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 S
l
.
3) Uma falha primria ocorre antes da transao terminar.
4) O sistema recuperado para o ltimo estado certificado. Como V
i
(j) = (s',d) e d > C, faz-se
V
i
(j) := VC
i
(j).
5) Porm, VC
i
(j) = (s,t) indica que o setor s contm a imagem certificada da pgina j do
segmento S
i
, o que no verdade, pois ele contm a imagem transiente da pgina k de S
l
.
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 VC
i
mantm ponteiros para as imagens certificadas das pginas
modificadas por T.
Seja d a senha de T. Para cada bloco b de V
i
na lista B
i
de T e para cada pgina j de S
i
no
intervalo correspondente a b, se V
i
(j) = (s,d), ento libere s fazendo MAP(s)=0 e copie
VC
i
(j) para V
i
(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 VC
i
. Eis porque VC
i
(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 VC
i
, no segundo caso.
Para cada pgina j de cada segmento S
i
, seja V
i
(j) = (s,d):
Caso 1.1: Suponha que d C.
Faa V
i
(j) := VC
i
(j)
Caso 1.2: Suponha que d = C.
Faa VC
i
(j) := V
i
(j)
Para recuperar MAP, proceda da seguinte forma. Inicialmente, zere MAP; em
seguida percorra todos os vetores V
i
, para cada pgina j de S
i
e, se V
i
(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 V
i
e VC
i
e, para cada pgina j de S
i
, se V
i
(j) = (s,t) ou
VC
i
(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 V
i
(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 VC
i
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 (como anteriormente).
D (como anteriormente).
E senha da ltima transao que terminou antes do incio da ltima descarga
dinmica.
DATIVA DATIVA=1 indica que uma descarga est em progresso,
DATIVA=0 indica o contrrio.
COPIANDO vetor de comprimento igual ao nmero de setores, em memria principal, tal que
COPIANDO(s)=1 se s contm uma imagem certificada sem cpia que est
sendo copiada.
COPIANDO(s)=0 em caso contrrio.
LA 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
VC
i
para um novo vetor VD
i
, para cada segmento S
i
. Os vetores VD
i
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 VD
i
, para cada segmento S
i
, fazendo COPIANDO(s)=1 para
cada setor s que contm uma imagem certificada sem cpia (ou seja, tal que VD
i
(j) = (s,t)
e t > E para alguma pgina j de S
i
). 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 VD
i
, se VD
i
(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 L
i
, 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 S
i
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 (V
i
, VC
i
, etc.).
2) Associar os objetos aos segmentos.
3) Associar os objetos a intervalos de pginas [ j
i
, k
i
] tais que o i-simo bloco de V
i
contm os
valores de V
i
(j), para j [ j
i
,k
i
]
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 V
i
.
Em linhas gerais, a implementao do bloqueio em duas fases a seguinte:
1) Imediatamente antes de uma operao LEIA(S
i
,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 no executa bloqueios.
LEIA bloqueia o intervalo cobrindo a pgina a ser lida para a transao.
GRAVE no executa bloqueios (LEIA j bloqueou os intervalos necessrios).
FECHE libera os intervalos mantidos bloqueados.
SALVE mantm os intervalos bloqueados.
RESTAURE libera os intervalos mantidos bloqueados (supe-se que aps esta operao
a transao reiniciada)
CPIA 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 VC
i
(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 V
i
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].