Introdução Bases de Dados Distribuídas

Introdução
Devido ao ambiente de grande competitividade em que as organizações de hoje têm
que actuar, estas são forçadas a distribuir-se geograficamente, procurando as
condições locais mais favoráveis à produção e/ou exploração do seu negócio.
Por essa razão, é hoje vulgar o caso de organizações cujas instalações se encontram
dispersas por vários pontos geográficos, dispondo cada um destes de bases de dados e
meios de processamento próprios. Contudo, apesar da relativa autonomia dessas
bases de dados locais, é normal haver a necessidade de manter uma perspectiva
integrada dos dados da organização.
Ou seja, os dados apesar de «fisicamente distribuídos» deverão estar «logicamente
integrados». Essa é a justificação principal para as bases de dados distribuídas.
Bases de Dados Distribuídas
Um sistema de bases de dados distribuídas consiste em múltiplos servidores, cada
um responsável pelos seus dados. Estes dados podem ser acedidos utilizando uma rede
e, apesar de estarem fisicamente distribuídos, devem apresentar-se ao utilizador
logicamente integrados, como se estivessem num único servidor.
Uma base de dados distribuída surge ao utilizador como se fosse uma
única base de dados, mas na realidade é constituída por várias bases
de dados distribuídas por diversos servidores.
A principal razão para utilizar bases de dados distribuídas é o facto do problema
em análise ter uma natureza distribuída. Por exemplo, no caso de uma organização que
tenha a sua sede em Coimbra e uma fábrica A em Braga, um armazém B em Aveiro e
uma fábrica C em Évora, pode fazer sentido utilizar uma base de dados distribuída, pois
espelha a estrutura da organização.
Mas, às vezes, não faz sentido ter um servidor em vários locais. Por exemplo, se
uma empresa tem sede na alta de Coimbra e 3 lojas na baixa, não faz sentido ter um
servidor em cada local. Nesta situação, talvez seja mais adequada uma solução
cliente/servidor. Portanto, se o problema não tiver uma natureza distribuída, não
devemos utilizar uma base de dados distribuída.
Cada Servidor que participa na base de dados distribuída tem uma autonomia
local, ou seja, é administrado (contas, segurança, ...) separada e independentemente dos
outros servidores. Esta autonomia local tem várias vantagens:
• Os nodos dos sistemas podem espelhar mais facilmente a estrutura lógica das
organizações onde se inserem;
• Os dados locais são controlados por um administrador local, pelo que o domínio de
administração é menor e mais manejável;
• A recuperação de falhas pode, em muitos casos, ser efectuada numa base
estritamente local;
• Os nodos do sistema podem ter a dimensão mais adequada a cada problema local e
crescer independentemente.
Bases de Dados Distribuídas Oracle
Resolução de nomes
Antes de verificarmos como as vistas e os sinónimos permitem obter transparência na
localização de objectos numa base de dados ORACLE distribuída, vamos fazer uma
pequena abordagem sobre a resolução de nomes deste sistema.
Cada objecto (ex: Tabela) de qualquer esquema existente na base de
dados distribuída tem de ter um nome unívoco.
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 dicionário local só contém nomes dos objectos locais.
Para os nomes globais, cada base de dados local que participa na base de dados
distribuída tem um nome global unívoco (nome da base de dados + domínio da rede
que contém a base de dados). No ORACLE, este mecanismo não é automático. É
usual ser o DBA a pessoa responsável por dar os nomes às bases de dados.
SELECT * FROM [email protected];
esquema
objecto
Base de dados
domínio
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 atribuídos nomes globais únicos de bases de dados.
2
Bases de Dados Distribuídas Oracle
Comandos Remotos e Distribuídos
•
Interrogação remota
o Selecciona (Select) informação de uma ou mais tabelas todas residentes no
mesmo nó remoto.
•
Actualização remota
o Modifica dados numa ou mais tabelas todas residentes no mesmo nó remoto.
•
Interrogação distribuída
o Selecciona informação de dois ou mais nós da BDD.
•
Actualização distribuída
o Modifica dados em dois ou mais nós da BDD.
Transacções Remotas e Distribuídas
•
Transacção remota
o Contém um ou mais comandos remotos, todos referenciando o mesmo nó.
•
Transacção distribuída
o Inclui comandos que acedem a dados em dois ou mais nós distintos.
Transacções Distribuídas
Uma transacção distribuída termina com commit em todos os servidores que
participam na transacção, ou então termina com rollback em todos os servidores;
O mecanismo/protocolo mais conhecido para garantir a execução de transacções
distribuídas é o two-phase-commit.
Transparência numa base de dados distribuída
•
Na localização física de objectos;
•
Nas interrogações e actualizações distribuídas;
•
Nas transacções distribuídas;
•
Na replicação de objectos;
3
Bases de Dados Distribuídas Oracle
Transparência na localização de objectos
Apesar de, num sistema de bases de dados distribuídas, os dados se encontrarem
dispersos, pretende-se que, ao nível dos utilizadores do sistema e das aplicações, 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 transparência na localização de objectos pode ser conseguida
através da utilização de vistas locais e de sinónimos.
Vistas (Locais) e transparência na localização de objectos
As vistas locais podem fornecer transparência na localização para tabelas locais e
remotas, num sistema distribuído. 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 localização e o relacionamento destas tabelas transparente para os utilizadores do
sistema, podemos criar uma vista na base de dados local, que faça a junção das duas
tabelas:
CREATE VIEW Universidade AS
SELECT
A.numalu, A.nomealu, B.nomedep
FROM
Arnaldo.ALUNOS A, [email protected] B
WHERE
A.numdept = B.numdept;
Quando os utilizadores acedem à vista Universidade, não precisam saber onde é que os
dados estão 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 instrução:
SELECT * FROM Universidade
Devemos, no entanto, ter em conta que se uma das tabelas acima referidas mudasse
de localização, tínhamos que mudar a definição da vista. Contudo, no acesso à vista
tudo continuava a ser transparente.
Podem-se apontar como vantagens da utilização de vistas:
• Simplificação do acesso remoto;
• A localização física dos objectos pode ser alterada sem que isso tenha impacto nos
utilizadores finais ou nas aplicações.
Uma vista é uma tabela lógica que permite aceder aos dados de outras tabelas e/ou de
outras vistas. As vistas podem-se consultar, actualizar (com as limitações já conhecidas)
e apagar como as tabelas.
4
Bases de Dados Distribuídas Oracle
Sinónimos e transparência na localização de objectos
Os sinónimos também podem conferir transparência na localização dos objectos, pois
escondem a identidade dos objectos referidos. Se o objecto referido pelo sinónimo for
mudado para outro local, só é necessário alterar a definição do sinónimo.
Os sinónimos devem ser públicos e têm que ser declarados em todas as bases de dados
locais. Por exemplo, vamos assumir que em todas as bases de dados de um sistema
distribuído é definido um sinónimo público DISCIPLINA para uma tabela DISC
pertencente ao esquema ANTUNES armazenada na base de dados LISB.
CREATE PUBLIC SYNONYM disciplina FOR [email protected];
Se a tabela DISC for mudada da base de dados LISB para a base de dados PORTO, só é
necessário mudar a definição dos sinónimos públicos nas bases de dados do sistema
distribuído. Para os utilizadores, o acesso à informação é transparente.
CREATE PUBLIC SYNONYM disciplina FOR [email protected];
Um sinónimo é um nome alternativo para uma tabela, vista, sequência, procedure,
snapshot ou outro sinónimo.
Transparência nas consultas e actualizações distribuídas
Os comandos DML (Select, Insert, Update, Delete,...) devem poder ser utilizados para
acessos remotos e distribuídos como se fosse para acessos locais.
Exemplos:
INSERT INTO [email protected]
SELECT * FROM emp;
SELECT A.nfunc, A.fnome, B.dnome
FROM [email protected] A, [email protected] B
WHERE A.ndept = B.ndept;
Transparência nas transações distribuídas
As transacções distribuídas são controladas pelos mesmos comandos standard (Commit,
Savepoint, Rollback) das transacções locais, sem necessidade de qualquer outra acção:
• Os comandos numa transacção podem referenciar qualquer número de tabelas locais
ou remotas;
• O SGBD garante que todos os nodos envolvidos na transacção tomam a mesma
acção; ou fazem todos commit ou fazem todos rollback (protocolo Two-PhaseCommit);
• Se houver uma falha na rede durante a transacção distribuída, o sistema deve
garantir que a transacção é resolvida globalmente, sem necessidade de intervenção
explícita.
5
Bases de Dados Distribuídas Oracle
Replicação
Uma das decisões que temos que tomar num sistema de bases de dados distribuídas é
optar por distribuir ou replicar os dados. Esta escolha deve ser principalmente
determinada pela necessidade de ter a informação repetida em vários nodos do
sistema ou se os dados podem estar claramente divididos pelos nodos.
Num ambiente replicado existem vários nodos com as cópias dos mesmos dados.
Manter múltiplas cópias (réplicas) desses dados requer mais recursos do sistema e torna
ainda mais complexa a gestão do mesmo, pois, se há duplicação de dados, é necessário
manter a sua coerência global.
Transparência na replicação de objectos
O SGBD deve ter mecanismos para, de uma maneira transparente, replicar certos
objectos muito críticos.
Manter cópias de uma mesma tabela em vários pontos da base de dados
distribuída pode ter interesse se:
• A tabela é interrogada frequentemente, pelo que uma cópia local melhora a
velocidade;
•
A tabela é modificada muito raramente, pelo que o custo da gestão das réplicas é
baixo;
•
Se uma das cópias falhar, o sistema deverá permitir o acesso a uma réplica da tabela
localizada noutro nó.
O SGBD Oracle tem uma ferramenta gráfica que nos permite administrar o ambiente
replicado a partir de um dado local – Oracle Replication Manager.
Com esta ferramenta, podemos criar grupos de replicação constituídos por tabelas,
vistas, triggers, etc. Podemos fazer “Drag and Drop” de um grupo de replicação para
outras bases de dados, para adicionar novos sítios de replicação ao ambiente. Se
adicionarmos ou eliminarmos objectos de um grupo de replicação, essas alterações são
automaticamente propagadas a todos os sítios. O Replication Manager também pode ser
utilizado na resolução de erros.
6
Bases de Dados Distribuídas Oracle
Gestão de Tabelas replicadas numa Base de Dados Distribuída
•
Actualização síncrona
o Utilizando Triggers para desencadear a actualização (atómica) de todas as
réplicas assim que uma delas é alterada.
Os trigggers podem ser utilizados, como alternativa aos snapshots, para manter cópias
de tabelas em múltiplos nodos de um sistema de bases de dados distribuídas. Cada
réplica pode ser actualizada. As alterações de uma réplica são automática e
imediatamente propagadas às outras réplicas distribuídas.
A replicação de uma tabela se for implementada utilizando triggers, tem as
seguintes características:
• Cada cópia pode ser consultada e actualizada. Todas as actualizações são
propagadas imediatamente a todas as réplicas.
•
As actualizações remotas realizadas pelos triggers são confirmadas (commited) pela
transacção contida no trigger de Actualização, utilizando o protocolo Two-PhaseCommit.
•
Se os triggers estiverem desactivados, as operações de replicação não são efectuadas
até que os triggers fiquem activados de novo.
•
Se ocorrer uma falha na rede entre os nodos que têm réplicas, nem a cópia 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 [email protected] SET
numemp = :new.numemp,
numdept = :new.numdept,
WHERE numemp = :old.numemp;
END;
O trigger acima indicado dispara imediatamente antes de cada actualização feita na
tabela EMP da base de dados local, e vai actualizar a tabela EMP (réplica) da base de
dados LISB.
A replicação síncrona é útil em situações em que temos uma rede estável e
necessitamos que os dados replicados estejam continuamente sincronizados.
7
Bases de Dados Distribuídas Oracle
•
Actualização assíncrona
o Há uma tabela mestre e um número arbitrário de réplicas (snapshots);
o A tabela mestre está num dos nodos e é a única que pode ser actualizada; as
réplicas são só de leitura;
o As réplicas (snapshots) são periodicamente actualizadas, de modo a reflectir
o estado mais recente da tabela mestre.
Esta abordagem tem a desvantagem de não se conseguir espelhar totalmente a tabela
mestre. No caso de esta ser actualizada e antes de ser feita a actualização (periódica) das
réplicas se se fizer uma consulta a essas mesmas réplicas, vêem-se os dados antigos.
Quando se utilizar a propagação assíncrona, deve ter-se em conta o seguinte:
•
As actualizações são propagadas nos intervalos de tempo que forem convenientes.
Para simular uma situação próxima da replicação em tempo real, pode-se utilizar um
intervalo de poucos segundos.
•
As alterações na tabela mestre não são reflectidas imediatamente nas réplicas locais,
resultando numa inconsistência temporária entre as réplicas.
Criar um snapshot é semelhante a criar uma tabela. Pode-se especificar as suas
características de armazenamento (data blocks, extent sizes, parâmetros de
armazenamento, tablespace). Podemos especificar o modo de actualização (rápida ou
completa) e a query distribuída que define o snapshot. Uma actualização rápida requer
um snapshot log e actualiza somente os registos que foram alterados desde a última
actualização. Uma actualização 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 são contidos
no esquema, devem ter um nome único, tendo em conta os outros objectos do esquema.
8
Bases de Dados Distribuídas Oracle
Seleccionar o método de replicação de uma tabela é uma tarefa muito importante.
•
Se a tabela a ser replicada for actualizada bastantes vezes e essas alterações só
necessitarem de ser reflectidas nas outras réplicas periodicamente, então a utilização
de snapshots é a melhor alternativa. Utilizar triggers nesta situação provoca uma
degradação desnecessária da performance.
•
Se as actualizações a uma tabela replicada devem reflectir sempre (continuamente) o
estado corrente da tabela nas outras réplicas, então a replicação síncrona, utilizando
triggers deve ser considerada.
Também podemos escolher um ambiente replicado no qual alguns nodos propagam as
alterações de um modo síncrono enquanto os outros utilizam a propagação assíncrona.
9
Bases de Dados Distribuídas Oracle
Atomicidade nas transacções distribuídas
Problema: Garantir que numa transacção distribuída os nós envolvidos na transacção
ou fazem todos commit ou fazem todos rollback.
Surge Quando: Uma transacção contém 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 não necessita de
participar nas acções que garantem execução atómica da transacção)
Protocolo two-phase-commit
•
Fase de preparação
o O coordenador global (nó que inicia o processo começando a executar o
comando commit) pergunta aos nós que participam na transacção se estão
preparados para terminar a transacção (commit ou rollback).
•
Fase de conclusão (commit phase)
o Se todos os participantes respondem ao coordenador que estão preparados,
então o coordenador manda efectuar o commit;
o Se algum dos participantes diz que não está preparado então o coordenador
manda todos os nós envolvidos efectuar rollback.
Fase de Preparação
Em resposta ao nó coordenador (para preparar o fim da transacção) cada nó participante
pode responder uma de três coisas:
•
•
•
Preparado
o Todos os dados do nó referidos pelos comandos DML da transacção
distribuída já foram modificados e o nó está preparado para terminar a
transacção;
Só de leitura
o Os comandos executados na transacção não alteram dados no nó, pelo que
não é necessária qualquer preparação;
Abortar
o Ocorreu um erro e o nó não está preparado para terminar a transacção com
êxito.
10
Bases de Dados Distribuídas Oracle
Passos na fase de preparação
Depois de ter recebido ordem para se preparar, um nó executa os seguintes passos:
•
Indica aos seus descendentes, se houver, (nós subsequentemente referidos por este
nó) para se prepararem;
•
Reserva todos os recursos necessários para fazer o commit;
•
Efectua uma série de acções, de modo a garantir que os dados bloqueados (os que
foram alterados) vão sobreviver a eventuais falhas;
•
Responde ao nó que lhe ordenou para se preparar, de acordo com o resultado da sua
fase de preparação.
Insucesso na fase de preparação
Quando um nó não se consegue preparar para terminar a transacção com êxito:
•
Efectua rollback da parte local da transacção;
•
Liberta todos os recursos afectos a essa transacção;
•
Responde ao nó que lhe solicitou para se preparar a indicar que abortou a transacção
Estas acções são propagadas aos outros nós envolvidos na transacção
Fase de conclusão (commit phase)
Nesta fase há garantia de que todos os nós envolvidos estão em condições de terminar a
transacção com êxito:
1. Todos os nós recebem a ordem para efectuar commit;
2. Em cada nó o SGBD faz o commit da parte local da transacção e liberta os bloqueios
correspondentes; Regista que a transacção terminou nas estruturas que garantem
tolerância a falhas.
Falhas durante o two-phase-commit
Uma grande variedade de falhas pode ocorrer durante a execução do mecanismo twophase-commit:
•
•
•
Falhas nos nós;
Falhas na rede;
Falhas de software.
O objectivo das técnicas de tolerância a falhas é
garantir que não há perda de dados, qualquer que seja a
falha, mesmo que esta ocorra durante a execução do
mecanismo de two-phase-commit.
11
Bases de Dados Distribuídas Oracle
Conclusão
O processamento distribuído é mais adaptado à estrutura de muitas das organizações
actuais. Proporciona melhor desempenho e maior facilidade de expansão, e aumenta a
disponibilidade do sistema. No entanto, devemos ter em conta que, sob determinadas
condições, o desempenho e a disponibilidade do sistema também podem diminuir. Por
outro lado, tem maior complexidade, tornando-se mais difícil de controlar.
Para se conseguir obter transparência na localização dos objectos, devem-se utilizar
vistas ou sinónimos. Mas quando os dados mudam de local, tem que se alterar quer a
definição das vistas quer dos sinónimos.
Os snapshots são actualizados periodicamente, com as várias actualizações a ocorrerem
numa única operação, permitindo, assim, manter a consistência transaccional entre as
várias cópias da tabela mestre. Alternativamente, a replicação de uma tabela utilizando
triggers implica que, sempre que ocorra uma alteração, se actualizem imediatamente
todas as outras réplicas. Portanto, se ocorrer um número significativo de actualizações,
os snapshots são mais eficientes do que os triggers, porque várias actualizações são
concentradas numa única operação, a qual requer menos tráfego na rede. Por outro lado,
se algum nodo ou a rede forem abaixo quando se estiver a fazer uma actualização, e
estivermos a utilizar triggers, a actualização não pode ser concluída. Adicionalmente, os
snapshots são mais simples de implementar do que os triggers. Assim, podemos
concluir que só se devem utilizar triggers para fazermos a replicação de uma tabela, se a
aplicação requiser as características que os triggers oferecem.
Basicamente, a gestão de tabelas replicadas num sistema de base de dados distribuídas
pode ser feita de duas maneiras:
• Actualização síncrona – Utilizando triggers para desencadear a actualização
(atómica) de todas as réplicas assim que uma delas é alterada.
• Actualização Assíncrona – Há uma tabela mestre e um número arbitrário de réplicas
(snapshots); só a tabela mestre é actualizada; as réplicas são só de leitura; as réplicas
são periodicamente actualizadas de modo a reflectir as últimas alterações na tabela
mestre.
No SGBD Oracle, a atomicidade das transacções é garantida através do protocolo twophase-commit. Este protocolo garante que numa transação distribuída, os nodos
envolvidos ou fazem todos commit ou fazem todos rollback. Se um nodo é referenciado
apenas para leitura, não necessita de participar nas acções que garantem a execução
atómica da transação.
Quando optamos entre uma propagação assíncrona e uma propagação em tempo real
(síncrona), estamos a escolher entre eficácia e complexidade.
Com um ambiente completamente síncrono, temos a vantagem de termos sempre a
informação mais recente em todos os nodos. Portanto, tomamos as decisões baseados na
informação mais recente.
Com um ambiente completamente assíncrono, tem-se a vantagem de ter uma eficácia
contínua, pois nenhum nodo é dependente de outro, para permitir que uma actualização
seja realizada. Se um site for abaixo, pode-se trocar para outro e continuar a trabalhar.
As nossas necessidades irão determinar qual dos métodos de propagação é o mais
apropriado.
12
Bases de Dados Distribuídas Oracle
Bibliografia
•
•
•
•
•
•
•
Abbey, M. and Corey, M., Oracle 8: A Beginner’s Guide, Oracle Press, 1997.
Oracle Corp., Oracle7 Server – SQL Language Reference Manual.
Oracle Corp., Oracle7 Server – Application Developer’s Guide.
Pereira, J. L., Tecnologia de Bases de Dados (2.ª Edição), FCA – Editora de
Informática, 1998. (Capítulo 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
13