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