Introduo

Devido ao ambiente de grande competitividade em que as organizaes de hoje tm

que actuar, estas so foradas a distribuir-se geograficamente, procurando as
condies locais mais favorveis produo e/ou explorao do seu negcio.

Por essa razo, hoje vulgar o caso de organizaes cujas instalaes se encontram
dispersas por vrios pontos geogrficos, dispondo cada um destes de bases de dados e
meios de processamento prprios. Contudo, apesar da relativa autonomia dessas
bases de dados locais, normal haver a necessidade de manter uma perspectiva
integrada dos dados da organizao.

Ou seja, os dados apesar de fisicamente distribudos devero estar logicamente
integrados. Essa a justificao principal para as bases de dados distribudas.


Bases de Dados Distribudas

Um sistema de bases de dados distribudas consiste em mltiplos servidores, cada
um responsvel pelos seus dados. Estes dados podem ser acedidos utilizando uma rede
e, apesar de estarem fisicamente distribudos, devem apresentar-se ao utilizador
logicamente integrados, como se estivessem num nico servidor.






A principal razo para utilizar bases de dados distribudas o facto do problema
em anlise ter uma natureza distribuda. Por exemplo, no caso de uma organizao que
tenha a sua sede em Coimbra e uma fbrica A em Braga, um armazm B em Aveiro e
uma fbrica C em vora, pode fazer sentido utilizar uma base de dados distribuda, pois
espelha a estrutura da organizao.

Mas, s vezes, no faz sentido ter um servidor em vrios locais. Por exemplo, se
uma empresa tem sede na alta de Coimbra e 3 lojas na baixa, no faz sentido ter um
servidor em cada local. Nesta situao, talvez seja mais adequada uma soluo
cliente/servidor. Portanto, se o problema no tiver uma natureza distribuda, no
devemos utilizar uma base de dados distribuda.

Cada Servidor que participa na base de dados distribuda tem uma autonomia
local, ou seja, administrado (contas, segurana, ...) separada e independentemente dos
outros servidores. Esta autonomia local tem vrias vantagens:
Os nodos dos sistemas podem espelhar mais facilmente a estrutura lgica das
organizaes onde se inserem;
Os dados locais so controlados por um administrador local, pelo que o domnio de
administrao menor e mais manejvel;
A recuperao de falhas pode, em muitos casos, ser efectuada numa base
estritamente local;
Os nodos do sistema podem ter a dimenso mais adequada a cada problema local e
crescer independentemente.
Uma base de dados distribuda surge ao utilizador como se fosse uma
nica base de dados, mas na realidade constituda por vrias bases
de dados distribudas por diversos servidores.
Bases de Dados Distribudas Oracle
2
Resoluo de nomes

Antes de verificarmos como as vistas e os sinnimos permitem obter transparncia na
localizao de objectos numa base de dados ORACLE distribuda, vamos fazer uma
pequena abordagem sobre a resoluo de nomes deste sistema.







Para os nomes de objectos locais: o SGBD garante a unicidade de nomes dentro de
cada esquema; o SGBD garante a unicidade de nomes de esquemas em cada base de
dados local; cada dicionrio local s contm nomes dos objectos locais.


Para os nomes globais, cada base de dados local que participa na base de dados
distribuda tem um nome global unvoco (nome da base de dados + domnio da rede
que contm a base de dados). No ORACLE, este mecanismo no automtico.
usual ser o DBA a pessoa responsvel por dar os nomes s bases de dados.








Como o SGBD ORACLE assegura que o nome de um objecto nico dentro de uma
base de dados, podemos estar certos que ele de facto nico ao longo de todas as bases
de dados, se forem atribudos nomes globais nicos de bases de dados.

SELECT * FROM scott.emp@bdlisb.di.lis.pt;
esquema objecto Base de dados domnio
Cada objecto (ex: Tabela) de qualquer esquema existente na base de
dados distribuda tem de ter um nome unvoco.
Bases de Dados Distribudas Oracle
3
Comandos Remotos e Distribudos

Interrogao remota
o Selecciona (Select) informao de uma ou mais tabelas todas residentes no
mesmo n remoto.
Actualizao remota
o Modifica dados numa ou mais tabelas todas residentes no mesmo n remoto.
Interrogao distribuda
o Selecciona informao de dois ou mais ns da BDD.
Actualizao distribuda
o Modifica dados em dois ou mais ns da BDD.

Transaces Remotas e Distribudas

Transaco remota
o Contm um ou mais comandos remotos, todos referenciando o mesmo n.
Transaco distribuda
o Inclui comandos que acedem a dados em dois ou mais ns distintos.

Transaces Distribudas

Uma transaco distribuda termina com commit em todos os servidores que
participam na transaco, ou ento termina com rollback em todos os servidores;

O mecanismo/protocolo mais conhecido para garantir a execuo de transaces
distribudas o two-phase-commit.

Transparncia numa base de dados distribuda

Na localizao fsica de objectos;
Nas interrogaes e actualizaes distribudas;
Nas transaces distribudas;
Na replicao de objectos;
Bases de Dados Distribudas Oracle
4
Transparncia na localizao de objectos

Apesar de, num sistema de bases de dados distribudas, os dados se encontrarem
dispersos, pretende-se que, ao nvel dos utilizadores do sistema e das aplicaes, se
tenha uma perspectiva integrada dos mesmos.

Assim, um utilizador deve poder referenciar uma mesma tabela sempre da mesma
maneira, independentemente do n a que se liga.

No SGBD ORACLE, a transparncia na localizao de objectos pode ser conseguida
atravs da utilizao de vistas locais e de sinnimos.


Vistas (Locais) e transparncia na localizao de objectos

As vistas locais podem fornecer transparncia na localizao para tabelas locais e
remotas, num sistema distribudo. Por exemplo:

Vamos assumir que a tabela ALUNOS est armazenada na base de dados local e a
tabela DEPT (departamentos) est armazenada numa base de dados remota. Para tornar
a localizao e o relacionamento destas tabelas transparente para os utilizadores do
sistema, podemos criar uma vista na base de dados local, que faa a juno das duas
tabelas:

CREATE VIEW Universidade AS
SELECT A.numalu, A.nomealu, B.nomedep
FROM Arnaldo.ALUNOS A, Anibal.DEPT@bdbib.fct.uc.pt B
WHERE A.numdept = B.numdept;

Quando os utilizadores acedem vista Universidade, no precisam saber onde que os
dados esto fisicamente armazenados nem se os dados foram acedidos a partir de uma
ou mais tabelas. Para visualizar os dados da vista acima criada, podemos utilizar a
seguinte instruo:

SELECT * FROM Universidade

Devemos, no entanto, ter em conta que se uma das tabelas acima referidas mudasse
de localizao, tnhamos que mudar a definio da vista. Contudo, no acesso vista
tudo continuava a ser transparente.

Podem-se apontar como vantagens da utilizao de vistas:
Simplificao do acesso remoto;
A localizao fsica dos objectos pode ser alterada sem que isso tenha impacto nos
utilizadores finais ou nas aplicaes.

Uma vista uma tabela lgica que permite aceder aos dados de outras tabelas e/ou de
outras vistas. As vistas podem-se consultar, actualizar (com as limitaes j conhecidas)
e apagar como as tabelas.
Bases de Dados Distribudas Oracle
5
Sinnimos e transparncia na localizao de objectos

Os sinnimos tambm podem conferir transparncia na localizao dos objectos, pois
escondem a identidade dos objectos referidos. Se o objecto referido pelo sinnimo for
mudado para outro local, s necessrio alterar a definio do sinnimo.

Os sinnimos devem ser pblicos e tm que ser declarados em todas as bases de dados
locais. Por exemplo, vamos assumir que em todas as bases de dados de um sistema
distribudo definido um sinnimo pblico DISCIPLINA para uma tabela DISC
pertencente ao esquema ANTUNES armazenada na base de dados LISB.

CREATE PUBLIC SYNONYM disciplina FOR antunes.disc@lisb.di.ul.pt;

Se a tabela DISC for mudada da base de dados LISB para a base de dados PORTO, s
necessrio mudar a definio dos sinnimos pblicos nas bases de dados do sistema
distribudo. Para os utilizadores, o acesso informao transparente.

CREATE PUBLIC SYNONYM disciplina FOR antunes.disc@porto.di.up.pt;

Um sinnimo um nome alternativo para uma tabela, vista, sequncia, procedure,
snapshot ou outro sinnimo.

Transparncia nas consultas e actualizaes distribudas

Os comandos DML (Select, Insert, Update, Delete,...) devem poder ser utilizados para
acessos remotos e distribudos como se fosse para acessos locais.

Exemplos:

INSERT INTO scott.emp@vendas.cc.pt
SELECT * FROM emp;

SELECT A.nfunc, A.fnome, B.dnome
FROM scott.emp@vendas.cc.pt A, princ.dept@sede.cc.pt B
WHERE A.ndept = B.ndept;


Transparncia nas transaes distribudas

As transaces distribudas so controladas pelos mesmos comandos standard (Commit,
Savepoint, Rollback) das transaces locais, sem necessidade de qualquer outra aco:
Os comandos numa transaco podem referenciar qualquer nmero de tabelas locais
ou remotas;
O SGBD garante que todos os nodos envolvidos na transaco tomam a mesma
aco; ou fazem todos commit ou fazem todos rollback (protocolo Two-Phase-
Commit);
Se houver uma falha na rede durante a transaco distribuda, o sistema deve
garantir que a transaco resolvida globalmente, sem necessidade de interveno
explcita.

Bases de Dados Distribudas Oracle
6
Replicao

Uma das decises que temos que tomar num sistema de bases de dados distribudas
optar por distribuir ou replicar os dados. Esta escolha deve ser principalmente
determinada pela necessidade de ter a informao repetida em vrios nodos do
sistema ou se os dados podem estar claramente divididos pelos nodos.

Num ambiente replicado existem vrios nodos com as cpias dos mesmos dados.
Manter mltiplas cpias (rplicas) desses dados requer mais recursos do sistema e torna
ainda mais complexa a gesto do mesmo, pois, se h duplicao de dados, necessrio
manter a sua coerncia global.


Transparncia na replicao de objectos

O SGBD deve ter mecanismos para, de uma maneira transparente, replicar certos
objectos muito crticos.

Manter cpias de uma mesma tabela em vrios pontos da base de dados
distribuda pode ter interesse se:
A tabela interrogada frequentemente, pelo que uma cpia local melhora a
velocidade;
A tabela modificada muito raramente, pelo que o custo da gesto das rplicas
baixo;
Se uma das cpias falhar, o sistema dever permitir o acesso a uma rplica da tabela
localizada noutro n.

O SGBD Oracle tem uma ferramenta grfica que nos permite administrar o ambiente
replicado a partir de um dado local Oracle Replication Manager.

Com esta ferramenta, podemos criar grupos de replicao constitudos por tabelas,
vistas, triggers, etc. Podemos fazer Drag and Drop de um grupo de replicao para
outras bases de dados, para adicionar novos stios de replicao ao ambiente. Se
adicionarmos ou eliminarmos objectos de um grupo de replicao, essas alteraes so
automaticamente propagadas a todos os stios. O Replication Manager tambm pode ser
utilizado na resoluo de erros.
Bases de Dados Distribudas Oracle
7
Gesto de Tabelas replicadas numa Base de Dados Distribuda

Actualizao sncrona
o Utilizando Triggers para desencadear a actualizao (atmica) de todas as
rplicas assim que uma delas alterada.
Os trigggers podem ser utilizados, como alternativa aos snapshots, para manter cpias
de tabelas em mltiplos nodos de um sistema de bases de dados distribudas. Cada
rplica pode ser actualizada. As alteraes de uma rplica so automtica e
imediatamente propagadas s outras rplicas distribudas.

A replicao de uma tabela se for implementada utilizando triggers, tem as
seguintes caractersticas:
Cada cpia pode ser consultada e actualizada. Todas as actualizaes so
propagadas imediatamente a todas as rplicas.
As actualizaes remotas realizadas pelos triggers so confirmadas (commited) pela
transaco contida no trigger de Actualizao, utilizando o protocolo Two-Phase-
Commit.
Se os triggers estiverem desactivados, as operaes de replicao no so efectuadas
at que os triggers fiquem activados de novo.
Se ocorrer uma falha na rede entre os nodos que tm rplicas, nem a cpia local nem
as remotas podem ser actualizadas at que a falha na rede seja resolvida, limitando,
assim, a performance.

CREATE TRIGGER emp_upd
BEFORE UPDATE ON emp
FOR EACH ROW
BEGIN

UPDATE Anibal.emp@lisb.fc.ul.pt SET
numemp = :new.numemp,
numdept = :new.numdept,
WHERE numemp = :old.numemp;

END;

O trigger acima indicado dispara imediatamente antes de cada actualizao feita na
tabela EMP da base de dados local, e vai actualizar a tabela EMP (rplica) da base de
dados LISB.


A replicao sncrona til em situaes em que temos uma rede estvel e
necessitamos que os dados replicados estejam continuamente sincronizados.

Bases de Dados Distribudas Oracle
8

Actualizao assncrona
o H uma tabela mestre e um nmero arbitrrio de rplicas (snapshots);
o A tabela mestre est num dos nodos e a nica que pode ser actualizada; as
rplicas so s de leitura;
o As rplicas (snapshots) so periodicamente actualizadas, de modo a reflectir
o estado mais recente da tabela mestre.

Esta abordagem tem a desvantagem de no se conseguir espelhar totalmente a tabela
mestre. No caso de esta ser actualizada e antes de ser feita a actualizao (peridica) das
rplicas se se fizer uma consulta a essas mesmas rplicas, vem-se os dados antigos.

Quando se utilizar a propagao assncrona, deve ter-se em conta o seguinte:

As actualizaes so propagadas nos intervalos de tempo que forem convenientes.
Para simular uma situao prxima da replicao em tempo real, pode-se utilizar um
intervalo de poucos segundos.
As alteraes na tabela mestre no so reflectidas imediatamente nas rplicas locais,
resultando numa inconsistncia temporria entre as rplicas.

Criar um snapshot semelhante a criar uma tabela. Pode-se especificar as suas
caractersticas de armazenamento (data blocks, extent sizes, parmetros de
armazenamento, tablespace). Podemos especificar o modo de actualizao (rpida ou
completa) e a query distribuda que define o snapshot. Uma actualizao rpida requer
um snapshot log e actualiza somente os registos que foram alterados desde a ltima
actualizao. Uma actualizao completa regenera por completo o snapshot, a partir da
tabela mestre. No exemplo seguinte, cria-se um snapshot, na base de dados LISB, da
tabela EMP, que est na base de dados PORTO.

CREAT SNAPSHOT emp_lisb
PCTFREE 10 PCTUSED 70
TABLESPACE utilizadores
STORAGE (INITIAL 50K NEXT 50K PCTINCREASE 50)
REFRESH FAST
START WITH sysdate
NEXT sysdate + 7
AS SELECT * FROM emp@porto

Sempre que um snapshot criado, imediatamente carregado com os registos
devolvidos pela query que define o snapshot. A partir desse momento o snapshot
actualizado como especificado pela palavra refresh. Como os snapshots so contidos
no esquema, devem ter um nome nico, tendo em conta os outros objectos do esquema.


Bases de Dados Distribudas Oracle
9

Seleccionar o mtodo de replicao de uma tabela uma tarefa muito importante.

Se a tabela a ser replicada for actualizada bastantes vezes e essas alteraes s
necessitarem de ser reflectidas nas outras rplicas periodicamente, ento a utilizao
de snapshots a melhor alternativa. Utilizar triggers nesta situao provoca uma
degradao desnecessria da performance.

Se as actualizaes a uma tabela replicada devem reflectir sempre (continuamente) o
estado corrente da tabela nas outras rplicas, ento a replicao sncrona, utilizando
triggers deve ser considerada.



Tambm podemos escolher um ambiente replicado no qual alguns nodos propagam as
alteraes de um modo sncrono enquanto os outros utilizam a propagao assncrona.
Bases de Dados Distribudas Oracle
10
Atomicidade nas transaces distribudas

Problema: Garantir que numa transaco distribuda os ns envolvidos na transaco
ou fazem todos commit ou fazem todos rollback.

Surge Quando: Uma transaco contm comandos DML que referenciam objectos
remotos (usando o nome global do objecto) com o objectivo de modificar os dados
neles contidos.

(Se um n remoto referenciado apenas para leitura no necessita de
participar nas aces que garantem execuo atmica da transaco)


Protocolo two-phase-commit

Fase de preparao
o O coordenador global (n que inicia o processo comeando a executar o
comando commit) pergunta aos ns que participam na transaco se esto
preparados para terminar a transaco (commit ou rollback).

Fase de concluso (commit phase)
o Se todos os participantes respondem ao coordenador que esto preparados,
ento o coordenador manda efectuar o commit;

o Se algum dos participantes diz que no est preparado ento o coordenador
manda todos os ns envolvidos efectuar rollback.

Fase de Preparao

Em resposta ao n coordenador (para preparar o fim da transaco) cada n participante
pode responder uma de trs coisas:

Preparado
o Todos os dados do n referidos pelos comandos DML da transaco
distribuda j foram modificados e o n est preparado para terminar a
transaco;
S de leitura
o Os comandos executados na transaco no alteram dados no n, pelo que
no necessria qualquer preparao;
Abortar
o Ocorreu um erro e o n no est preparado para terminar a transaco com
xito.

Bases de Dados Distribudas Oracle
11
Passos na fase de preparao

Depois de ter recebido ordem para se preparar, um n executa os seguintes passos:

Indica aos seus descendentes, se houver, (ns subsequentemente referidos por este
n) para se prepararem;
Reserva todos os recursos necessrios para fazer o commit;
Efectua uma srie de aces, de modo a garantir que os dados bloqueados (os que
foram alterados) vo sobreviver a eventuais falhas;
Responde ao n que lhe ordenou para se preparar, de acordo com o resultado da sua
fase de preparao.

Insucesso na fase de preparao

Quando um n no se consegue preparar para terminar a transaco com xito:

Efectua rollback da parte local da transaco;
Liberta todos os recursos afectos a essa transaco;
Responde ao n que lhe solicitou para se preparar a indicar que abortou a transaco

Estas aces so propagadas aos outros ns envolvidos na transaco

Fase de concluso (commit phase)

Nesta fase h garantia de que todos os ns envolvidos esto em condies de terminar a
transaco com xito:

1. Todos os ns recebem a ordem para efectuar commit;

2. Em cada n o SGBD faz o commit da parte local da transaco e liberta os bloqueios
correspondentes; Regista que a transaco terminou nas estruturas que garantem
tolerncia a falhas.

Falhas durante o two-phase-commit

Uma grande variedade de falhas pode ocorrer durante a execuo do mecanismo two-
phase-commit:

Falhas nos ns;
Falhas na rede;
Falhas de software.


O objectivo das tcnicas de tolerncia a falhas
garantir que no h perda de dados, qualquer que seja a
falha, mesmo que esta ocorra durante a execuo do
mecanismo de two-phase-commit.
Bases de Dados Distribudas Oracle
12
Concluso

O processamento distribudo mais adaptado estrutura de muitas das organizaes
actuais. Proporciona melhor desempenho e maior facilidade de expanso, e aumenta a
disponibilidade do sistema. No entanto, devemos ter em conta que, sob determinadas
condies, o desempenho e a disponibilidade do sistema tambm podem diminuir. Por
outro lado, tem maior complexidade, tornando-se mais difcil de controlar.

Para se conseguir obter transparncia na localizao dos objectos, devem-se utilizar
vistas ou sinnimos. Mas quando os dados mudam de local, tem que se alterar quer a
definio das vistas quer dos sinnimos.

Os snapshots so actualizados periodicamente, com as vrias actualizaes a ocorrerem
numa nica operao, permitindo, assim, manter a consistncia transaccional entre as
vrias cpias da tabela mestre. Alternativamente, a replicao de uma tabela utilizando
triggers implica que, sempre que ocorra uma alterao, se actualizem imediatamente
todas as outras rplicas. Portanto, se ocorrer um nmero significativo de actualizaes,
os snapshots so mais eficientes do que os triggers, porque vrias actualizaes so
concentradas numa nica operao, a qual requer menos trfego na rede. Por outro lado,
se algum nodo ou a rede forem abaixo quando se estiver a fazer uma actualizao, e
estivermos a utilizar triggers, a actualizao no pode ser concluda. Adicionalmente, os
snapshots so mais simples de implementar do que os triggers. Assim, podemos
concluir que s se devem utilizar triggers para fazermos a replicao de uma tabela, se a
aplicao requiser as caractersticas que os triggers oferecem.

Basicamente, a gesto de tabelas replicadas num sistema de base de dados distribudas
pode ser feita de duas maneiras:
Actualizao sncrona Utilizando triggers para desencadear a actualizao
(atmica) de todas as rplicas assim que uma delas alterada.
Actualizao Assncrona H uma tabela mestre e um nmero arbitrrio de rplicas
(snapshots); s a tabela mestre actualizada; as rplicas so s de leitura; as rplicas
so periodicamente actualizadas de modo a reflectir as ltimas alteraes na tabela
mestre.

No SGBD Oracle, a atomicidade das transaces garantida atravs do protocolo two-
phase-commit. Este protocolo garante que numa transao distribuda, os nodos
envolvidos ou fazem todos commit ou fazem todos rollback. Se um nodo referenciado
apenas para leitura, no necessita de participar nas aces que garantem a execuo
atmica da transao.

Quando optamos entre uma propagao assncrona e uma propagao em tempo real
(sncrona), estamos a escolher entre eficcia e complexidade.
Com um ambiente completamente sncrono, temos a vantagem de termos sempre a
informao mais recente em todos os nodos. Portanto, tomamos as decises baseados na
informao mais recente.
Com um ambiente completamente assncrono, tem-se a vantagem de ter uma eficcia
contnua, pois nenhum nodo dependente de outro, para permitir que uma actualizao
seja realizada. Se um site for abaixo, pode-se trocar para outro e continuar a trabalhar.
As nossas necessidades iro determinar qual dos mtodos de propagao o mais
apropriado.
Bases de Dados Distribudas Oracle
13

Bibliografia
Abbey, M. and Corey, M., Oracle 8: A Beginners Guide, Oracle Press, 1997.
Oracle Corp., Oracle7 Server SQL Language Reference Manual.
Oracle Corp., Oracle7 Server Application Developers Guide.
Pereira, J. L., Tecnologia de Bases de Dados (2. Edio), FCA Editora de
Informtica, 1998. (Captulo 7).
Oracle7 Server Distributed Systems Volume I: Distributed Data
Oracle7 Server Distributed Systems Volume I: Replicated Data
Oracle7 Server Distributed Systems Volume II: Replicated Data