Manografia Replicação em banco de dados distribuídos heterogêneos

Ciência da Computação

Replicação em Banco de Dados Distribuídos Heterogên eos

Cleidenilson Santiago da Silva

Salvador-BA

2013



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



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.


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


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


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


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


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


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


create or replace

PROCEDURE procDELETE(i NUMBER)


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)


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


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


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)


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


create or replace

PROCEDURE procDELETEdepen(i NUMBER)


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)


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


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


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


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


51

Como podemos ver de os dados foram replicados para o MySQL, conforme a figura

14:

Figura 14 - Dados Replicados Para o MySQL


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


53

Podemos ver que a atualização também ocorreu no MySQL conforme a figura 16:

Figura 16 - Dados Atualizados no MySQL


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


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


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

Manografia Replicação em banco de dados distribuídos heterogêneos

Technology

Transcript of Manografia Replicação em banco de dados distribuídos heterogêneos