manografia replicação em banco de dados distribuídos heterogêneos
DESCRIPTION
Manografia Replicação em banco de dados distribuídos heterogêneosTRANSCRIPT
Ciência da Computação
Replicação em Banco de Dados Distribuídos Heterogên eos
Cleidenilson Santiago da Silva
Salvador-BA
2013
Cleidenilson Santiago da Silva
Replicação em Banco de Dados Distribuídos Heterogên eos
Monografia apresentada ao Curso de
Bacharelado em Ciências da Computação
da Faculdade IBES, como requisito parcial
para obtenção do grau de Bacharel.
Orientador: Prof. Roberto Carlos Sarmento
Barbosa
Salvador-BA
2013
TERMO DE APROVAÇÃO
Cleidenilson Santiago da Silva
Replicação em Banco de Dados Distribuídos Heterogên eos
Monografia aprovada como requisito parcial para obtenção do grau de Bacharel em
Ciências da Computação, pela seguinte banca examinadora:
_________________________________________
Prof. Carlos Roberto Sarmento Barbosa
Orientador
_________________________________________
Prof. Carlos Henrique
Examinador
_________________________________________
Prof. Vicente Cardoso
Examinador
Aprovado em ____/___/_____.
Salvador-BA
2013
AGRADECIMENTOS
Agradeço primeiramente a Deus, por ter me ajudado e me conduzido para
que eu pudesse alcançar essa benção na minha vida.
Ao meu pai Armando Ferreira da Silva que não mediu esforços para me
proporcionar uma vida melhor e que foi um exemplo para mim, sempre batalhador,
dedicado e esforçado.
A minha mãe Cleidenice Santiago que sempre esteve ao meu lado durante o
desenvolvimento desse trabalho nunca deixando eu me desviar dos meus objetivo
essa ajuda muito importante para a conclusão desse trabalho.
Ao meu primo Lídio que investiu e acreditou em mim, ao meu tio Durval por
ter me ajudado e incentivado a minha qualificação, agradeço também ao Bispo Júlio
e a Bispa Lindinalva pela dedicação e atenção.
Ao professor Sarmento por ter me orientado, pela grande contribuição e por
ter me incentivado, essa grande ajuda viabilizou o desenvolvimento desse trabalho.
Aos meus companheiros de sala João Guedes, Thyago Souza, Jorge Luiz,
Rodrigo Franco, Jorge Antônio, Robson Oliveira, Guilherme Matos, Luís Paulo, Cris
e Fernando pelo companheirismo durante esses 4 anos.
A todos os meus professores do curso de ciência da computação pela grande
contribuição na minha vida, que possibilitou a concretização da minha graduação.
RESUMO
Com a crescente demanda de armazenamento e acesso de dados, é necessário o
uso de mecanismos que possam garantir a disponibilidade, segurança e acesso
dessas informações independente da sua localização, a descentralização vem
ganhando espaço a cada dia que passa fortalecendo assim o uso de banco de
dados distribuídos. Em ambientes corporativos é natural as informações estarem
espalhadas em diversas localidades sendo necessária a consolidação de tais dados.
Quando as empresas são incorporadas na maioria das vezes se torna necessário a
replicação das informações para banco de dados de fabricantes distintos,
possibilitando a integração entre sistemas e o reaproveitamento de infra-estrutura
existente, minimizando os custos com equipamentos e manutenções. Neste trabalho
será abordado as questões inerente da replicação de dados, bem como o
desenvolvimento de um ambiente de replicação entre base dados da Oracle e
MySQL, utilizando máquinas virtuais.
Palavras-chave: Disponibilidade; Banco de Dados Distribuídos; Replicação; Oracle;
MySQL
ABSTRACT
With the increasing demand for storing and accessing data, using mechanisms to
ensure the availability, security and access these independently of the location
information is required, decentralization is gaining momentum with each passing day
thus strengthening the use of stock distributed data. In corporate environments is
natural information are scattered in various locations consolidate such data is
necessary. When companies are incorporated in most cases the replication of
information to the database of different manufacturers becomes necessary, enabling
the integration of systems and the reuse of existing infrastructure, minimizing
equipment costs and maintenance. This work will address the inherent issues of data
replication and the development of an environment database replication between
Oracle and MySQL, using virtual machines.
Keywords: Availability; Distributed Database; Replication; Oracle; MySQL
LISTA DE FIGURAS
Figura 1 - Representação Simplificada de um sistema de banco de dados. ............ 11
Figura 2 - Representação do sistema de banco de dados distribuído (SGBDD)....... 16
Figura 3 - Variação de Arquitetura ............................................................................ 20
Figura 4 - Representação do modelo multimestre. .................................................... 34
Figura 5 - Representação do modelo mestre/escravo. .............................................. 35
Figura 6 - Maquina virtual que funcionará como servidor mestre. ............................. 37
Figura 7 - Máquina virtual que funcionará como servidor escravo. ........................... 38
Figura 8 - Diagrama de Entidade de Relacionamento D.E.R .................................... 39
Figura 9 - Representação do Esquema de Replicação ............................................. 41
Figura 10 - Configurando ODBC MySQL .................................................................. 42
Figura 11 - Criando o Arquivo Init .............................................................................. 43
Figura 12 - Reiniciando o Banco de Dados Oracle ................................................... 44
Figura 13 - Inserindo Dados no Banco de Dados da Oracle .................................... 50
Figura 14 - Dados Replicados Para o MySQL........................................................... 51
Figura 15 - Atualizando Dados no Banco de Dados da Oracle ................................. 52
Figura 16 - Dados Atualizados no MySQL ................................................................ 53
Figura 17 - Excluído Um Registro no Banco de Dados da Oracle ............................ 54
Figura 18 - Registro Excluído no MySQL .................................................................. 55
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 10
1.1 Objetivo ............................................................................................................ 10
1.2 Organização do Trabalho ................................................................................. 10
2 SISTEMA DE BANCO DE DADOS ....................... ................................................ 11
2.1 Sistema Gerenciador de Banco de Dados ....................................................... 12
2.2 Vantagens do Banco de Dados ....................................................................... 12
2.3 Linguagem de Banco de Dados ....................................................................... 13
2.4 Modelo de Dados ............................................................................................. 14
2.4.1 Modelo Relacional ..................................................................................... 14
2.4.2 Modelo Entidade/Relacionalmento ............................................................ 15
2.4.3 Modelo Orientado a Objeto ........................................................................ 15
3 SISTEMA DE BANCO DE DADOS DISTRIBUÍDO ........... .................................... 16
3.1 Tipos de Sistema de Banco de Dados Distribuídos ........................................ 17
3.1.1 Bancos de Dados Homogêneo .................................................................. 17
3.1.2 Bancos de Dados Heterogêneos ............................................................... 17
3.2 Vantagens do Banco de Dados Distribuídos .................................................... 18
3.3 Arquitetura ....................................................................................................... 19
3.4 Processamento Distribuido de Consulta .......................................................... 21
3.5 Transparência de Dados .................................................................................. 22
3.5.1 Transparência de Rede ............................................................................. 22
3.5.2 Transparência de Replicação .................................................................... 23
3.5.3 Transparência de Fragmentação ............................................................... 23
3.6 Armazenamento Distribuído dos Dados ........................................................... 23
3.6.1 Replicação de Dados ................................................................................. 24
3.6.2 Fragmentação de Dados ........................................................................... 25
3.6.2.1 Fragmentação Horizontal .................................................................... 25
3.6.2.2 Fragmentação Vertical......................................................................... 26
3.6.2.3 Fragmentação Mista ............................................................................ 26
3.7 Controle de Concorrência ................................................................................ 26
3.7.1 Gerenciamento de Bloqueio Único ............................................................ 26
3.7.2 Gerenciador de bloqueio distribuído .......................................................... 28
3.7.3 Cópia Primária ........................................................................................... 28
3.7.4 Protocolo da Maioria .................................................................................. 28
3.7.5 Protocolo Parcial ........................................................................................ 29
3.7.6 Timestamp ................................................................................................. 30
4 REPLICAÇÃO ...................................... .................................................................. 31
4.1 Estratégias de Replicação ............................................................................... 31
4.1.1 Replicação Síncrona .................................................................................. 31
4.1.2 Replicação Assícrona ................................................................................ 32
4.2 Modelos de Replicação .................................................................................... 33
4.2.1 Modelo Mutimestre .................................................................................... 33
4.2.2 Modelo Mestre/Escravo ............................................................................. 34
4.3 Objetos de Replicação ..................................................................................... 35
4.4 Conflitos de Replicação ................................................................................... 35
5 APLICAÇÃO ....................................... ................................................................... 37
5.1 Criação do Processo de Replicação ................................................................ 40
5.2 Testes .............................................................................................................. 50
5.3 Considerações ................................................................................................. 56
6 CONSIDERAÇÕES FINAIS ............................ ....................................................... 57
REFERÊNCIAS ......................................................................................................... 58
10
1 INTRODUÇÃO
1.1 Objetivo
Este trabalho tem como objetivo demostrar o funcionamento da replicação
entre banco de dados distribuídos heterogêneos, levando em consideração as
vantagens e desvantagem do mesmo, explorando os principais conceitos de banco
de dados e replicação de dados, provando assim que esse recurso pode ser
utilizado em empresas, hospitais, universidades, entre outros.
1.2 Organização do Trabalho
Esse trabalho está organizado da seguinte forma: no capítulo 2 temos uma
abordagem com alguns conceitos importantes de banco de dados, no capítulo 3 são
apresentado os fundamentos de banco de dados distribuídos com uma abordagem
mais detalhada, no capítulo 4 é explorado os tópicos referentes à replicação de
dados assim como os seus modelos e tipos. No capítulo 5 é realizado na prática a
replicação de dados bem como as devidas configurações utilizando os banco de
dados Oracle 10g e o MySQL 5.0.
11
2 SISTEMA DE BANCO DE DADOS
Conforme Date (2003):
Um sistema de banco de dados é basicamente um sistema computadorizado de armazenamento de registros; isto é, um sistema computadorizado cujo propósito geral é armazenar informações e permitir ao usuário buscar e atualizar essas informações quando solicitado (DATE 2003, p.6).
Os sistemas de banco de dados são projetados para gerir grandes volumes de
informações, definir um banco de dados envolve especificar os tipos, estruturas e restrições
dos dados armazenados. A definição ou informação descritiva do banco de dados também é
armazenada pelo SGBD (NAVATHE, 2005).
Na Figura 1 temos uma representação de um sistema de gerenciador de
banco de dados.
Figura 1 - Representação Simplificada de um sistema de banco de dados.
Fonte: (DATE 2003).
Para se definir um banco de dados é necessário especificar os tipos,
estruturas e restrições de dados a ser armazenada, a definição descritiva do banco
12
de dados também é armazenada pelo SGBD na forma de metadados que é também
conhecida como catálogo ou dicionário.
2.1 Sistema Gerenciador de Banco de Dados
Segundo Korth, Silberschatz e Sudarshan (2006) um Sistema Gerenciador de
Banco de Dados (SGBD) é uma coleção de dados inter-relacionados, representando
informações sobre um domínio específico.
O SGBD é um sistema de software de uso geral que facilita o processo de
definição, construção, manipulação e compartilhamento de banco de dados entre
diversos usuários e aplicações.
2.2 Vantagens do Banco de Dados
O banco de dados apresenta uma séria de vantagens levando em
consideração o sistema de arquivos.
Conforme Date (2003) as vantagens de utilizar um sistema de banco de
dados (SGBD) são:
• Densidade - Não há necessidade de arquivos em papel, possivelmente
volumosos e com a possibilidade de perder todas as informações.
• Velocidade - A máquina pode obter e atualizar dados com mais consistência
e rapidez muito maior que o ser humano.
• Menos trabalho monótono - Grande parte do tédio de manter arquivos à
mão é eliminada. As tarefas mecânicas são em geral feitas com melhor
qualidade por máquinas.
• Atualidade - Informações precisas e atualizadas estão disponíveis a qualquer
momento sob consulta.
13
• Proteção - Os dados podem ser mais bem protegidos contra perda não
intencional e acesso ilegal.
2.3 Linguagem de Banco de Dados
Durante o desenvolvimento dos bancos de dados relacionais, foram criadas
linguagens responsáveis pela sua manipulação, conforme Date (2003), SQL é a
linguagem padrão utilizada para interagir com banco de dados relacionais, e
atualmente é aceita pela maioria dos SGBDs disponíveis no mercado. A SQL inclui
operações de definição de dados e operação de manipulação de dados, sendo
composta por vários comandos tais como:
● Linguagem de definição de dados ou DDL (Data Definition Language) é
responsável por permitir aos usuários acessar e manipular a dados, ela pode operar
tanto no nível externo (sobre visões) quanto no nível conceitual (tabelas), e também
oferece alguns recursos para controlar dados. O resultado da compilação dos
parâmetros DDLs são armazenados em um conjunto de tabelas que compõe um
arquivo especial chamado de dicionário de dados ou diretório de dados.
● Linguagem de manipulação de dados ou DML (Data Manipulation Language)
é utilizada para recuperação, inclusão, remoção e modificação de informações de
um banco de dados. As DDLs têm a sua capacidade funcional organizada pela
palavra inicial em uma declaração, que na maioria das vezes é um verbo, temos os
seguintes comandos SQL:
▪ Select - É uma declaração SQL que retorna um conjunto registros de uma ou
mais tabelas. Exemplo: SELECT * FROM alunos
▪ Insert - É uma declaração SQL que inclui um ou mais registros em qualquer
tabela de um banco de dados relacional. Exemplo: INSERT INTO alunos (matricula,
nome) VALUES (José Ferreira, 122346)
▪ Update - É uma instrução que altera os dados de um ou mais registros em uma
tabela. Exemplo: UPDATE alunos Set nome = José Ferreira Silva WHERE matricula
14
=122346
▪ Delete - É uma instrução que remove um ou mais registro de uma tabela, uma
condição deve ser definido a, para evitar que todos os registro sejam removidos.
Exemplo: DELETE FROM alunos WHERE matricula =122346
Segundo Korth, Silberschatz e Sudarshan (2006) a linguagem de
manipulação de dados é responsável por viabilizar o acesso a manipulação de
dados de uma forma apropriada e compatível com o modelo de dados, basicamente
existe dois tipos:
▪ DMLs procedurais o usuário fica obrigado a especificar quais dados são
necessário e como obtê-los.
▪ DMLs não procedurais o usuário fica obrigado a especificar quais dados são
necessário sem especificar como obtê-los.
2.4 Modelo de Dados
Segundo Korth, Silberschatz e Sudarshan (2006) o modelo de dados é uma
coleção de ferramentas conceituais para descrever dados, relações de dados,
semântica de dados e restrições de consistência que visa apoiar a estrutura de um
banco de dados. Ou seja, o modelo de dados representa todas as propriedades
lógicas de armazenamento de dados.
2.4.1 Modelo Relacional
Este modelo usa uma coleção de tabelas para representar os dados e
relacionamentos entre elas, podemos dizer que o modelo relacional é um exemplo
de um modelo baseado em registros.
Conforme Korth, Silberschatz e Sudarshan (2006) o modelo de dados
relacional é o modelo de dados mais utilizado, e a grande maioria dos SGDBs atuais
15
é baseada nesse modelo.
2.4.2 Modelo Entidade / Relacionamento
Este modelo é baseado em uma percepção de um real que consiste em uma
coleção de objetos básicos, chamados de entidades, e as relações entre objetos
(KORTH; SILBERSCHATZ; SUDARSHAN, 1999, p.7).
2.4.3 Modelo Orientado a Objeto
Este modelo tem por base um conjunto de objetos, e esses objetos contém
valores armazenados em variáveis instâncias dentro do objeto. Existe um conjunto
de códigos que são utilizados para operar os objetos, chamamos esses conjuntos de
código de métodos (KORTH; SILBERSCHATZ; SUDARSHAN, 1999, p.8).
16
3 SISTEMA DE BANCO DE DADOS DISTRIBUÍDO
Segundo Date (2003), um sistema de banco de dados distribuído
basicamente consiste em uma coleção de sites, interligados através de algum tipo
de rede de comunicações, onde:
a. Cada site é ele próprio um site completo do sistema de banco de dados.
b. Porém, os sites concordaram em atuar juntos, de modo que um usuário em
qualquer site pode ter acesso aos dados em qualquer lugar da rede,
exatamente como se os dados estivessem armazenados no site do próprio
usuário. Decorre que o assim chamado “banco de dados distribuído” é na
verdade uma espécie de banco de dados virtual, cujas partes componentes
estão fisicamente armazenadas em vários bancos de dados “reais” distintos
em vários sites distintos (na verdade, é a união lógica desses bancos de
dados reais).
Na figura 2 temos a representação de um Sistema de Banco de Dados
Distribuído (SGBDD).
Figura 2 - Representação do sistema de banco de dados distribuído (SGBDD).
Fonte: (http://www.cos.ufrj.br/~marta/IntroductionP3.pdf).
17
3.1 Tipos de Sistema de Banco de Dados Distribuídos
Segundo Casanova (1999) o sistema gerenciador de banco de dados
distribuídos (SGBDD) pode ser classificado em dois grandes grupos homogêneo e
heterogêneo.
3.1.1 Bancos de Dados Homogêneos
Chamamos de Banco de dados Homogêneo quando todos os sites possuem
software de gerenciamento de banco de dados idênticos, ou seja, de um mesmo
fabricante, ambos se conhecem e concordam em cooperar nas solicitações dos
usuários do processamento. Conforme Elmasri e Navathe (2011) uma das
características desse sistema é que os sites locais concordam em entregar parte da
sua autonomia para ter direito de mudar esquemas ou software de sistema de
gerenciamento de banco de dados. Segundo Casanova (1999), um SGBD
distribuído será chamado de homogêneo (em "software") se os SGBDs locais forem
semelhantes, mais precisamente, um SGBD distribuído é homogêneo se todos os
seus SGBDs locais:
● Oferecer interfaces idênticas ou, pelo menos, da mesma família;
● Fornecerem os mesmo serviços aos usuários em diferentes nós.
3.1.2 Bancos de Dados Heterogêneos
Um banco de dados é heterogêneo, quando os sites são distintos e podem
usar diferentes esquemas e softwares de gerenciamento de banco de dados, pode
ocorrer dos sites não ter ciência um do outro e oferecerem apenas facilidades
limitadas para cooperação de processamento. Segundo Elmasri e Navathe (2011) a
diversidade nos esquemas é um problema importante para o processamento da
consulta, porém, a divergência de software se torna um obstáculo para o
processamento de transações que acessam múltiplos sites. Conforme Casanova
(1999), SGBDs distribuídos heterogêneos são quando os SGDBs locais forem
distintos e geralmente é utilizada para integrar sistemas já existentes, a escolha por
18
uma arquitetura ou outra é influenciada pelo aproveitamento de "hardware" e
"software" já existentes e pelo próprio hábito e grau de cooperação esperado dos
usuários em caso de uma mudança para um sistema diferente.
3.2 Vantagens do Banco de Dados Distribuídos
Segundo Elmasri e Navathe (2011), as vantagens mais importantes dos
bancos de dados distribuídos são:
• Maior facilidade e Flexibilidade de desenvolvimento da Aplicação - O
desenvolvimento e a manutenção de aplicações em sites geograficamente
distribuídos de uma organização são facilitados devido à transparência da
distribuição e controle de dados.
• Maior confiabilidade e disponibilidade - Confiabilidade e disponibilidade
são duas das vantagens em potencial mais comum citadas para bancos de
dados distribuídos, onde:
• Confiabilidade - É a probabilidade de um sistema estar funcionando (não
parado) em certo ponto no tempo.
• Disponibilidade - É a probabilidade de que o sistema esteja continuamente
disponível durante um intervalo de tempo. Isso é obtido pelo isolamento de
falhas ao seu site de origem, sem afetar os outros bancos de dados
conectados à rede. Quando os dados e o software de SGBDD são
distribuídos por vários sites, um destes pode apresentar falhas em enquanto
os outros continuam a operar. Apenas os dados e software que existem no
site defeituoso não poderão ser acessados. Isso melhora tanto a
confiabilidade quanto a disponibilidade. Uma melhoria ainda maior é obtida
pela devida replicação dos dados e software em mais de um site. Em um
sistema centralizado, uma falha e um único site tornam o sistema inteiro
indisponível a todos os usuários. Em um banco de dados distribuídos, alguns
dos dados no site podem ficar inalcançáveis, mas os usuários ainda podem
ser capazes de acessar outras partes do banco de dados. Se os dados no site
19
que apresentou falha tiverem sido duplicados em outro site antes da falha,
então o usuário não será afetado de forma alguma.
• Maior desempenho - Um SGBD distribuído fragmenta o banco de dados ao
manter os dados mais próximos de onde eles são mais necessários. A
localização de dados reduz a disputa pela CPU e serviços de E/S e, ao
mesmo tempo, reduz os atrasos nos acessos envolvidos nas redes remotas.
Quando um banco de dados grande é distribuído por vários sites, existem
bancos de dados menores em cada site. Como resultado, consultas e
transações locais que acessam dados em um único site possuem melhor
desempenho por causa dos bancos de dados locais menores. Além disso.
Cada site tem um número menor de transações executando do que se todas
as transações fossem submetidas a um único banco de dados centralizados.
Ainda o paralelismo entre consultas e dentro da consulta pode ser alcançado
ao executar várias consultas em diferentes sites, ou ao desmembrar uma
consulta em uma série de sub-consultas executadas em paralelo. Isso
contribui para melhorar o desempenho.
• Expansão mais fácil - Em um ambiente distribuído, a expansão do sistema
em matéria de inclusão de mais dados, aumento dos tamanhos do banco de
dados ou inclusão de mais processadores é muito mais fácil.
3.3 Arquitetura
A arquitetura de um sistema define a sua estrutura, ou seja, os componentes
do sistema são identificados, é especificada a função de cada componente e as
suas relações e interações.
Segundo Özsu e Valdiurez (2011) no que diz respeito à arquitetura as
possibilidades de projetar um SGBDD podem variar em de três dimensões:
autonomia, distribuição e heterogeneidade, conforme é exemplificado na figura 3.
20
Figura 3 - Variação de Arquitetura
Fonte: (ÖSZU; VALDIUREZ, 2011, p.25).
A autonomia , neste caso se se refere à distribuição de controle, e não dos
dados necessariamente. Indicando o grau em que SGBD individuais podem operar
independentemente. Autonomia é uma função de certo número de fatores, tais
como se os sistemas de componente (isto é, SGBDs individuais) trocarem de
informação, se eles podem, independentemente executar transações, e se é
permitido modificá-los (ÖZSU; VALDIUREZ, 2011, p.25).
A distribuição está relacionada à distribuição física de dados em múltiplos
nós, sendo que os o usuários não sabem de qual maneira os dados estão
distribuídos, ou seja, a distribuição é transparente ao usuário. De acordo com Özsu e
Valdiurez (2011) um SGBD pode ser distribuído da seguinte maneira:
• Cliente / Servidor: Os servidores concentram-se nas funções de gestão de
dados, enquanto os clientes se concentram em o ambiente do aplicativo,
incluindo a interface do usuário. Os deveres de comunicação são
21
compartilhados entre si.
• Distribuição não hierárquica: Não existe distinção de máquinas clientes e
servidores, cada máquina possui toda a funcionalidade de um SGBD podendo
se comunicar com as demais máquinas, executar consultas e transações.
A Heterogeneidade pode ocorrer em várias formas, que vão de diferentes
hardware e protocolos de redes de comunicação até variação nos modelos de
dados, linguagens de consultas e protocolos de gerenciamento de transações
(ÖZSU; VALDIUREZ, 2011).
3.4 Processamento Distribuído de Consulta
Em sistemas distribuídos, é necessário levar em conta inúmeros fatores para
aferir a resposta a uma consulta. O custo de transmissão de dados na rede e o
ganho em se ter diverso localidades processando partes da consulta em paralelo
são fatores importantes. Um ponto de equilíbrio deve ser encontrado entre
transferência de dados na rede e transferência entre discos para garantir um baixo
custo de transferência. De acordo com Elmasri e Navathe (2011) uma consulta em
banco de dados distribuídos é processada em estágios da seguinte forma:
• Mapeamento de consulta: A consulta de entrada em dados distribuídos é
especificada formalmente usando uma linguagem de consulta, depois ela é
traduzida para uma consulta algébrica em relações globais. Essa tradução é
feita ao referir-se ao esquema conceitual global e não leva em conta a
distribuição e replicação real dos dados. Portanto, essa tradução é em grande
parte idêntica àquela realizada em um SGBD centralizado. Ou seja, ele é
primeiro normalizado, analisado quanto a erros semânticos, simplificado e
finalmente reestruturado em uma consulta algébrica.
• Localização: Em um banco de dados distribuído, a fragmentação resulta em
relações armazenadas em sites separados, com alguns fragmentos
possivelmente sendo replicados. Esse estágio mapeia a consulta distribuída
no esquema global para consultas separadas em fragmentos individuais
22
usando informações de distribuição e replicação de dados.
• Otimização global de consulta : A otimização consiste em selecionar uma
estratégia com base em uma lista de candidatas que está mais próximo do
ideal. Uma lista de consulta candidatas pode ser obtida ao permutar a
ordenação das operações em uma consulta de fragmento gerada pelo estágio
anterior. O tempo é a unidade utilizada para medir o custo. O Custo total é
uma combinação ponderada de custos como o de CPU, os de E/S e aqueles
de comunicação pela rede são os mais significativos. Isso é especialmente
verdadeiro quando os sites são conectados por uma rede remota (WAN -
Wide Area Network).
• Otimização de consulta local: É o estágio comum a todos os sites do BDD,
as técnicas são semelhantes àquelas usadas nos sistemas centralizados.
3.5 Transparência de Dados
A transparência “esconde” dos usuários finais os detalhes de implementação.
Verifica-se também que segundo Elmasri e Navathe (2011) um sistema altamente
transparente oferece mais flexibilidade ao usuário final/desenvolvedor de aplicação,
pois não exige nenhum conhecimento ou conhecimentos básicos de sua parte. No
banco de dados centralizados, a transparência pertence à independência lógica e
física de dados para desenvolvedores de aplicação. Em um cenário de BDD, os
dados e software são divididos por vários sites conectados por uma rede de
computadores, de modo que tipos adicionais de transparência são introduzidos.
Além disso, talvez seja preferível duplicar alguns desses dados em outros lugares
por razões de confiabilidade e desempenho, que é conhecido como replicação de
dados, o resultado é um banco de dados distribuído que é fragmentado e replicado.
Para tratar de maneira adequada com este banco de dados distribuído, fragmentado
e replicado, o sistema deve ser capaz de trabalhar com diversos tipos de
transparências.
3.5.1 Transparência de Rede
23
Em um ambiente gerenciamento de banco de dados distribuídos o sistema
pode "esconder" os detalhes relativos à distribuição de dados na rede, minimizando
a necessidade do usuário saber onde está a relação. A Transparência de rede pode
ser dividida em transparência local e transparência de nomes, onde a transparência
local refere-se ao fato que independente da localização dos dados e do nó onde o
mesmo foi emitido, o comando será executado. A transparência de nomes
significa que quando um nome é associado a um objeto, os mesmos podem ser
encontrados sem ambigüidade (ELMASRI; NAVATHE, 2011).
3.5.2 Transparência de Replicação
A transparência de replicação visa realizar várias cópias dos mesmos objetos
de dados quem podem ser armazenados em vários sites para melhor
disponibilidade, desempenho e confiabilidade, contudo os usuários não têm
conhecimento da existência dessas cópias.
3.5.3 Transparência de Fragmentação
A transparência de fragmentação oculta do usuário a existência de
fragmentos, uma consulta global é transformada em várias consultas.
Segundo Elmasri e Navathe (2011):
Dois tipos de fragmentação são possíveis, horizontal e vertical. Na fragmentação horizontal as relações são distribuídas em sub relações (tabela) que são sub-relações de tuplas (linhas) na relação original. A fragmentação vertical distribui uma relação em sub-relações em que cada uma é definida por um subconjunto das colunas da relação original (ELMASRI; NAVATHE, 2011, p.591).
Ainda, segundo o autor existem outras transparências como: transparência
de projeto e transparência de execução referindo-se à liberdade de saber como o
banco de dados distribuído é projetado e onde uma transação é executada.
3.6 Armazenamento Distribuído dos Dados
24
Para se entender como o banco de dados distribuídos realiza o
armazenamento de dados é importante compreender alguns conceitos.
Conforme Korth, Silberschatz e Sudarshan (1999), quando uma relação r é
armazenada em um banco de dados, faz-se necessário abordar algumas questões
quanto ao armazenamento dessas relações em um banco de dados distribuído, tais
como:
● Replicação - O sistema mantem diversas réplicas idênticas de uma relação r.
● Fragmentação - A relação é dividida em vários fragmentos e esses fragmentos
são armazenados em outro site.
● Replicação e fragmentação - É a junção dos itens apresentados
anteriormente, a relação é dividida em vários pedaços e o sistema mantém diversas
cópias de cada fragmento.
3.6.1 Replicação de Dados
Replicação é o nome dado ao processo sincronização de entre dois ou mais
servidores de banco de dados com o objetivo de garantir que os dados estejam
disponíveis em dois ou mais servidores (KORTH; SILBERSCHATZ; SUDARSHAN,
1999, p.522).
Para Elmasri e Navathe (2006) “A replicação é útil na melhoria da
disponibilidade dos dados. O caso mais extremo é a replicação do banco de dados
inteiro em todos os sites do sistema distribuído, criando assim, um banco de dados
distribuído completamente replicado. Isso pode melhorar notavelmente a
disponibilidade porque o sistema pode continuar operando desde que pelo menos
um site esteja em operação” (ELMASRI; NAVATHE, 2011).
Segundo Korth, Silberschatz e Sudarshan (1999) existem diversas vantagens
e desvantagens na replicação de dados.
25
● Disponibilidade - Se um dos sites contendo os dados operacionais
falharem, então estes mesmos dados pode ser encontrado em outro site. Desta
forma o sistema pode continuar o processamento da consulta, mesmo com um site
inoperante.
● Paralelismo aumentado - Como todos os sites terão os mesmos dados, as
consultas realizadas geralmente ocorrerão nos servidores da rede local de cada
cliente, com isso será minimizada a movimentação de dados entre os sites,
melhorando a desempenho da rede que deixará de ficar sobrecarregada.
● Maior sobrecarga da atualização - Para garantir que todas as réplicas sejam
consistentes é exigido mais controle do SGBD. Assim sempre que há uma
atualização é necessária a atualização do todos os demais sites, com isso há uma
maior sobrecarga para o sistema.
3.6.2 Fragmentação de Dados
Quando uma relação é dividida em vários pedaços pode-se dizer que a
mesma está fragmentada. Um sistema pode ser fragmentado e replicado, ou seja,
uma relação pode ser particionada e cada uma dessas partições serem armazenada
em locais distintos, isso é chamada de fragmentação Uma vez fragmentada é
indispensável que cada fragmento possua as informações suficientes para recompor
a relação no formato original. Essa reconstrução pode ser realizada por meio da
aplicação de uma operação de união ou de um tipo especial de junção aos vários
fragmentos. "Há dois esquemas diferentes para a fragmentação de uma relação:
horizontal e vertical” (KORTH; SILBERSCHATZ; SUDARSHAN, 1999), existe
também a fragmentação mista, porém alguns autores não classificam a mesma
como um terceiro esquema de fragmentação.
3.6.2.1 Fragmentação Horizontal
Uma fragmentação horizontal é um subconjunto das tuplas nessa relação. As
tuplas que pertence ao fragmento são especificadas por uma condição de um ou
26
mais atributos da relação (ELMASRI; NAVATHE, 2011).
Os autores Korth, Silberschatz e Sudarshan (1999), definem a mesma como:
“Quando uma relação é particionada em um número de subconjuntos cada tupla
da relação pertence à pelo menos um fragmento, de modo que a relação original
possa ser reconstruída se necessário” (KORTH; SILBERSCHATZ; SUDARSHAN,
1999).
3.6.2.2 Fragmentação Vertical
O nó não precisa de todos os atributos de uma relação, essa técnica divide uma
relação “verticalmente” através das colunas, um fragmento vertical de uma relação
mantém apenas alguns atributos da relação.
3.6.2.3 Fragmentação Mista
A fragmentação mista é a junção da fragmentação horizontal e vertical.
3.7 Controle de Concorrência
O controle de concorrência é importante, pois garante que todas as transações
simultâneas sejam executadas como se fosse a única, ou seja, em uma execução
concorrente, as transações não devem gerar interferências que possam afetar a
sincronização. Segundo Casanova (1999) as anomalias que ocorre com mais
facilidades são perdas de atualizações, inconsistência no banco de dados e acesso
a dados inconsistentes, as técnicas de controle de concorrência deve garantir que
toda execução concorrente de um conjunto de transações seja serializável,
equivalente a alguma execução das transações em que cada transação é
completamente processada antes da seguinte começar.
3.7.1 Gerenciamento de Bloqueio Único
27
Com o uso dessa técnica o sistema mantém apenas um gerenciador de
bloqueio que reside em um único site escolhido. Um site é escolhido para tratar
todas as solicitações de bloqueio e desbloqueio, se alguma transação necessitar
bloquear um item de dados, ele enviar a solicitação para o site que foi escolhido
para atender a todas solicitações. O gerenciador de bloqueio determina se o
bloqueio pode ser concedido, se for possível atender a solicitação de bloqueio é
enviada uma mensagem para o site que realizou a solicitação de desbloqueio, caso
contrário a solicitação do site é postergada até que a mesma possa ser atendida.
Quando uma mensagem é enviada ao site em que a solicitação de bloqueio foi
iniciada, a transação pode ler o item de dados de qualquer um dos sites onde reside
uma réplica (cópia) do item de dados. Já no caso da escrita, todos os sites em que
reside uma réplica (cópia) do item de dados são obrigados a está envolvido na
escrita.
Segundo Korth, Silberschatz e Sudarshan (2006) esse esquema possui as
seguintes vantagens:
● Implementação simples: Esse esquema requer duas mensagens para tratar
de solicitações de bloqueio e uma mensagem para tratar de solicitação de
desbloqueio.
● Tratamento de impasse simples: As solicitações de bloqueio e desbloqueios
são feitas em apenas um site, os algoritmos de tratamento de impasse podem ser
aplicados a esse ambiente.
As desvantagens conforme Korth, Silberschatz e Sudarshan (2006) são as
seguintes:
● Gargalo: O site se torna um gargalo, apresentando lentidão e acompanhado
com altíssimas taxas de latência, pois todas as solicitações precisam ser
processadas lá.
● Vulnerabilidade: Se o site responsável pelo controle de concorrência falhar o
controlador de concorrência estará perdido, o processamento precisa ser
28
interrompido ou um esquema de recuperação precisa ser usado para que um site de
backup possa assumir o gerenciamento de bloqueio a partir do site defeituoso.
3.7.2 Gerenciador de bloqueio distribuído
Na implementação da técnica do gerenciamento de bloqueio distribuído a
função do gerenciamento de bloqueio é distribuída por diversos sites. Conforme
Korth, Silberschatz e Sudarshan (2006) cada site possui um gerenciador de bloqueio
local onde são administradas as solicitações de bloqueio e desbloqueio para os itens
de dados que estão armazenados no site. Esse esquema tem a vantagem de
implementação simples e reduz o gargalo do coordenador consequentemente. A
sobrecarga é razoavelmente baixa, exigindo duas transferências de mensagens para
lidar com solicitações de bloqueio e para tratar as solicitações de desbloqueio é
apenas uma transferência de mensagem.
3.7.3 Cópia Primária
A cópia primária é implementada quando um sistema utiliza a replicação de
dados.
“Assim, a cópia primária permite que o controle de concorrência para todos os
dados replicados seja tratado como o controle de concorrência para dados não
replicados” (KORTH; SILBERSCHATZ; SUDARSHAN, 2006, p.570).
3.7.4 Protocolo da Maioria
É mantido um administrador de bloqueio local em cada site, cuja função é
gerenciar as solicitações de bloqueio e desbloqueio para os itens de dados que
estão armazenados naquele site. Segundo Korth, Silberschatz e Sudarshan (2006)
quando uma transação solicita o bloqueio de um determinado item de dados Q, que
não é replicado e reside em um site S, uma mensagem é enviada para o
administrador de desbloqueio do site S solicitando o desbloqueio (em um modo de
bloqueio em particular). Se o modo de bloqueio solicitado for incompatível com o
29
item de dado Q, a solicitação aguarda até que possa ser conseguido, quando o
bloqueio é realizado , o administrador de bloqueio envia uma mensagem de resposta
informando que houve o bloqueio solicitado. Esse esquema possui a vantagem de
ser implementado facilmente e exige a troca de duas mensagens para o tratamento
de bloqueio e uma mensagem para o tratamento de desbloqueio. Uma as
características desse esquema é que ele trabalha de maneira descentralizada dessa
forma reduzindo os custos e o tráfego de dados. Contudo quando replicação de
dados ele apresenta as seguintes desvantagens:
▪ Implementação - Esse protocolo tem implementação mais complicada que
em relação a outros projetos.
▪Tratamento de Impasse - Já que as solicitações de bloqueio e desbloqueio
é descentralizada, o algoritmos para tratamento de impasse não necessita de
alteração, porém é possível que um impasse aconteça, até mesmo se apenas um
item de dados estiver bloqueado. Entretanto é possível evitar esses impasses de
modo fácil, solicitando que todos os sites realizem o bloqueio nas réplicas de um
item de dados em uma ordem predeterminada.
3.7.5 Protocolo Parcial
O Protocolo parcial basicamente é semelhante ao modelo do protocolo da
maioria. Conforme Korth, Silberschatz e Sudarshan (2006) a principal diferença do
protocolo da maioria é que as solicitações para bloqueios compartilhado são
processadas mais favoravelmente do que as solicitações para bloqueio exclusivo, a
seguir os detalhamentos dos bloqueios:
● Bloqueio compartilhamento - Se uma transação necessita do bloqueio de um
item de dados Q, ela solicita o bloqueio de Q, através do gerenciador de bloqueio
em todos os sites que possui uma replicação de Q.
● Bloqueios exclusivos - Se uma transação necessita bloquear um determinado
item de dados Q, ela solicita um bloqueio sobre Q, a partir do gerenciador de
bloqueio todos os sites que armazena uma réplica de Q.
30
3.7.6 Timestamp
A principal ideia do timestamp é que cada transação receba um "tempo"
exclusivo, que o sistema define para decidir a ordem de serialização. Conforme
Korth, Silberschatz e Sudarshan (2006) existem basicamente dois métodos para
geração de um único registro de tempo, um centralizado e outro distribuído. No
esquema centralizado, é escolhido um único site para a distribuição dos registros de
horário. Contudo no esquema distribuído todos os sites geram um único registro de
tempo global usando um contador lógico ou o relógio local. Para se obter um único
registro de tempo global é necessário concatenar o registro de tempo único local
com o identificador do site, que obrigatoriamente deve ser único.
31
4 REPLICAÇÃO
O processo de copiar e manter objetos de banco de dados em vários bancos
de dados que compõem um sistema de banco de dados distribuídos é denominado
de replicação. De acordo com a Ramalho (2005), as alterações aplicadas em um
determinado local são captadas e armazenadas localmente, antes de serem
enviados e aplicados a cada um dos locais remotos. A replicação utiliza a mesma
tecnologia de banco de dados distribuído para compartilhar informações entre vários
sites, contudo, um banco de dados replicado e um banco de dados distribuídos são
distintos, pois em um banco de dados distribuídos as informações estão disponíveis
em vários locais, porém, uma tabela específica reside apenas em um local.
Enquanto na replicação os mesmos dados estão disponíveis em vários locais. A
replicação é um ótimo recurso quando o objetivo é a distribuição de dados.
4.1 Estratégias de Replicação
Em relação à replicação de dados existem basicamente duas estratégias de
replicação, conhecidas como replicação síncrona e replicação assíncrona, onde
cada uma pode ser utilizada de acordo com o tipo de sistema a ser implementado,
necessidade de atualização de dados, desempenho e disponibilidade.
4.1.1 Replicação Síncrona
Na replicação síncrona as alterações em um objeto são propagadas
imediatamente para os demais objetos, as principais vantagens desta estratégia são
a garantia da consistência de dados entre os objetos replicados, pois para a
transação ser concretizada a mesma precisa ser confirmada em todos os objetos
envolvidos e a baixa latência na atualização dos objetos replicados. Contudo as
desvantagens se dão pelo excesso de operações que necessitam ser realizados
para que uma atualização seja concluída, baixa escalabilidade e pela baixa
autonomia que um objeto tem em relação aos demais (MELO, 2010).
32
Os sistemas mais adequados para essa estratégia de replicação são os que
possuem as seguintes características:
• Necessidade de altas consistências das réplicas;
• Possui operação de leitura maior que as de escrita;
• O número de objetos replicados é reduzido;
• Não exige alto desempenho para a utilização dos objetos;
• Os meios de comunicação são de alto desempenho, confiáveis e de alta
disponibilidade.
Podemos citar como exemplos de sistemas que utilizam a estratégia de
replicação síncrona sistema de aviação, bancário, comércio eletrônico e militar
(MELO, 2010)
4.1.2 Replicação Assíncrona
Nessa estratégia de replicação, as atualizações que ocorre no site não são
propagadas instantaneamente para o site de destino, gerando uma latência nesse
processa mento, pois as atualizações são registradas, enfileiradas e executadas nos
objeto de destino em um segundo momento. A replicação assíncrona soluciona
algumas limitações existentes na replicação síncrona, pois o tempo de resposta da
transação é reduzido, entretanto a consistência dos dados é prejudicada, pois, a
atualização é executada em apenas um local, desprezando a existência de outras
réplicas. Essa estratégia de replicação pode ocorrer de duas formas, em lotes ou por
demanda. Quando ocorre em lotes, as mudanças nos objetos são registradas e
enfileiras para serem processadas em um momento posterior. Os critérios para a
realização da sincronização entre objetos podem ser baseado em um período de
tempo, na quantidade de transação acumuladas, etc. Quando a replicação ocorre
por demanda, os objetos de destinos recebem as alterações quando a mesma é
solicitada por uma aplicação (MELO, 2010).
Algumas vantagens da replicação assíncrona são:
33
● Baixo custo de comunicação - a internet ou intranet pode ser utilizada para
comunicação entre as réplicas.
● Aumento do desempenho das aplicações - inicialmente as operações são
realizadas localmente, apresentando um tempo de resposta para as aplicações
muito baixas, já que as mesmas podem utilizar objetos mais próximos.
● Menor concorrência - não há necessidade de bloquear recursos, pois as
transações são executadas localmente.
● Maior disponibilidade - a possibilidade de uma operação não ser realizada é
menor, pois o objeto não necessita que a comunicação com os demais esteja
disponível.
Esse tipo de replicação é utilizado quando não há necessidade dos dados
serem atualizado em tempo real e quando os conflitos entre transações não
acontecem com muita freqüência (MELO, 2010).
4.2 Modelos de Replicação
Quanto ao modelo de replicação temos o modelo multimestre e o modelo
mestre/escravo.
4.2.1 Modelo Mutimestre
A replicação multimestre permite que vários sites gerenciem os grupos de
objetos replicados de banco de dados, os aplicativos atualizam as tabelas replicadas
em qualquer site pertencentes a esse modelo. Os servidores de banco de dados da
que funcionam como site mestre em um ambiente multimestre converge os dados
automaticamente de todas as réplicas de tabela garantindo a consistência global da
transação de dados e a integridade dos dados. A replicação multimestre é útil para
garantir a disponibilidade de um banco de dados de crítico de missão e também para
os aplicativos de processamento de transação que necessitam de inúmeros pontos
34
de acesso ás informações do banco de dados, garantindo a disponibilização de
dados ou mais acesso localizado de dados (RAMALHO, 2005).
Na figura 4 temos uma representação do modelo mutimestre.
Figura 4 - Representação do modelo multimestre.
Fonte: (http://prezi.com/axoc18nzbmtm/replicacao-de-dados/).
4.2.2 Modelo Mestre / Escravo
Nesse modelo a replicação é unidirecional, ou seja, replicação ocorre
somente em um sentido, de uma unidade primária de distribuição dos dados
chamada de mestre para uma unidade secundária chamada de escravo, sendo que
essa unidade pode ser fragmentada ou desfragmentada, centralizada ou distribuída.
Esse modelo de replicação é normalmente utilizado em backup servidores de banco
e na melhoria de desempenho de consultas em sites remotos, esse modelo também
possibilita a rápida recuperação de dados no caso de indisponibilidade da unidade
mestre. Apenas a base mestre recebe atualizações enquanto na base só é permitida
a leitura (RAMOS, 2007).
35
Na figura 5 temos uma representação do modelo mestre/escravo.
Figura 5 - Representação do modelo mestre/escravo.
Fonte: (http://prezi.com/axoc18nzbmtm/replicacao-de-dados/).
4.3 Objetos de Replicação
Segundo Ramalho (2005) quando um objeto de banco de dados existe em
vários servidores de um sistema de banco de dados distribuídos, ele é chamado de
objeto de replicação. Alguns bancos de dados permitem replicar tabelas e objetos de
suporte, tais como visões, triggers de banco de dados, packages, índices e
sinônimos.
4.4 Conflitos de Replicação
Segundo Ramalho (2005) é importante os ambientes de replicação prever a
possibilidade de conflitos de replicação que podem ocorrer quando duas ou mais
transações de originadas de sites distintos tentam atualizar a mesma informação
praticamente no mesmo momento. Se ocorrer conflitos de dados é necessário ter
mecanismos para garantir que os conflitos sejam sanados, conforme as regras de
36
negócio e que os dados sejam tratados corretamente em todos os sites. Além dos
conflitos que ocorrem em ambientes é importante ter recursos que permitam definir
um sistema de resolução de conflitos.
37
5 APLICAÇÃO
Para o ambiente de replicação será utilizada os seguintes componentes:
• VitualBox da Oracle para a criação de 2 máquinas virtuais;
• Banco de Dados Oracle 10G;
• Banco de Dados MySQL 5.0;
• Conexão ODBC.
Servidor Mestre
Figura 6 - Maquina virtual que funcionará como servidor mestre.
Fonte: Elaborado pelo autor.
38
Servidor Escravo
Figura 7 - Máquina virtual que funcionará como servidor escravo.
Fonte: Elaborado pelo autor.
O banco de dados Oracle 10g foi instalado no servidor (Mestre) e possui as
tabelas funcionário e dependente sendo que somente a tabela de funcionário será
replicada, conforme a figura 8.
39
Figura 8 - Diagrama de Entidade de Relacionamento D.E.R
Fonte: Elaborado pelo autor.
Foi utilizado o seguinte código SQL para a criação das tabelas, conforme o
diagrama anterior.
CREATE DATABASE cadastro;
USE cadastro;
CREATE TABLE Dependente
(
idDepen NUMBER (7,1) NOT NULL ,
Funcionario_idFunc NUMBER (7,1) NOT NULL ,
Nome VARCHAR2 (45) ,
Cpf VARCHAR2 (11) ,
Rg VARCHAR2 (10)
) ;
ALTER TABLE DependenteADD CONSTRAINT Dependente_PK PRIMARY KEY
(
idDepen
);
40
CREATE TABLE Funcionario
(
idFunc NUMBER (7,1) NOT NULL ,
Nome VARCHAR2 (45) ,
Cpf VARCHAR2 (11) ,
Rg VARCHAR2 (10) ,
Cargo VARCHAR2 (45)
) ;
ALTER TABLE Funcionario ADD CONSTRAINT Funcionario_PK PRIMARY KEY
(
idFunc
);
ALTER TABLE Dependente ADD CONSTRAINT Dependente_Funcionario_FK
FOREIGN KEY ( Funcionario_idFunc ) REFERENCES Funcionario ( idFunc ) ;
No servidor (Escravo) foi instalado o MySQL 5.0 será criada nesse banco de
dados a tabela funcionario, que receberá os dados do servidor(Mestre), a seguir o
código SQL utilizado para a criação da tabela.
CREATE TABLE Funcionario (
idFunc INTEGER(7) UNSIGNED NOT NULL ,
nome VARCHAR(45) NULL,
cpf VARCHAR(11) NULL,
rg VARCHAR(10) NULL,
cargo VARCHAR(45) NULL,
PRIMARY KEY(idFunc)
);
5.1 Criação do Processo de Replicação
Para a criação do processo de replicação, está sendo utilizadas duas bases de
dados, sendo que a replicação ocorrerá da base de dados mestre (Oracle) para o
41
escravo (MySQL) conforme a figura 9:
Figura 9 - Representação do Esquema de Replicação
Fonte: Elaborado pelo autor.
Todas as operações realizadas no banco de dados da Oracle, será replicada
para o banco de dados MySQL, combinando o modelo de replicação mestre/escravo
com o tipo de replicação síncrona, pois todas as operações será replicada
instantaneamente.
A criação do processo de replicação se iniciou pela máquina mestre onde foi
configurada a conexão ODBC, que permitirá a comunicação entre os bancos de
dados Oracle e MySQL, conforme a figura a seguir:
42
Figura 10 - Configurando ODBC MySQL
Fonte: Elaborado pelo autor.
No arquivo listener.ora que está localizado no diretório C:\oraclexe\app\oracle\
product\10.2.0\server\NETWORK\ADMIN adicionamos o seguinte código no
arquivo:
(SID_DESC =
(SID_NAME = ORACLE_MYSQL)
(ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = hsodbc)
)
Após a configuração do arquivo listener. ora , se faz necessário a configuração
do arquivo tsnames.ora localizando no diretório C:\oraclexe\app\oracle\product
\10.2.0\server\NETWORK\ADMIN é inserido no arquivo o seguinte código:
ORACLE_MYSQL =
43
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = servidor-9dd59b)(PORT = 1521))
(CONNECT_DATA =
(SID=ORACLE_MYSQL)
)
(HS=OK)
)
Agora se faz necessário criar o arquivo unitORACLE_MYSQL.ora no diretório
C:\oraclexe\app\oracle\product\10.2.0\server\hs\adm in conforme a figura 11.
Figura 11 - Criando o Arquivo Init
Fonte: Elaborado pelo autor.
O arquivo initORACLE_MYSQL.ora é composto pelo seguinte código:
44
# This is a sample agent init file that contains the HS parameters that are
# needed for an ODBC Agent.
#
# HS init parameters
#
HS_FDS_CONNECT_INFO = ORACLE_MYSQL
HS_FDS_TRACE_LEVEL = 0
#
# Environment variables required for the non-Oracle system
#
#set <envvar>=<value>
Após a configuração do arquivo initORALCE_MYSQL.ora é necessário reiniciar
o serviço do banco de dados para que as configurações sejam aplicadas ao banco
de dados Oracle conforme a figura 12:
Figura 12 - Reiniciando o Banco de Dados Oracle
Fonte Elaborado pelo autor.
45
Agora fazemos a conexão entre o banco de dados Oracle e MySQL, conforme o
código SQL a seguir:
CREATE DATABASE LINK "conMYSQL"
CONNECT TO "user"
IDENTIFIED BY "123456"
USING 'ORACLE_MYSQL'
Cada linha significa:
Linha 1 – nome do link.
Linha 2 – nome de usuário do banco MySQL.
Linha 3 – senha usuário do banco MySQL.
Linha 4 – o nome dado à conexão de fonte de dados ODBC do sistema.
Após a criação da conexão entre os bancos de dados, criaremos os sinônimos
para facilitar a manipulação das tabelas conforme o código SQL a seguir:
CREATE SYNONYM funcionarioMYSQL FOR funcionario@con;
CREATE SYNONYM dependentesMYSQL FOR dependente@con;
Feito a criação dos sinônimos, vamos criar as procedures e triggers das tabelas
funcionário e dependente.
Criamos a procedure para inserção de dados na tabela funcionário, conforme o
código SQL a seguir:
create or replace
PROCEDURE procINSERT(i NUMBER, n VARCHAR2, cp VARCHAR2, rg
VARCHAR2, ca VARCHAR2)
AS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO funcionarioMYSQL VALUES(i,n, cp, rg,ca);
COMMIT;
46
END;
Criamos a procedure para exclusão de dados na tabela funcionário, conforme o
código SQL a seguir:
create or replace
PROCEDURE procDELETE(i NUMBER)
AS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
DELETE FROM funcionarioMYSQL WHERE "idFunc" = i;
COMMIT;
END;
Criamos a procedure para atualização de dados na tabela funcionário, conforme
o código SQL a seguir:
create or replace
PROCEDURE procUPDATE(io NUMBER ,i NUMBER, n VARCHAR2, cp
VARCHAR2, rg VARCHAR2, ca VARCHAR2)
AS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
UPDATE funcionarioMYSQL SET "idFunc"=i, "nome"=n, "cpf"=cp, "cargo"=ca
WHERE "idFunc"=io;
COMMIT;
END;
Agora vamos criar as trigger da tabela funcionários, começamos pela trigger que
irá chamar a procedure procINSERT, conforme o código SQL a seguir.
create or replace
TRIGGER tgINSERT
AFTER INSERT ON funcionario
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
47
BEGIN
procINSERT(:NEW.idFunc, :NEW.nome, :NEW.cpf, :NEW.rg, :NEW.cargo);
END;
Agora vamos criar a trigger que irá chamar a procedure procDELETE, conforme o
código SQL a seguir.
create or replace
TRIGGER tgDELETE
AFTER DELETE ON funcionario
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
procDELETE(:OLD.idFunc);
END;
Criamos agora trigger que irá chamar a procedure procUPDATE, conforme o
código SQL a seguir.
create or replace
TRIGGER tgUPDATE
AFTER UPDATE ON funcionario
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
procUPDATE(:OLD.idFunc,:NEW.idFunc, :NEW.nome, :NEW.cpf, :NEW.rg,
:NEW.cargo);
END;
Feito isso, vamos criar a procedures e trigger da tabela dependente, começando
pela procedure responsável pela inserção de dados, conforme o código SQL a
seguir:
create or replace
48
PROCEDURE procINSERTdepen(i NUMBER, ii NUMBER,n VARCHAR2, cp
VARCHAR2,rg VARCHAR2)
AS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO dependenteMYSQL VALUES(i, ii, n,cp, rg);
COMMIT;
END;
Criamos a procedure para exclusão de dados da tabela dependentes, conforme o
código SQL a seguir:
create or replace
PROCEDURE procDELETEdepen(i NUMBER)
AS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
DELETE FROM dependenteMYSQL WHERE "idDepen"= i;
COMMIT;
END;
Criamos a procedure para atualização de dados da tabela dependente, conforme
o código SQL a seguir:
create or replace
PROCEDURE procUPDATEdepen(io NUMBER, i NUMBER, ii NUMBER,n
VARCHAR2, cp VARCHAR2,rg VARCHAR2)
AS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
UPDATE dependenteMYSQL SET "idDepen"=i, "Funcionario_idFunc"=ii,
"nome"= n, "cpf"= cp, "rg"=rg WHERE "idDepen"=io;
COMMIT;
END;
Concluída as procedures da tabela dependente, se faz necessário criar as trigger,
começaremos pela trigger responsável por chamar a procedure procINSERTdepen,
49
conforme o código SQL a seguir.
create or replace
TRIGGER tgINSERTdepen
AFTER INSERT ON dependente
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
procINSERTdepen(:NEW.idDepen, :NEW.funcionario_IDFUNC, :NEW.nome,
:NEW.cpf, :NEW.rg);
END;
Agora vamos criar a trigger que irá chamar a procedure procDELETEdepen,
conforme o código SQL a seguir:
create or replace
TRIGGER tgDELETEdepen
AFTER DELETE ON dependente
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
procDELETEdepen(:OLD.idDepen);
END;
Agora vamos criar a trigger que irá chamar a procedure procUPDATEdepen,
conforme o código SQL a seguir:
create or replace
TRIGGER tgUPDATEdepen
AFTER UPDATE ON dependente
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
procUPDATEdepen(:OLD.idDepen,:NEW.idDepen,:NEW.Funcionario_idFunc,
50
:NEW.nome, :NEW.cpf, :NEW.rg);
END;
5.2 Testes
O teste de replicação será realizado na tabela de funcionário com as operações
de inserção, atualização e exclusão de dados.
Vamos realizar a inserção de 4 registros no banco de dados da Oracle e verificar
se os dados foram replicados para a base de dados do MySQL.
Figura 13 - Inserindo Dados no Banco de Dados da Oracle
Fonte: Elaborado pelo autor.
51
Como podemos ver de os dados foram replicados para o MySQL, conforme a figura
14:
Figura 14 - Dados Replicados Para o MySQL
Fonte: Elaborado pelo autor.
52
Será realizada a atualização de um registro no banco de dados da Oracle conforme
a figura 15:
Figura 15 - Atualizando Dados no Banco de Dados da Oracle
Fonte: Elaborado pelo autor.
53
Podemos ver que a atualização também ocorreu no MySQL conforme a figura 16:
Figura 16 - Dados Atualizados no MySQL
Fonte: Elaborado pelo autor.
54
Agora será realizada a exclusão de um registro no banco de dados da Oracle
conforme a figura 17:
Figura 17 - Excluído Um Registro no Banco de Dados da Oracle
Fonte: Elaborado pelo autor.
55
Como pode ser visto o registro foi excluído no banco de dados MySQL conforme a
figura 18:
Figura 18 - Registro Excluído no MySQL
Fonte: Elaborado pelo autor.
56
5.3 Considerações
Conforme os testes realizados, pode-se observar que todas as operações
realizadas no banco de dados da Oracle foram replicadas para o MySQL, como os
testes foram realizados em máquinas virtuais não houve a necessidade de se
implantar uma infraestrutura de comunicação para a transferência de dados.
Neste trabalho apenas a tabela de funcionário foi replicada, contudo, para replicar
outras tabelas, basta utilizar os mesmos princípios que foram explanados durante o
desenvolvimento do ambiente de replicação, sendo possível utilizar outros bancos
de dados e até mesmo combinar modelos e estratégias de replicações conforme a
necessidade.
A replicação síncrona foi utilizada para que fosse possível perceber as alterações
nos ambientes, contudo, para essa estratégia de replicação é indispensável uma
conexão entre os servidores com a maior disponibilidade possível. Entretanto
quando não existe um meio de comunicação confiável a replicação assíncrona pode
ser utilizada, porém, é importante salientar que pode ocorrer inconsistência e
conflitos entre as réplicas.
Quanto aos bancos de dados utilizados, não foi levado em consideração o
desempenho, a segurança e outros fatores relativos aos mesmos, entretanto, ambos
são muito utilizados no mercado.
57
6 CONSIDERAÇÕES FINAIS
Como foi visto a replicação de dados oferece muitas vantagens como
desempenho, disponibilidade, redução de custos e distribuição de dados, já que é
possível ter a mesma réplica armazenada em diversos servidores independente do
software de banco de dados, porém é necessário levar em consideração o ambiente,
a localização e principalmente a infra-estrutura disponível. Neste caso foi utilizada a
replicação síncrona com o modelo mestre/escravo, para que fosse possível perceber
a replicação de dados entre os bancos de dados heterogêneos. É importante
salientar que ao utilizar a estratégia de replicação síncrona, o meio de comunicação
tem que ser confiável e com alta disponibilidade, pois, o processo de replicação
pode ser comprometido, contudo, com a replicação síncrona as bases de dados
sempre estarão atualizadas. Foi possível esclarecer que existem estratégias e
modelos de replicação para situações específicas, cabendo ao profissional da área
verificar quais as combinações atende a situação desejada. A replicação de dados
ainda precisa ser bastante explorada, pois é um assunto que ainda é pouco
discutido atualmente. Durante o desenvolvimento deste trabalho foi possível
comprovar que é possível implementar um banco de dados distribuído e replicá-lo
para qualquer banco de dados independente do fabricante. O desenvolvimento do
ambiente de replicação permitiu a demonstração de todo o processo de
configuração e replicação, bem como aplicar os conceitos abordado neste trabalho,
já que foi possível a junção da teoria com a prática, permitindo uma melhor
compreensão e entendimento do conteúdo explanado.
58
REFERÊNCIAS
BOSS, Líbia. Replicação de Dados Disponível em: <http://prezi.com/axoc 18nzbmtm/ replicacao-de-dados/> Acesso em: 3 set, 2013
DATE, C. J. Introdução a Sistemas de Banco de Dados . 8º. ed. São Paulo: Elsevier Brasil, 2003, 864p. ELMASRI, R.; NAVATHE, S. B. Sistema de Banco de Dados . 6º. ed. São Paulo: PEARSON, 2011. 808p. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados . 3º. ed. São Paulo: Makron Books, 1999. 904p. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados . 5º. ed. Rio de Janeiro: Elsevier, 2006. 808p. MACIEL, Lucas. Conexão e replicação de dados em banco de dados distribuídos heterogêneos Disponível em: <http://imasters.com.br/banco-de-dados/postgresql/ conexao-e-replicacao-de-dados-em-banco-de-dados-distribuidos-heterogeneos-parte-01/> Acesso em: 21 ago, 2013 MATTOSO. BANCO DE DADOS DISTRIBUÍDOS Disponível em: <http://www.cos.uf rj.br/~marta/IntroductionP3.pdf> Acesso em: 17 mai, 2013 MELO, P. C. B. Desenvolvimento de um Sistema de Replicação . 2010. 105f. Manografia (Bacharelado em Engenharia da Computação) - UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE , Natal RN, 2010. ÖZSU, M. T.; VALDIUREZ, P. Principles of Distributed Database Systems . 3º. ed. New York: Springer, 2011. 860p. Disponível em: <http://dl.bookos.org/genesis/6040 00/7a0f200338289c2f7cbe5b7e165fa510/_as/[M._Tamer_%C3%96zsu,_Patrick_Valduriez]_Principles_of_(Bookos.org).pdf> Acesso em: 13 out, 2013 ORACLE.. Introdução à Replicação Avançada Disponível em: <http://docs.o racle.com/cd/B19306_01/server.102/b14226/repoverview.htm#REPLN001> Acesso em: 1 out, 2013
59
RAMALHO, J. A. ORACLE 10G . 1º. ed. São Paulo: Thomson Pionera , 2005. 377p. RAMOS, Wagner. Replicação de Dados Disponível em: <object.com.br/file s/Replicação OBJECTSistemas.ppt > Acesso em: 6 ago, 2013 VIANA.. MYSQL: Replicação de Dados , Adriel Lucas Da Silva Viana Disponível em: <http://www.devmedia.com.br/mysql-replicacao-de-dados/22923> Acesso em: 28 out, 2013