TCC BDD Sidnei

Centro Universitrio - IESB
BANCO DE DADOS DISTRIBUDOS

Um Estudo de Caso em um banco de dados Homogneo Distribudo visando a
Alta Disponibilidade de Dados
Matrcula: 0931004012 - Sidnei Fernandes das Neves
Braslia-DF
Abril de 2012
Sidnei Fernandes das Neves
BANCO DE DADOS DISTRIBUDO

Um Estudo de Caso em um banco de dados Homogneo Distribudo visando
alta disponibilidade de Dados
Trabalho de Concluso de Curso apresentado

ao Curso de Ps-graduao com nfase em
SGBD Oracle do Centro Universitrio - IESB,
como requisito para a obteno do grau de
ps-graduado, sob a orientao do professor
Eder Couto.
Braslia-DF
Abril de 2012
Sidnei Fernandes das Neves
BANCO DE DADOS DISTRIBUDO

Um Estudo de Caso em um banco de dados Homogneo Distribudo visando
alta disponibilidade de Dados
Trabalho de Concluso de Curso apresentado

e aprovado em 13 de abril de 2012, pela banca
examinadora constituda pelos professores:
______________________________________________________
Prof. Eder Couto - Orientador
______________________________________________________
Prof. Esp. Paulo Lima Machado - Examinador
_______________________________________________________
Prof. Esp. Andr Nagy - Examinador
AGRADECIMENTOS
Agradeo a todos os professores que se empenharam na ministrao do curso
de Ps-Graduao em Banco de Dados no Centro Universitrio - IESB, os quais me
ajudaram a desenvolver e agregar conhecimento suficiente para que eu pudesse
prosseguir com as pesquisas e desenvolver este Trabalho de Concluso de Curso.
A minha esposa, Letcia Lins, a qual tem me dado toda fora e incentivo para
continuar nesta empreitada.
A uma pessoa espetacular, que tive a honra de conhecer no Centro
Universitrio IESB, chamado Andr Baracho, que foi uma das pessoas que se
dedicou bastante em me apoiar nos momentos de dvidas, se tornando uma pea
chave para que eu obtivesse xito neste trabalho.
Aos Diretores da Object Sistemas, pelo apoio e confiana depositados em mim
para se tornasse possvel a concluso deste trabalho.
Alm destes, no poderia me esquecer das pessoas que fazem parte minha
vida e que tanto contriburam com meu ensino bsico, sem o qual eu no teria
conseguido chegar ate aqui, so eles, meu pai, Paulo Srgio e minha segunda me,
Antonia Estelita.
RESUMO
Com o avano tecnolgico voltado para as redes de computadores e com as
facilidades oferecidas por elas, cada vez maior a quantidade de empresas que
adquam sua estrutura para um funcionamento em rede fazendo com que nenhum
computador fique simplesmente isolado.
Em um ambiente corporativo essencial que haja alta disponibilidade de
acesso aos dados atravs de uma rede, mas somente o acesso no basta, tem que
existir a garantia de disponibilidade desses dados, o que pode ter como uma alternativa
de soluo a distribuio do banco de dados em vrios servidores, dentro de uma
mesma empresa ou em diversas empresas distribudas por vrias localidades
geogrficas.
Este trabalho tem como objetivo principal demonstrar como funciona uma
estrutura para a distribuio de dados em diversos Sistemas de Gerenciamento de
Banco de Dados, atravs de redes computacionais, bem como expor quais so os
benefcios e as perdas em se eleger uma estrutura como esta para se trabalhar. Sero
expostas, ainda, algumas formas de se consolidar os dados distribudos e os prs e
contras de cada metodologia.
Todo o estudo voltado para um problema real de Gesto de Continuidade do
Negcio de uma empresa de Previdncia Complementar, a qual, neste trabalho ter o
nome fictcio de PREVIDAS. Todas as solues e anlises ocorrero em laboratrio
(Mquinas Virtuais).
ABSTRACT
With technological advances toward computer networks and the facilities
offered by them is increasing the number of companies that adapt their structure to a
network operation so that no computer is simply isolated.
In a corporate environment is essential to have high availability data access
across a network, but only access is not enough, there must be a guarantee of
availability of these data, which may have an alternative solution to the distribution
database across multiple servers within a single company or several companies spread
across multiple geographic locations.
This paper aims to demonstrate how a main structure for the distribution of
data in various Management Systems Database, via computer networks, as well as
expose what are the benefits and losses to be elected a structure like this to work. Will
be exposed, still some ways to consolidate the data spread and the pros and cons of
each methodology.
The whole study is a real problem facing the Management of a Business
Continuity in a Pension Funds, which, in this work will have the fictitious name to
PREVIDAS. All solutions and analysis will occur in the laboratory (Virtual Machines).
LISTA DE ILUSTRAES
Figura 1 - Arquitetura Centralizada ............................................................................... 17
Figura 2 - Arquitetura Verdadeiramente Distribuda ...................................................... 18
Figura 3 - Arquitetura do Oracle .................................................................................... 23
Figura 4 - Exemplo de MER Simples ............................................................................ 36
Figura 5 Diagrama da soluo de replicao ............................................................. 38
Figura 6 Diagrama Fsico do Banco de Dados ........................................................... 42
Figura 7 - Usurio de Banco de Dados ......................................................................... 44
Figura 8 - Redefinio de tamanho da tablespace System ........................................... 45
Figura 9 - Criao dos usurios do Banco de Dados .................................................... 46
Figura 10 - Criao das tabelas que sero replicadas .................................................. 47
Figura 11 - Concesso de privilgios aos usurios de banco ....................................... 48
Figura 12 - Concesso de privilgio de "Create Any Trigger" ....................................... 48
Figura 13 Arquivos de criao do Dicionrio de Dados ............................................. 49
Figura 14 - Execuo do Script de Criao do Dicionrio de Dados ............................ 49
Figura 15 - Carga inicial do Dicionrio de Dados .......................................................... 50
Figura 16 - Criao das tabelas de Log de replicao .................................................. 51
Figura 17 - Grants no dicionrio de dados para os usurios de replicao .................. 51
Figura 18 - Grants no dicionrio de dados para o proprietrio das tabelas .................. 52
Figura 19 - Tornando scripts Executveis ..................................................................... 52
Figura 20 - Converso de arquivos para o formato Unix............................................... 53
Figura 21 - Arquivo objectmmrs.properties ................................................................... 53
Figura 22 Arquivo objectdb.properties (Parmetro databases) .................................. 54
Figura 23 - Arquivo objectdb.properties (Parmetro do master) ................................... 54
Figura 24 - Arquivo objectdb.properties (Parmetro do Slave1) ................................... 55
Figura 25 - Arquivo objectdb.properties (Parmetro do Slave2) ................................... 55
Figura 26 - Configurao do Classpath (Conforme Manual) ......................................... 56
Figura 27 - Export do Classpath no Profile do Linux ..................................................... 56
Figura 28 - Teste preliminar de conexo com as bases de dados ................................ 56
Figura 29 - Arquivo Publicar.sh ..................................................................................... 57
Figura 30 - Execuo do script publicar.sh ................................................................... 57
Figura 31 - Viso parcial do arquivo publicar.sql ........................................................... 57
Figura 32 Criao de Triggers de replicao ............................................................. 58
Figura 33 - Cadastro dos servidores slaves de replicao............................................ 59
Figura 34 - Teste final de conectividade entre servidores ............................................. 59
Figura 35 - Cadastramento de Assinaturas ................................................................... 60
Figura 36 Insero e Consulta em mmrs1 ................................................................. 61
Figura 37 - Consulta em mmrs2 .................................................................................... 62
Figura 39 - Insero e Consulta em mmrs2 .................................................................. 63
Figura 40 - Insero e Consulta em mmrs3 .................................................................. 63
Figura 44 - Alterao e Consulta aos Dados ................................................................. 65
Figura 45 - Consulta de dado alterado replicado ao mmrs3 ......................................... 66
Figura 46 - Consulta de dado alterado replicado ao mmrs2 ......................................... 66
Figura 47 - Excluso e consulta a dados ...................................................................... 67
Figura 48 - Consulta a replicao em mmrs1 ................................................................ 67
Figura 49 - Consulta a replicao em mmrs3 ................................................................ 68

Figura 50 - Tabelas a serem replicadas vazias as 10:51:36 ......................................... 69
Figura 51 - Realizao da Carga no site mmrs1 ........................................................... 69
Figura 52 - Tabelas da sede e do o site alternativo 1 s 10:53:01................................ 70
Figura 53 - Bytes trafegados na replicao para o Servidor Alternativo 1 (mmrs2) ...... 70
Figura 54 - Apurao do desempenho do replicador .................................................... 71
Figura 55 - Grfico de Custos da Replicao ................................................................ 72
LISTA DE TABELAS
Tabela 1 - Matriz de Comparao de Replicadores ...................................................... 41
LISTA DE ABREVIATURAS E SIGLAS

AD Administrador de Dados.
API (Application Programming Interface) Interface de Programao de Aplicaes.
ARCn (Archiver Process) Processo de arquivamento.
BDD Banco de Dados Distribudo.
BI Business Intelligence.
CKPT (Ckecpoint Process) Marcador de pontos de verificao de processo.
CPU (Central Processing Unit) Unidade Central de Processamento.
DBLink Data Base Link
DBWn (Database Write Process) Processo de escrita na base de dados.
DCL (Data Control Language) Linguagem de Controle de Dados.
DDL (Data Definition Language) Linguagem de Definio de Dados.
DML (Data Manipulation Language) Linguagem de Manipulao de Dados.
E/S Entrada e Sada.
GB (Gigabytes).
GHz (Gigahertz).
IO (Input/Output) - A mesma definio de E/S.
LGWR (Log Write) Escrita de Log.
MB (Megabytes).
Mbps Megabits por segundo.
MER Modelo Entidade Relacionamento.
NTP (Network Time Protocol) Protocolo de hora da rede
OLTP (Online Transaction Processing) Processamento de transaes em tempo
real.
PMON (Process Monitor Process) Processo monitor de processos.
RAM (Random Access Memory) Memria de acesso randmico.
RPM Rotaes por minuto.
SBDD Sistema de Banco de Dados Distribudo.
SGA System Global Area.
SGBD Sistema de Gerenciamento de Banco de Dados.
SGBDD Sistema de Gerenciamento de Banco de Dados Distribudo.
SMON (System Monitor Process) Processo monitor do sistema.
SQL (Structured Query Language) Linguagem estruturada de pesquisa.

TI Tecnologia da Informao.
WEB Rede mundial de computadores.
SUMRIO
1. INTRODUO ........................................................................................................ 11
1.1
CONTEXTUALIZAO................................................................................. 12
1.2
MOTIVAO E CARACTERIZAO DO PROBLEMA................................ 13

1.2.1.
Justificativa ................................................................................................ 13
1.2.2.
Oportunidade ............................................................................................. 13
1.2.3.
Viabilidade ................................................................................................. 14
1.3
OBJETIVOS .................................................................................................. 14
1.3.1.
Objetivo geral ............................................................................................. 14
1.3.2.
Objetivo especfico .................................................................................... 14
1.4
RESULTADOS ESPERADOS ...................................................................... 15
1.5
ESTRUTURA DO TRABALHO ..................................................................... 15
2. REVISO DA LITERATURA ................................................................................... 16

2.1.
SISTEMA DE BANCO DE DADOS ............................................................... 16
2.2.
TIPOS DE BANCOS DE DADOS ................................................................. 16

2.2.1.
Banco de Dados Centralizado ................................................................... 16
2.2.2.
Banco de Dados Distribudo ...................................................................... 17
2.3.
VANTAGENS DE UM BANCO DE DADOS DISTRIBUDO.......................... 18
2.4.
DESVANTAGENS DE UM BANCO DE DADOS DISTRIBUDO .................. 20
2.5.
PROBLEMTICAS DE UM BANCO DE DADOS DISTRIBUDO ................. 21
2.6.
ARQUITETURA DO BANCO DE DADOS ORACLE..................................... 22

2.6.1.
Funcionamento da Instance ...................................................................... 23
2.6.2.
Detalhamento da SGA ............................................................................... 24
2.6.3.
Detalhamento da Database ....................................................................... 24
2.6.4.
Processos em background ........................................................................ 24
2.7.
STRUCTURED QUERY LANGUAGE (SQL) ................................................ 26
2.8.
REPLICAO DE DADOS ENTRE BANCOS DE DADOS DISTRIBUDOS 26
2.9.
2.8.1.
Modelo de Replicao ............................................................................... 27
2.8.2.
Mtodos de Replicao ............................................................................. 28
2.8.3.
Conflitos de Replicao ............................................................................. 29

SOFTWARES DE REPLICAO ................................................................. 30
2.9.1.
Dbmoto ...................................................................................................... 30
2.9.2.
Oracle Goldengate ..................................................................................... 30
2.9.3.
DBLink ....................................................................................................... 30
2.9.4.
Objectmmrs ............................................................................................... 31
2.9.5.
DBReplicator .............................................................................................. 33
3. METODOLOGIA ..................................................................................................... 35
3.1.
METODOLOGIA UTILIZADA ........................................................................ 35
3.2.
PLANEJAMENTO DE CRIAO DO BANCO DE DADOS DISTRIBUDO.. 35
3.3.
MODELO DE DADOS ................................................................................... 35

3.3.1.
Modelo entidade-relacionamento .............................................................. 35
3.4.
ETAPAS PARA O DESENVOLVIMENTO E IMPLMENTAO ................... 36
3.5.
CONTEXTUALIZAO DO ESTUDO DE CASO ......................................... 37
3.6.
PROCEDIMENTO DE PESQUISA ............................................................... 37
4. ESTUDO DE CASO ................................................................................................ 38

4.1.
DIAGRAMA DA SOLUO .......................................................................... 38
4.2.
SGBD UTILIZADO ........................................................................................ 39
4.3.
INFRA-ESTRUTURA .................................................................................... 39
4.4.
DESCRIO DA SOLUO ........................................................................ 40
4.5.
CRIAO DO PROCESSO DE REPLICAO ............................................ 43
4.6.
TESTES DE REPLICAO .......................................................................... 61

4.6.1.
Operaes de Insert. ................................................................................. 61
4.6.2.
Operaes de Update ................................................................................ 65
4.6.3.
Operaes de Delete ................................................................................. 67
4.7.
DESEMPENHO DO REPLICADOR .............................................................. 68
4.8.
GRFICO DE INVESTIMENTO .................................................................... 71
4.9.
FUNCIONAMENTO E MANUTENO DO REPLICADOR.......................... 72
5. ANLISE ................................................................................................................. 74
5.1.
CONSIDERAES GERAIS ........................................................................ 74
5.2.
RESULTADOS OBTIDOS............................................................................. 74
6. CONCLUSES ....................................................................................................... 75
6.1.
QUANTO AO PROBLEMA E A SOLUO .................................................. 75
7. SUGESTO DE TRABALHOS FUTUROS ............................................................. 76

8. REFERNCIAS BIBLIOGRFICAS ...................................................................... 77
9. GLOSSRIO ........................................................................................................... 79
10.
ANEXOS .............................................................................................................. 84
1.
INTRODUO
Este trabalho tem como objetivo demonstrar o funcionamento de um banco
de dados distribudo e explicar os seus principais conceitos, bem como compar-lo

ao modelo centralizado, expondo as vantagens e desvantagens em se utilizar esta
tecnologia e demonstrar a sua utilizao em um caso de uso de uma empresa de
Previdncia Complementar.
Um Sistema de Banco de Dados Distribudo (SBDD) nada mais do que
uma coleo de mltiplos bancos de dados homogneos ou heterogneos,
logicamente inter-relacionados distribudos atravs de uma rede de computadores e
gerenciado por um Sistema de Gerenciamento de Banco de Dados Distribudo
(SGBDD) que responsvel por tornar a distribuio transparente para todos os
usurios.
Este modelo traz a vantagem do processamento distribudo, atravs do qual
vrios computadores (nodos) podem dividir um grande e intratvel problema em
partes menores e menos complexas e os resolvem eficientemente de maneira
coordenada.
Outra grande vantagem a possibilidade de descentralizao dos dados, o
que proporciona alta disponibilidade, pois mesmo que um dos servidores do SBDD
seja colocado fora de operao no indicar a falta de acesso aos dados, pois estes
estaro distribudos total ou parcialmente de forma confivel entre os outros nodos
existentes.
Esta tecnologia surgiu a partir da fuso da tecnologia de Banco de Dados e
a tecnologia de Rede e Comunicao de Dados, pois nos anos 70 e incio dos anos
80 a idia que se tinha era de centralizar os dados, o que resultou em bancos
monolticos e gigantescos, que consequentemente, exigiam muito mais poder de
processamento. Este cenrio logo se inverteu e ao final dos anos 80 a tendncia
passou a ser descentralizar os bancos de dados para haver autonomia no
processamento dos dados, tendo vrios reflexos positivos tais como a alta
confiabilidade, disponibilidade e melhoria de desempenho.
11
1.1
CONTEXTUALIZAO
Atualmente, com o avano da tecnologia, exigida cada vez mais agilidade,
segurana e alta disponibilidade nos processos, sejam de uma pequena empresa ou

de uma multinacional. Isso tem sido um grande desafio para os profissionais de TI,
os quais tem a obrigao de estarem sempre atentos s mudanas tecnolgicas que
auxiliem na rdua tarefa de melhoria dos processos no aspecto de eficincia, alta
disponibilidade, segurana, confiabilidade e etc.
Um processo bem definido s traz bons resultados para as corporaes,
pois nas anlises realizadas antes da implementao de uma soluo, devem ser
avaliados todos os aspectos positivos e negativos, bem como seus respectivos
reflexos.
J um processo mal definido pode levar uma empresa falncia, pois torna
o trabalho to ineficiente que pode prejudicar o negcio, ocasionando diversos
problemas, tais como baixo tempo de resposta, falhas constantes, insegurana, o
que pode gerar consequentemente a falta de confiabilidade. Todos estes problemas
podero ocasionar a perda de mercado para outras empresas mais estruturadas e
preparadas para trabalhar com maior qualidade.
Com a utilizao de um Banco de Dados Distribudo (BDD), vrios dos
fatores negativos so minimizados pelo fato deste se tornar mais eficiente
dependendo da forma que for implementado, pois deixar de contar apenas com um
banco de dados centralizado e trabalhar com vrios bancos distribudos em locais
distintos, o que d mais agilidade e segurana, pois quando um banco de dados no
estiver disponvel por algum tipo de falha, s este dever ser tratado e os demais
continuaro trabalhando normalmente.
Considerando que o volume dirio de transaes de uma empresa pode ser
muito grande, necessrio elaborar a melhor soluo para a atualizao e
replicao dos dados, pois o trafego na rede ir aumentar substancialmente, o que
far, dependendo da soluo que for adotada, que as respostas s requisies feitas
pelos usurios em suas estaes de trabalho sejam muito lentas.
Por esse motivo, os profissionais de Tecnologia da Informao (TI) precisam
adotar alternativas eficientes para realizar consultas e alteraes dos dados sem
que haja o comprometimento do desempenho da rede.
12
1.2
MOTIVAO E CARACTERIZAO DO PROBLEMA

Uma empresa precisa de acesso aos dados para poder trabalhar, pois sem
eles os processos no conseguem seguir o fluxo normal.

Sendo assim, necessrio tornar mais estvel e fcil o acesso e troca de
dados entre uma empresa sede e seus sites alternativos, utilizando para este fim
uma estrutura de rede computacional e os recursos disponibilizados pelo SGBDD.
Considerando que a empresa em questo atende a centenas de clientes
diariamente, indispensvel que exista alta disponibilidade para acesso aos dados.
Este o principal motivo para a implementao de um banco de dados distribudo,
pois mesmo que algum dos servidores deixe de funcionar, os dados sempre estaro
disponveis em outro servidor, fazendo assim com que o risco de perda dos dados
seja
minimizado
disponibilidade
dos
dados
maximizada,
que
consequentemente os nodos que no tiveram falhas continuem operando

normalmente.
1.2.1.
Justificativa
A cada dia se torna mais evidente para as empresas que querem realmente
crescer ou se manter no mercado, que tal objetivo inalcanvel se no houver um

forte investimento em tecnologia, pois s assim haver segurana e disponibilidade
das informaes a qualquer momento que se desejar, principalmente nos momentos
estratgicos de negociaes e atendimentos por exemplo.
1.2.2.
Oportunidade
Analisando a justificativa acima possvel perceber que as empresas
realmente deveriam investir em tecnologia, tendo em contrapartida aumento do

volume de negcios, ora prejudicados pela falta de infra-estrutura. Este aumento de
negociaes se justifica, pelo fato dos processos passarem a fluir com maior rapidez
e segurana aps a implantao de uma nova estrutura mais slida e confivel.
Em fase de projeto, para criar um cenrio prximo ao real e avaliar as
ocorrncias que podem vir a acontecer aps a implantao, ser criado um
laboratrio de testes, no qual ser montada toda a estrutura necessria para
distribuir os dados de um SGBD centralizado. Neste momento sero iniciadas as
anlises e coleta de informaes para identificar, na prtica, quais so reais
13
dificuldades encontradas na implantao de um SGBDD. Aps o processo de

implantao sero simulados alguns processos inerentes a um SGBDD, tais como a
fragmentao, replicao e alocao de dados.
1.2.3.
Viabilidade
A arquitetura de um BDD, assim como todo investimento que feito em
tecnologia, possui um custo elevado, pois se trata de uma estrutura mais complexa a
ser administrada. Mas dependendo da rea de atuao e do volume de negociaes
realizadas diariamente por uma empresa, pode ser um investimento justificvel se
comparado aos prejuzos causados pela inoperabilidade do negcio, caso ocorra
alguma falha numa arquitetura com banco de dados centralizado.
1.3
OBJETIVOS
1.3.1.
Objetivo geral
Definir uma soluo que garanta alta disponibilidade para um SBDD, sempre
se preocupando com os aspectos relacionados segurana, independente dos

custos correspondentes.
1.3.2.
Objetivo especfico
Aplicar, de forma prtica, o que est descrito nas documentaes literrias
que tratam dos assuntos correlatos ao projeto, que sirvam de embasamento para a
definio da melhor soluo para a distribuio dos bancos de dados e suas
respectivas rotinas de replicao.
Avaliar algumas das formas e ferramentas de replicao disponveis no
mercado, focando nos prs e contras de cada uma.
Propor uma soluo eficaz para replicao de dados entre servidores de
banco de dados localizados em diferentes sites.
Montar um laboratrio para o estudo de caso que simular a replicao entre
bancos de dados Oracle.
Analisar a qualidade dos dados replicados entre os sites criados em
laboratrio.
14
Demonstrar que perfeitamente possvel, com algum esforo adicional,

implementar uma estrutura de Banco de Dados distribudo, o que adicionar
segurana estrutura de dados da organizao.
1.4
RESULTADOS ESPERADOS
Aps a criao da estrutura de BDD, esperado o aumento do desempenho
dos sistemas, a alta disponibilidade das bases de dados, a confiabilidade dos dados
e informaes geradas e consequentemente o aumento das negociaes da
empresa.
1.5
ESTRUTURA DO TRABALHO
O trabalho est estruturado em 10 (dez) captulos. O primeiro trata da
introduo, a contextualizao do estudo, o que motivou o desenvolvimento desta

pesquisa, os objetivos gerais e especficos, os resultados esperados e a estrutura do
trabalho.
O captulo dois trata de conceitos, sempre embasado por autores
conhecidos na rea de Banco de Dados, alm da verificao das vantagens,
desvantagem e problemticas de tal implementao e alguns dos replicadores
existentes no mercado.
No
captulo
trs
apresentada
metodologia
de
planejamento,
desenvolvimento e implementao de um Banco de Dados Distribudo.

O captulo quatro trata do estudo de caso e da descrio das solues
tcnicas abordadas para a construo do BDD e seu respectivo processo de
replicao de dados.
O captulo cinco consiste na anlise dos resultados obtidos a partir do
estudo em questo, onde so feitas as consideraes gerais e demonstrados os
resultados obtidos.
No captulo seis feita a concluso do trabalho com a anlise dos aspectos
positivos e negativos identificados e avaliados na implementao da soluo para o
estudo de caso em questo.
No capitulo sete feita uma sugesto para trabalhos futuros que englobam
assuntos correlatos ao desenvolvido neste trabalho.
Ao final as referncias bibliogrficas pesquisadas, o glossrio, apndices e
anexos.
15
2.
REVISO DA LITERATURA
2.1.
SISTEMA DE BANCO DE DADOS

Um sistema de banco de dados (SBD) basicamente um sistema de
manuteno de registros por computador (DATE, 1991), que possui a misso de

armazenar os registros inseridos pelos usurios e recuper-los quando solicitado.
Por estrutura de banco de dados entendemos os tipos de dados,
relacionamentos e restries que devem suportar os dados (ELMASRI/NAVATHE,
2005).
Um sistema de gerenciamento de bancos de dados (SGBD) consiste em
uma coleo de dados inter-relacionados e em um conjunto de programas para
acess-los (KORTH, 1995).
Para que haja uma fcil compreenso dos assuntos abordados, nos tpicos a
seguir detalharemos os tipos de banco de dados.
2.2.
TIPOS DE BANCOS DE DADOS QUANTO A ARQUITETURA
2.2.1. Banco de Dados Centralizado

uma estrutura na qual todos os usurios do sistema acessam um mesmo
servidor que est fisicamente localizado em um local nico.
A conexo a este servidor ocorre atravs de uma rede de computadores, a
qual pode utilizar de diversos meios para que ocorra a comunicao, tais como cabo
UTP, coaxial, rdio, fibra-ptica e etc.
Este modelo estrutural atualmente no recomendvel por no ser to
seguro, pois dependendo da capacidade de processamento e armazenamento do
servidor, quantidade de dados trafegados em rede, quantidade de usurios
conectados e complexidade das operaes, os resultados para o usurio final
podem se tornar muito demorados ou at apresentar erros em se tratando de
solues WEB, alm do risco de parada total da empresa em caso de
inoperabilidade do servidor de banco de dados centralizado.
Estes so alguns dos motivos pelos quais as empresas atualmente, com o
avano da tecnologia, esto migrando para a arquitetura de banco de dados
distribudo, que mais complexa de se implantar e manter, porm mais rpida e
segura se comparada centralizada.
16
A figura 1 demonstra um exemplo de arquitetura centralizada, na qual os

servidores trabalham de forma independente dentro da fronteira da rede de
computadores, sem haver o compartilhamento de disco, Central Processing Unit
(CPU) e memria. Cada usurio processa sua informao e armazena em um nico
site central.
EST
Servidor de Banco de Dados (Central - Braslia)
Rede de comunicao
Servidor
(Goinia)
Servidor
(Salvador)
Servidor
(Manaus)
Servidor
(Belo Horizonte)
Servidor
(So Paulo)
Figura 1 - Arquitetura Centralizada
Este modelo possui a desvantagem de que todas as informaes precisam

trafegar pela rede e chegar ao site onde est o banco de dados central, o que pode
sobrecarregar o canal de comunicao deixando o servio lento. Alm do mais, se
houver algum problema no site central, os demais sites tambm ficaro sem acesso
aos dados.
2.2.2. Banco de Dados Distribudo
um conjunto de vrios bancos de dados logicamente inter-relacionados,
fisicamente separados em diferentes localidades, dispersos geograficamente e
distribudos por uma rede de computadores (ZSU & VALDURIEZ, 2001).
De acordo com ELMASRI e NAVATHE, 2005, Podemos definir banco de
dados distribudo (BDD) como uma coleo de mltiplos bancos de dados
logicamente inter-relacionados distribudos por uma rede de computadores.
17
Este modelo traz a vantagem da computao (processamento) distribuda,

onde vrios computadores interconectados dividem um problema grande e intratvel
em partes menores e o resolve eficientemente de maneira coordenada.
A figura 2 apresenta a ideia de uma estrutura de BDD, onde cada site possui
seu respectivo SGBD, todos trabalhando de forma local e fazendo troca de
informaes quando necessrio atravs de uma rede de comunicao. Neste
modelo de arquitetura todos SGBDs podem ser iguais em todos os sites (arquitetura
de BDD homognea) ou diferentes em um ou mais sites (arquitetura de BDD
heterognea).
Servidor
(Salvador)
Servidor
(Braslia)
Servidor
(Manaus)
Rede de comunicao
Servidor
(So Paulo)
Servidor
(Goinia)
Servidor
(Belo Horizonte)
Figura 2 - Arquitetura Verdadeiramente Distribuda
Uma das principais vantagens deste modelo que se houver algum incidente
que ocasione a falha de algum dos sites, os outros podero continuar operando
normalmente. A falha ocorrida neste caso seria transparente para os demais.
2.3.
VANTAGENS DE UM BANCO DE DADOS DISTRIBUDO

De acordo com KORTH e ZSU h diversas vantagens em se implantar um
sistema de gerenciamento de bancos de dados distribudos. Abaixo so destacadas

algumas delas:
Gerenciamento de dados distribudos - com nveis diferentes de
transparncia. Na forma ideal um SGBD deve ser transparente na distribuio, no
sentido de camuflar os detalhes de onde cada arquivo se encontra armazenado
18
fisicamente, ou seja, mesmo que existam vrios sites onde os dados so

armazenados (distribudos), isso deve ser transparente para o usurio final. A
vantagem de um SGBD totalmente transparente o alto nvel de suporte que ele
oferece para o desenvolvimento de aplicativos complexos.
Transparncia de distribuio ou de rede - significa que o usurio no
precisa conhecer detalhes tcnicos ou operacionais relacionados camada de rede.
Este item subdivide-se em:
Transparncia de localizao significa que um comando utilizado para
realizar determinada tarefa pode ser executado sem nenhum problema
pelo usurio, independente da localizao dos dados e da localizao do
sistema onde o comando foi emitido.
Transparncia de nomenclatura significa que uma vez especificado o
nome, os objetos nomeados podem ser acessados de forma no ambgua
sem a necessidade de especificao adicional.
Transparncia de replicao significa que as cpias de dados podem
ser armazenadas em mltiplos locais para obter melhor disponibilidade,
desempenho e confiabilidade. O usurio final no precisa saber da
existncia de cpias.
Transparncia de fragmentao significa que os dados podem estar
replicados em diversos sites de forma horizontal ou vertical, mas o
usurio no precisa tomar conhecimento deste detalhe tcnico.
Melhoria na confiabilidade e na disponibilidade:
Confiabilidade definida de forma ampla como a probabilidade de que o
sistema esteja sempre em operao.
Disponibilidade a probabilidade de que o sistema esteja disponvel em
um intervalo de tempo.
Nota: Quando os dados e o software do SGBD so distribudos por vrios
sites, se um site falhar os outros continuam funcionando. Apenas os
dados do site que falhou no podem ser acessados, mas como se trata
de banco distribudo, o usurio pode acessar outras partes do banco de
dados.
Melhoria de desempenho um banco de dados grande e complexo
quebrado em vrios bancos com tamanhos menores e menos complexos, os dados
ficam mais prximos de onde eles so realmente necessrios, diminuindo a disputa
19
por CPU, reduzindo o IO e consequentemente reduzindo o atraso de acesso aos

dados.
Facilidade de expanso em um ambiente distribudo, tanto a expanso
quanto ao acrscimo de mais dados, aumento do tamanho dos bancos de dados ou
acrscimo de mais processadores muito mais fcil, justamente pelo fato j citado
de que estar se trabalhando com bancos menores e menos complexos.
Economia com link o custo com comunicao de dados pode diminuir,
pois os dados ficaro mais prximos do usurio, significando uma economia
significativa nas situaes em que o volume de trfego de dados tarifado por
exemplo.
Economia com hardware A reduo de custos com servidores se d pelo
fato de que podero ser utilizados computadores de menor valor e porte, tendo em
vista que o volume de processamento menor para os dados locais.
Aumento de performance Uma estrutura distribuda apresenta melhor
performance que um sistema centralizado pelo fato de haver a distribuio da carga
de trabalho, pois cada site processa apenas parte do banco de dados, reduzindo em
muito o esforo da CPU (Central Processing Unit) e o volume de E/S (entrada e
sada).
2.4.
DESVANTAGENS DE UM BANCO DE DADOS DISTRIBUDO

De acordo com KORTH e ZSU neste modelo existe uma complexidade
muito superior, pois alm de existirem os problemas encontrados em um ambiente

de bancos de dados centralizados, ter vrios problemas no resolvidos (aspectos
de modelagem, processamento, consultas, concorrncia, sistema operacionais,
entre outros), alm do custo adicional provocado pela necessidade de se investir em
cursos com alto valor para o treinamento de pessoal, realizao de aquisio de
novos aplicativos e investimento em segurana da rede do SBDD, a qual precisa
permanecer sempre muito bem protegida.
Distribuio de controle - mesmo sendo considerada uma vantagem a

distribuio gera problemas de sincronizao e coordenao. Portanto, este
controle distribudo exige mais responsabilidade e cuidados j que pode se
tornar facilmente uma obrigao.
Segurana um fator primordial para que qualquer negcio continue

funcionando. Manter a segurana das redes uma tarefa sria e complexa e
20
os problemas de segurana em sistemas de bancos de dados distribudos so

mais complexos do que os problemas nos sistemas de bancos de dados
centralizados.
Entre os sites de banco de dados distribudos existe uma rede de
comunicao que deve estar resguardada por regras bem rgidas de segurana, o
que uma tarefa sria, complexa e cara. Por este motivo os problemas de
segurana em SBDD so mais complexos que em bancos de dados centralizados.
2.5.
PROBLEMTICAS DE UM BANCO DE DADOS DISTRIBUDO

Segundo KORTH e ZSU, vrios problemas tcnicos precisam ser resolvidos
para se chegar ao melhor do potencial dos SGBDDs, pois estes possuem uma
complexidade muito maior, o que pode influenciar na estabilidade do SBDD.
Destacam-se dentro da problemtica os tpicos a seguir:
Projeto de bancos de dados distribudos Este um dos principais pontos

a serem discutidos quando se surge a idia de distribuir dados por diversos
sites, pois existem duas alternativas: particionar e replicar. O particionamento
implica em estudos matemticos com o intuito de reduo de custos com
trfego de dados pela rede, sincronizao entre sites e armazenamento de
dados. J a replicao uma forma de se manter cpias dos dados em duas
ou mais localidades, de forma a garantir que mesmo na extino de
determinado site, os dados esto preservados em outra localidade.
Processamento distribudo de consultas Em um SBDD a eficincia de

atualizao de dados reduzida, mas em contrapartida, as consultas ficam
muito mais rpidas, pelo fato dos dados consultados estarem prximos do
usurio. O objetivo melhorar os fragmentos, utilizando paralelismo para
otimizar o desempenho nas consultas e atualizaes.
Gerenciamento de diretrio distribudo No dicionrio de dados esto

contidas informaes como estrutura e localizao sobre os itens de
informaes no banco de dados. O dicionrio de dados pode permanecer
centralizado em um nico local ou distribudo por vrios sites, onde pode
haver uma cpia ou vrias cpias do banco de dados e devero estar em
constante atualizao.
Controle distribudo da concorrncia Refere-se sincronizao de dados

entre os bancos distribudos, com a finalidade de manter a integridade dos
21
dados. O controle da concorrncia em um contexto distribudo um pouco

diferente do que ocorre com a estrutura centralizada. Alm de se preocupar
com a integridade das informaes de um nico banco de dados,
importante, tambm, para a consistncia de vrias cpias do banco de dados.
Gerenciamento
distribudo
de
impasses
Se
mecanismo
de
sincronizao se basear em bloqueios, a competio entre usurios pelo

acesso a um conjunto de dados pode resultar em impasse. As alternativas
bem conhecidas de preveno, anulao e deteco tambm se aplicam a
SBDDs.
Confiabilidade de SGBDs distribudos Nos casos dos SBDDs, ocorrendo

um defeito em que um ou vrios sites fiquem inoperantes e sem acesso, os
bancos de dados existentes nos sites que permanecerem operacionais devem
continuar estveis e atualizados.
Suporte do sistema operacional O suporte oferecido pelos sistemas

operacionais para operaes de bancos de dados no corresponde
propriamente aos requisitos do software de gerenciamento dos bancos de
dados.
Os
principais
problemas
so
os
sistemas
de
arquivos,
gerenciamento de memria, os mtodos de acesso, a recuperao de falhas

e o gerenciamento de processos.
2.6.
ARQUITETURA DO BANCO DE DADOS ORACLE

De acordo com Watson (2010), a arquitetura do Oracle composta por uma
ou mais Instncias (Instance) e Banco de Dados (Database), conforme figura a

seguir:
22
Figura 3 - Arquitetura do Oracle
Databases so os armazenamentos fsicos do banco de dados no sistema

operacional, compostos por data files, control files, online redo log file, archive log,
etc.
Instncias so vrios processos rodando em background e na memria.
Dentro da instncia Oracle existe o SGA (System Global Area), que
composto por Database buffer cache, Redo Log buffer, Java pool, Streams Pool,
Large Pool e Shared Pool. Esta rea responsvel por compartilhar todos os
processos do servidor e de background, para compartilhar dados e informaes de
controle da instncia.
2.6.1. Funcionamento da Instance
Sempre que iniciada a instncia do Oracle, uma rea de System Global Area
(SGA) alocada, so iniciados os processos em background e a database
montada.
Aps iniciada a database ocorre a conexo do usurio (connection)
instncia Oracle, onde iniciada a sesso (session). Do lado do servidor a conexo
feita com o processo de servidor (Server process) e do lado do usurio com o
processo de usurio (User process).
23
2.6.2. Detalhamento da SGA

Conforme citado anteriormente a SGA composta por diversos itens, os
quais possuem o seguinte detalhamento:
Database Buffer Cache nesta rea ficam armazenados temporariamente
os blocos de dados que foram lidos dos data files com a finalidade de que na
prxima vez que os mesmos dados forem solicitados no haja a necessidade de
fazer I/O em disco para a busca de dados, fazendo com isso que o banco se torne
mais performtico.
Redo Log Buffer utilizado para registrar alteraes realizadas no banco de
dados. Possui a funo de possibilitar o refazimento de uma determinada ao que
possa ter sofrido algum tipo de problema. Os dados armazenados nessa rea, aps
serem persistidos em banco de dados so transferidos para disco no Online Redo
Log Files atravs do processo LogWrite (LGWR).
Shared Pool a rea utilizada para armazenar o dicionrio de dados,
estrutura de controle, instrues SQL e PL/SQL executados recentemente, cache de
resultado de funo e buffer de mensagens de execuo paralela.
2.6.3. Detalhamento da Database
Conforme demonstrado na Figura 1, assim como a SGA, a database tambm
composta por diversos outros itens conforme detalhamento a seguir:
Data files (Arquivos de dados) o conjunto de um ou mais arquivos onde
so armazenados os dados do Banco de Dados.
Control Files (Arquivo de controle) um arquivo binrio utilizado para
rastrear o status do banco de dados e a estrutura fsica.
Online Redo Log Files so arquivos de segurana que permitem que uma
instncia de Banco de Dados se recupere, caso haja alguma falha e no haja a
perda de nenhum arquivo de dados.
2.6.4. Processos em background
Database Write Process (DBWn) - responsvel por escrever o contedo do
Database Buffer Cache para o Data File.
24
LogWriter Process (LGWR) responsvel por gerenciar o Redo Log

Buffer, armazenando as entradas l contidas no Online Redo Log Files quando
executado o commit (confirmao) dos dados.
Checkpoint Process (CKPT) responsvel por marcar todos os datafiles e
controlfiles, utilizando timestamps, para indicar um ponto de recuperao em caso
de falha.
System Monitor Process (SMON) responsvel pela recuperao, se
necessria, na inicializao da instncia e pela limpeza dos segmentos temporrios
que no estejam em uso.
Process Monitor Process (PMON) responsvel por fazer a recuperao
quando um processo de usurio falhar, limpando cache no buffer do banco de dados
e liberando recursos que o processo de usurio estava utilizando.
Archiver Process (ARCn) responsvel por copiar os dados do Online
Redo Log Files para o Archived Log Files. Este processo s funcionar se o Banco
de Dados estiver configurado para o modo Archivelog e o arquivamento estiver
automatizado.
25
2.7.
STRUCTURED QUERY LANGUAGE (SQL)

De acordo com Machado e Abrei, a sigla SQL significa Structured Query
Language Linguagem estruturada de pesquisa.

A SQL a linguagem padro utilizada em bancos de dados relacionais, a qual
pode ser utilizada nos modos interativo e embutido.
A SQL chamada de interativa quando h a digitao de comandos e o
resultado visto logo em seguida. J a SQL embutida recebe este nome por ficar
dentro do cdigo fonte de uma linguagem de programao.
H a diviso da SQL nos grupos Linguagem de Definio de Dados (Data
Definition Language - DDL), Linguagem de Controle de Dados (Data Control
Language - DCL) e Linguagem de Manipulao de Dados (Data Manipulation
Language - DML).
Linguagem de Definio de Dados tem o objetivo de definir, alterar e
eliminar objetos de banco de dados, tais como tablespaces, tabelas, views,
constraints e outros.
Linguagem de Controle de Dados tem o objetivo de controlar os usurios
do banco de dados bem como o acesso aos seus recursos, mantendo a privacidade
de informaes importantes, a segurana de tabelas e o estabelecimento de
fronteiras. Os comandos Grant e Revoke so exemplos de comandos DCL.
Linguagem de Manipulao de Dados tem o objetivo de realizar a
manipulao de dados armazenados em tabelas. Os comandos Select, Update,
Insert e Delete so exemplos de comandos DML.
2.8.
REPLICAO DE DADOS ENTRE BANCOS DE DADOS DISTRIBUDOS

Replicao o nome dado ao processo sincronizao de dados (inseridos,
alterados ou excludos) entre dois ou mais servidores de banco de dados com

localizaes lgicas ou geogrficas diferentes, com a finalidade de que os dados
estejam sempre prontos para uso em mais de um servidor. Com isso, a empresa
ganha desempenho (os dados ficam mais prximos de quem os utiliza) e segurana
(alta disponibilidade). O perfeito funcionamento da sincronizao de dados depende
de que a estrutura de dados dos servidores seja semelhante e, s iniciada quando
o dado se torna consistente na base de dados.
Elmasry e Navate (2005) descrevem que A replicao til na melhoria da
disponibilidade dos dados. O caso mais extremo a replicao do banco de dados
26
inteiro em todos os sites do sistema distribudo, criando assim, um banco de dados

distribudo
completamente
replicado.
Isso
pode
melhorar
notavelmente
disponibilidade porque o sistema pode continuar operando desde que pelo menos
um site esteja em operao.
De acordo com Silberschatz, Korth e Sudarshan (2006), existem diversas
vantagens e desvantagens na replicao de dados.
Disponibilidade. Se um dos sites contendo os dados operacionais falhar,

ento estes mesmos dados podem ser encontrados em outro site. Desta
forma o sistema pode continuar o processamento da consulta, apesar da
falha de um site.
Paralelismo aumentado. Como todos os sites tero os mesmos dados,

as consultas realizadas geralmente ocorrero nos servidores da rede local
de cada cliente, com isso ser minimizada a movimentao de dados
entre os sites, melhorando a performance da rede que deixar de ficar
sobrecarregada.
Maior sobrecarga da atualizao. Para garantir que todas as rplicas

sejam consistentes exigido mais controle do SGBD. Assim sempre que
h uma atualizao necessria a atualizao do todos os demais sites,
com isso h uma maior sobrecarga para o sistema.
2.8.1. Modelo de Replicao

Segundo Silberschatz, Korth e Sudarshan (2006), o processo de replicao
dividido basicamente em dois tipos (sncrona e assncrona).
Replicao Sncrona (Eager). a replicao instantnea que ocorre no
momento do processamento da transao, a qual possui a vantagem de permitir que
os dados sejam atualizados em todas as rplicas de forma online, mas que em
contrapartida possui a desvantagem de comprometer a performance e no permitir
nenhum tipo de falha na rede. Neste tipo de replicao, quando h algum tipo de
falha a operao no concluda e o SGBD precisa fazer rollback na transao para
que o sistema no fique travado aguardando que o falha seja normalizada. Este tipo
de replicao mais apropriado para aplicaes comerciais (Ex. banco), onde
inevitvel que todos os servidores sejam atualizados ao mesmo tempo.
27
Para o uso da replicao sncrona indispensvel o uso de um meio de

transmisso de alta velocidade que garantam a eficincia e eficcia do processo, o
que gera custos muito elevados, o que no ocorre com o tipo assncrono.
Replicao Assncrona (Lazy). A replicao no ocorre de forma
instantnea. Neste modelo o replicador responsvel por montar um histrico das
aes que ocorrem no banco de dados e que devem ser replicadas entre as bases
de dados e, em um segundo momento ele se baseia neste histrico para gravar os
dados nas rplicas. Com isso este modelo agrega vrias vantagens: - O intervalo de
replicao pode ser programado no replicador, a transao ocorrer mesmo que
algum dos sites esteja inoperante e dependendo do volume de dados, no precisa
de uma grande quantidade banda de rede para sincronizar os dados, pois estes
podem ser replicados utilizando at mesmo uma linha discada, com acesso de hora
em hora do dirio.
2.8.2. Mtodos de Replicao
De acordo com Oliveira (2006), em sistemas de bancos de dados, toda
replicao requer os mecanismos de Log de Transaes e Triggers para para
realizar as alteraes feitas em dados replicados.
Log de transao copia as transaes marcadas para replicao para uma
rea de preparao para transmisso. Esta tcnica possui a vantagem de ter baixo
impacto no servidor porque exige o mnimo do uso de processador quando est
lendo o log em memria e escrevendo em disco.
Triggers propagam em uma tabela de log, as mudanas quando elas
ocorrem, para transmisso posterior.
Como a linguagem procedural da base de dados pode ser usada para estes
mtodos, ela prov maior flexibilidade em decidir quais os dados sero replicados.
Logs de transao e Triggers podem ser usados individualmente ou
conjuntamente em um SGBD, dependendo das caractersticas de cada sistema e de
suas aplicaes.
A vantagem de se usar Triggers que estas demandam menor tempo e
consomem menos recursos que os Logs de transao para realizar o processo de
replicao.
28
2.8.3. Conflitos de Replicao

A ocorrncia de conflito de replicao acontece quando o mesmo dado
atualizado em duas bases ao mesmo tempo.
Para assegurar a convergncia, os conflitos de atualizao devem ser
detectados e resolvidos para que o dado tenha o mesmo valor em cada base.
Quanto maior for a frequncia de propagao das mudanas de dados, menor ser
a incidncia de conflitos de atualizao.
Os conflitos de atualizao podem ser evitados pela limitao do direito de
atualizao
dado
um
elemento
para
uma
base.
Muitos
acreditam,
equivocadamente, que a resoluo de conflitos um processo que cabe ao

desenvolvedor de software. O software jamais precisar resolver conflitos, pois eles
nunca iro ocorrer se existir uma poltica de planejamentos e procedimentos para
eliminar essa possibilidade no prprio banco de dados.
De acordo com Coutinho (2002) sempre deve ser criado um ambiente de
replicao que evite a possibilidade de conflitos. Para que isso seja possvel
necessrio a utilizao de algumas tcnicas. Abaixo so listados alguns dos tipos de
conflitos que podem ocorrer, conforme a replicao utilizada:
Conflito de Update poder acontecer quando duas ou mais transaes,

originadas de bancos de dados diferentes atualizam um mesmo registro ao
mesmo instante. Este tipo de conflito pode ser reduzido ou at evitado
reduzindo o intervalo de tempo entre uma replicao e outra.
Conflito de Chaves nicas e seqenciais pode acontecer quando duas ou

mais transaes tentar fazer a insero de um registro com mesma chave
(Primary Key) ou (Unique Key) em uma mesma tabela, causando a violao
de integridade.
Conflito de Delete pode acontecer quando duas ou mais transaes

tentam, ao mesmo instante, deletar um registro com a mesma chave de
identificao. Neste caso s a primeira transao obter sucesso, pois no
momento em que a segunda for executada no encontrar mais o dado a ser
excludo.
29
2.9.
SOFTWARES DE REPLICAO
2.9.1. Dbmoto
um software replicador que oferece suporte para atualizao em tempo real,
suporte a qualquer tamanho de conjunto de dados, suporte a mltiplas bases de
dados e suporte a qualquer plataforma.
Este software possui a seguintes caractersticas:
Identificao dos dados modificados para minimizar o acesso aos bancos

de dados de origem e destino;
A capacidade de ler os logs de transao do banco de dados;
Suporte para transformao de dados; e,
Apoio integrao de dados com solues de Data Warehousing.
2.9.2. Oracle Goldengate

um replicador adquirido pela Oracle em 2009, que promove a integrao
rpida de dados em tempo real e a transformao de informaes em larga escala,
com alta confiabilidade, bem como a soluo de Business Intelligence (BI)
instantnea, melhoria no desempenho de OLTP e disponibilidade contnua (24x7)
dos dados para sistemas de misso crtica.
O Oracle Goldengate permite a movimentao de dados em tempo real entre
sistemas heterogneos de origem e destino, com sobrecarga mnima na
infraestrutura de TI, habilitando solues de BI em tempo real, sincronizao de
dados multidirecional para sistemas distribudos, atualizaes sem paralisaes no
sistema, recuperao de desastres e migraes entre diferentes bancos de dados,
plataformas de sistema operacional e servidores.
2.9.3. DBLink
um link criado em um banco de dados que possibilita acesso a outro banco
de dados, sendo ele Oracle ou no. Esta conexo pode ser homognea (mesmo
banco de dados) ou heterognea (banco de dados diferente), sendo que no Oracle
para o acesso heterogneo necessrio o uso do Oracle Heterogeneous Services.
Dependendo do nvel de privilgio do usurio do DBLink possvel fazer a
replicao de dados entre servidores, no entanto este aplicativo no pode ser
30
comparado a um replicador, pois bem limitado com relao desempenho, controle

de transao, automatizao e etc.
Usar esta ferramenta implica em assumir a rdua tarefa de fazer de forma
manual toda a complexa atividade que executada por um replicador. Portanto,
devido a estas limitaes, o DBLink mais indicado somente para consultas entre
bancos de dados distribudos.
2.9.4. Objectmmrs
uma sute de softwares para projetos de replicao de banco de dados, da
empresa Object Sistemas. Criado em 2002, o software evoluiu e tornou-se uma
verdadeira ferramenta multiuso de replicao de dados em tempo real de forma
bidirecional entre servidores remotos, mesmo que estes estejam usando SGBDs de
diferentes fabricantes.
A ferramenta possui tecnologia nacional e, o melhor: totalmente adaptado
s piores condies possveis de internet, possibilitando assim a troca eficiente de
dados mesmo em instveis e restritas bandas de rede de at inacreditveis 32Kbps.
um software capaz de trabalhar com bancos Oracle, DB2, SQL Server,
Postgresql, Firebird, HSQLDB, SQLite e Apache Derby.
As principais caractersticas do Objectmmrs so:
Backups em tempo real de banco de dados, replicando os dados de um
servidor principal para um servidor secundrio localizado na rede local ou
em outro local fsico.
Eliminao de rotinas de atualizao de dados em batch. Ao usar o produto
os dados so replicados em tempo real, continuamente, sem necessidade
de rotinas de exportao e importao de dados, etc. A sincronizao
tardia de dados fonte de muitos problemas, ao manter bases distintas
atualizadas em poucos segundos ao invs de, por exemplo, realizar
atualizaes dirias, eliminar muitas inconsistncias do dia-a-dia.
Replicao entre bancos de dados de diferentes fabricantes, como por
exemplo, a sincronizao de uma base de dados Oracle com uma base de
dados MySQL.
Importao de dados a partir de arquivos texto, planilhas, etc.
Replicao bidirecional e assncrona.
31
Resistncia e auto-recuperao em casos de falhas de rede ou de banco

de dados.
Possibilidade de implementao em diversas topologias de rede, tais como
estrela, hierrquica, ponto-a-ponto e etc.
Arquitetura multi-thread e multi-engine, imprescindvel em topologias do
tipo estrela onde h um servidor central e N servidores nas pontas, de
modo a permitir a replicao para um grande nmero de slaves.
Baixo overhead nos servidores de banco de dados, o software de
replicao pode ser instalado no prprio servidor de banco de dados, sem
com isso comprometer o desempenho do servidor. Pode tambm,
opcionalmente, em casos crticos, ser instalado em um ou mais servidores
separados.
Replicao a nvel de tabela e de operao (insert, update, delete).
Na
replicao
de
update
atualiza
apenas
as
colunas
alteradas,
economizando assim banda de rede e minimiza conflitos de concorrncia.

Tratamento automtico de conflitos de update, por tempo real ou prioridade
de base de dados.
Customizvel, pois o cliente pode desenvolver classes java usadas para
replicar casos especiais, como por exemplo, replicao para um
middleware usando webservices, replicao de arquivos como fotos e
vdeos via tunel ssh/sftp, etc.
Possuiu log detalhado e configurvel das operaes DML nos nveis:
DEBUG, INFO, WARN, ERROR e FATAL.
uma ferramenta multiplataforma, podendo ser instalado com facilidade
em Windows, Linux, Unix, Mac e etc, desde que a plataforma permita o
uso de Java 5 ou superior.
Pode ser usado como ferramenta de sincronizao de bases de dados em
notebooks, PDAs e etc.
Pode ser configurado para o envio de email automtico em caso de falhas
de rede prolongadas, etc. A sada do log pode ser integrada com
ferramentas de monitoramento de syslogs.
No usa recursos de baixo nvel dos SGBDs, extremamente portvel
entre diferentes verses de um mesmo SGBD, facilitando assim upgrades
32
de verso do SGBD.
preparado para a replicao de grandes volumes de dados, como por
exemplo, a partir de 500 mil operaes chegando com bom desempenho a
milhes de operaes por dia.
uma tecnologia nacional, com possibilidade de customizaes com
desenvolvimento e suporte tcnico local.
Quanto replicao de DDL, o software possui uma interface web de
aministrao da ferramenta, que oferece a opo de disparar a execuo de
comandos SQL, sejam eles DDL ou DML entre todos os sites cadastrados no
modelo. Aps a execuo possvel avaliar o log de execuo nos servidores
utilizados para a execuo dos comandos.
2.9.5. DBReplicator
uma API de replicao que possui como caractersticas mais significativas:
Replicao heterognea, ou seja, sincroniza dados entre o mesmo tipo de
banco de dados ou entre outros bancos de dados;
Replicao bi-direcional;
A plataforma 100% Java;
Independncia da aplicao, ou seja, o software no precisa conhecer da
replicao, nem acessar a fonte de dados de forma diferente, o que
importante para aplicativos que no tem acesso ao cdigo fonte;
Deteco automtica de conflitos de resoluo;
Facilidade de agendamento, onde o cronograma pode ser especificado por
minutos, horas, etc, e executa a operao desejada sempre no intervalo
especificado, a menos que haja algum erro.
Depurao Verbose, que implementado usando apache log4j, pode ser
bastante flexvel em termos de produo.
Tratamento
de
caracteres
especiais.
Atualmente,
esses
campos
que contenham caracteres especiais devem ser especificados no

EncodeConfig.ini, para o correto tratamento automtico.
Criao, caso no existam, as tabelas no assinante site slave.
33
2.9.6. Replication Server

um software de replicao que trata os dados independentes do tipo de
banco de dados, tanto na origem ou destino, enquanto mantm como prioridade o
desempenho e estabilidade.
Esta ferramenta possui as seguintes caractersticas:
Garante a recuperao em caso de desastres, sem interrupes para as
aplicaes crticas do negcio.
Evita impacto no desempenho do banco de dados operacional e captura as
mudanas em tempo real para em seguida replic-las.
Suporta replicao multi-master em ambiente heterogneo de banco de
dados,
em
diferentes
localizaes
geogrficas,
garantido
alto
disponibilidade dos dados operacionais onde e quando precisar.

Permite a migrao de Sistema Operacional ou plataforma de banco de
dados, sem a necessidade de interrupo das operaes.
Suporta replicao entre vrias plataformas de banco de dados, incluindo
Sybase ASE, Oracle, DB2 IBM e Microsoft SQL Server.
34
3.
METODOLOGIA
3.1.
METODOLOGIA UTILIZADA
O processo de pesquisa deste trabalho pode ser classificado sob os seguintes
aspectos:
Quanto natureza, ela aplicada, uma vez que "o investigador movido pela
necessidade de contribuir para fins prticos mais ou menos imediatos, buscando
solues para problemas concretos. [CERVO e BERVIAN, 1996, p. 47].
Do ponto de vista dos objetivos, ela exploratria, pois visa proporcionar
maiores informaes sobre determinado assunto; facilitar a delimitao de um tema
de trabalho; definir os objetivos ou formular as hipteses de uma pesquisa ou
descobrir novo tipo de enfoque para o trabalho que se tem em mente. De acordo
com Bonoma (1985), o mtodo do Estudo de Caso tem sido visto mais como um
recurso pedaggico ou como uma maneira para se gerar 'insights' exploratrios, do
que um mtodo de pesquisa propriamente dito e isto tem ajudado a mant-lo nesta
condio.
Quanto aos procedimentos, ela bibliogrfica, pois, utiliza fontes secundrias,
ou seja, livros e outros documentos bibliogrficos. [ANDRADE, 2007, p. 115].
3.2.
PLANEJAMENTO DE CRIAO DO BANCO DE DADOS DISTRIBUDO

Neste tpico, abordaremos o modelo utilizado para o experimento prtico de
criar, executar e manipular um BDD.

3.3.
MODELO DE DADOS
3.3.1. Modelo entidade-relacionamento

O Modelo Entidade Relacionamento (MER) uma extenso do modelo
conceitual de dados, o qual foi introduzido por Peter Chen em 1976. (SETZER e
SILVA, 2005)
Segundo Chen, a viso de uma dada realidade baseia-se no relacionamento
entre entidades, o qual retrata os fatos que governam essa mesma realidade, e cada
um (entidade ou relacionamento) pode possuir atributos (qualificadores desta
realidade). (MACHADO e ABREU, 2010)
Chen se dedicou a destacar a importncia de reconhecer os objetos que
compem
cada
negcio
independente
35
de
tratamento
de
informaes,
procedimentos, programas, tecnologia, etc. Estes objetos ele classificou em dois

grupos: Entidades e Relacionamentos, onde:
a. Entidades aquele objeto que existe no mundo real com uma
identificao distinta e com um significado prprio. So coisas que
existem no negcio, ou ainda, descrevem o negcio em si. (MACHADO
e ABREU, 2010).
b. Relacionamentos o fato, o acontecimento que liga dois objetos, duas
coisas existentes no mundo real (duas entidades). (MACHADO e
ABREU, 2010)
Abaixo apresentada a ttulo de exemplo a representao grfica de um
MER simples, no qual so apresentados duas entidades (Departamento e
Funcionrio) e um relacionamento (Ter).
Figura 4 - Exemplo de MER Simples
3.4.
ETAPAS PARA O DESENVOLVIMENTO E IMPLMENTAO

A construo de um SBDD exige bastante conhecimento do negcio, alm de
muitos estudos e anlises na fase de projeto e exaustivos testes antes da total

implementao, tudo isto para garantir que o sistema ser estvel e confivel e que
a complexidade de sua implementao ser transparente para o usurio final. Por
este motivo sero respeitadas as seguintes etapas:
a. Preparao do modelo de dados Nesta etapa do projeto ser preparado
o modelo de dados que retrate uma amostragem das entidades contidas
no negcio. Sero mapeadas algumas das diversas entidades, seus
respectivos atributos e relacionamentos, de forma a dar visibilidade
parcial do modelo de dados.
b. Definio da poltica de sincronizao e carga de dados ser definido,
com base no modelo de dados preparado na etapa anterior.
c. Definio das entidades operacionais que sero sincronizadas entre os
sites, de forma a manter a integridade, segurana e acessibilidade aos
dados.
36
d. Implementao da ferramenta de replicao Nesta etapa ser definida a

melhor forma de se fazer os processos de acesso aos dados encontrados
no SBDD tanto para consulta quanto para atualizao.
3.5.
CONTEXTUALIZAO DO ESTUDO DE CASO

A PREVIDAS uma empresa de previdncia complementar, sem filiais e com
a estrutura de banco de dados centralizada, esta empresa est sujeita ao

cumprimento
de
normas
regulamentares
da
Secretaria
de
Previdncia
Complementar, para que honre fielmente o seu propsito final que o pagamento de
aposentadoria para seus contribuintes.
Como esta empresa possui certificao ISO 9001/2008, sofre auditorias de
qualidade constantemente e alvo de observao de seus contribuintes, auditores
independentes, auditores dos patrocinadores e de seus rgos regulamentadores,
existe uma forte preocupao de sua Diretoria com relao Segurana da
Informao e a Gesto de Continuidade do Negcio. A partir desta preocupao,
surgiu a necessidade de se iniciar um projeto de replicao do banco de dados em
mais de uma localidade, com a finalidade de garantir que se houver algum tipo de
problema na sede, seja possvel o acesso aos dados em locais alternativos para a
continuidade das atividades normalmente.
A sede da empresa utiliza SGBD Oracle 10G, e os sites alternativos, tambm
utilizaro Oracle 10G. A replicao ser assncrona e abranger qualquer tipo de
alterao de dados ocorrida em algum dos sites, os quais faro atualizao entre si.
3.6.
PROCEDIMENTO DE PESQUISA
Todo o processo ocorre com embasamento no disposto na reviso literria,
anlise para preparao do ambiente de testes, preparao do ambiente, testes e

auditoria dos resultados.
37
4.
ESTUDO DE CASO
Nesta etapa ser criado um laboratrio com um Sistema de Gerenciamento
de Banco de Dados Distribudo homogneo (Oracle 10G) que simular o ambiente

da empresa de previdncia complementar (sede) e dois sites alternativos de
replicao, os quais tero os dados replicados entre si de forma automtica, a partir
da implementao de um software de replicao de Banco de Dados confivel que
atenda a tal necessidade.
4.1.
DIAGRAMA DA SOLUO
O projeto ser composto de trs sites alocados em diferentes pontos
geogrficos, os quais sero interligados atravs de links ponto a ponto de fibraptica com velocidade de trfego full de 2 Mbps.
A distncia aproximada dos dois sites alternativos para a sede entre 1 e 3
quilmetros.
As alteraes realizadas na sede sero replicadas para os dois sites
alternativos. J as alteraes dos sites alternativos s sero replicadas para a sede
e nunca entre eles, conforme demonstrado no diagrama a seguir. Todo esse
processo de replicao ocorrer de forma assncrona.
Matriz
Nome do host: mmrs1
Usurios Oracle:
.objectmmrs1 proprietrio do dicionrio de dados do replicador;
.mmrs - proprietrio das tabelas que sero replicadas para os hosts mmrs2 e mmrs3;
.repmmrs2 - usurio utilizado pelo host mmrs2 para fazer replicao para este servidor;
Localidade: SCN Q. 01 - Braslia - DF
Ethernet Gigabit Cat6
Fibra ptica
2 Mbps Full Duplex
Sentido da replicao
Sentido da replicao
Internet
Fibra ptica
2 Mbps Full Duplex
Fibra ptica
2 Mbps Full Duplex
Site Alternativo 1
Nome do host: mmrs2
Usurios Oracle:
.mmrs - proprietrio das tabelas que sero replicadas para os hosts mmrs1;
Localidade: 904 Sul - Braslia DF
Distncia de mmrs1: 3 Km
Site Alternativo 2
Nome do host: mmrs3
Usurios Oracle:
.mmrs - proprietrio das tabelas que sero replicadas para os hosts mmrs1;
Localidade: SCN Q. 04 - Braslia DF
Distncia aproximada de mmrs1: 1 Km
Figura 5 Diagrama da soluo de replicao
38
4.2.
SGBD UTILIZADO
Para este projeto sero utilizados, tanto na sede quanto nos sites alternativos
o Oracle 10G Express Edition Release 10.2.0.1.0.

4.3.
INFRA-ESTRUTURA
Para simular o ambiente da PREVIDAS sero utilizados servidores virtuais,
criados com o Virtualbox, os quais sero hospedados em um servidor com as

seguintes caractersticas:
Processador CORE I5 3.0GHz;
Disco Rgido de 1TB - 7200RPM;
Memria RAM de 16 GB;
Linux Debian 6 (Kernel 2.6.39.4 compilado para 64 GB de memria RAM); e,
Virtualbox 4.0.12.
Os servidores virtuais tero configuraes bsicas, que serviro para simular
o processo de replicao, sem comprometimento do desempenho, conforme as
caractersticas a seguir:
Sede
Servidor de Banco de Dados
Nome de Host: mmrs1
IP: 192.168.1.171 / Mscara de Rede: 255.255.255.0
Sistema Operacional Linux Debian 6;
SGBD Oracle 10G Express; e
Memria RAM de 2 GB.
Site Alternativo 1
Nome de Host: mmrs2
IP: 192.168.1.172 / Mscara de Rede: 255.255.255.0
Memria RAM de 2 GB.
39
Site Alternativo 2
4.4.
Nome de Host: mmrs3
IP: 192.168.1.173 / Mscara de Rede: 255.255.255.0
Memria RAM de 2 GB.
DESCRIO DA SOLUO
A alternativa encontrada para proporcionar segurana aos dados operacionais
da PREVIDAS e atender aos requisitos de Gesto de Continuidade do Negcio

desta empresa, foi seguir as melhores prticas de mercado, adotando a tecnologia
de banco de dados distribudos e a replicao de banco de dados, o que trar
grandes benefcios, pois os dados ficaro mais protegidos e, mesmo que acontea
algum tipo de problema ou at mesmo uma catstrofe em algum dos sites, sempre
haver mais duas cpias idnticas para a continuidade das atividades de forma
transparente para os usurios.
Atualmente existem no mercado vrias ferramentas de replicao de banco
de dados, cada uma com suas caractersticas tcnicas e preos que variam bastante
de uma para a outra. Para a deciso da ferramenta que seria utilizada nesta
soluo, foi elaborada uma tabela comparativa, demonstrada logo a seguir, onde
foram seguidos alguns critrios de avaliao e aprovao:
Anlise da ferramenta GoldenGate, a qual nativa do SGBD Oracle;
Anlise de outras ferramentas replicadoras de Banco de Dados, paralelas

ao GoldenGate, disponveis no mercado; e,
Avaliao de custo benefcio de cada uma das ferramentas analisadas.
40
Item de avaliao
DBMoto
Oracle
DBLink
ObjectMMRS
SIM
SIM
DBReplicator
GoldenGate
Compatvel com Oracle
SIM
SIM
SIM
(Mas no testado)
Replicao Multi-master
SIM
SIM
SIM
SIM
SIM
Replicao Assncrona
SIM
SIM
NO
SIM
SIM
Deteco e controle de conflitos de
SIM
SIM
NO
SIM
SIM
Uso de criptografia SSL
SIM
SIM
NO
SIM
NO
Captura de alterao dos dados
NO
SIM
NO
SIM
SIM
SIM
SIM
NO
SIM
SIM
Replicao de DDL
NO
SIM
NO
SIM
NO
Proteo de usurios e senhas de
SIM
SIM
NO
SIM
NO
NO
SIM
NO
SIM
NO
Arquitetura Multi-thread
SIM
SIM
NO
SIM
SIM
compatvel com servidor Linux
NO
SIM
SIM
SIM
SIM
compatvel com servidor Windows
SIM
SIM
SIM
SIM
SIM
Ferramenta
SIM
SIM
NO
SIM
NO
R$
R$
R$ 0,00
R$ 1.000,00
R$ 0,00
12.000,00
20.000,00
(Nativo)
update
baseados em triggers padro do

banco de dados
Ferramenta de sincronizao de
tabelas
banco de dados, no expondo os

arquivos de configurao ou setup
de tabelas
Ferramenta de monitoramento que
pode enviar emails e sms alertando
os mecanismos de replicao de
banco de dados indisponveis
enterprise
de
com
monitoramento
interface
web
habilitada para controle de vrios

projetos diferentes de replicao
Preo Anual
(Open Source)
Tabela 1 - Matriz de Comparao de Replicadores
O item preo anual, demonstrado na sede acima para servir de referncia

para este estudo, pois varia de projeto para projeto por depender de diversas
variveis, como por exemplo, a quantidade de tabelas a replicar, quantidade de
conectores de bancos diferentes necessrios, volume dirio de dados, se precisar
ou no de criptografia, se haver redundncia de links e etc.
Com relao anlise tcnica, todas as ferramentas possuem grande
potencial para atender soluo da PREVIDAS, com exceo do DBLink que seria
uma soluo lenta, trabalhosa e complicada de administrar. Aps anlise dos itens
41
de avaliao da tabela de comparao, foi identificado que as ferramentas mais

completas para a soluo so o Oracle Goldengate e o ObjectMMRS.
O ObjectMMRS da Object Sistemas foi escolhido como a soluo ideal pelo
seu baixo custo e pela robustez apresentada para o processo de replicao. Este
ser utilizado para replicar toda e qualquer operao de insero, alterao e
excluso de dados que houver em algum dos sites do projeto.
Para o funcionamento do processo de replicao este software utiliza o
controle do dicionrio de dados prprio da ferramenta, criado especificamente para
esta finalidade.
Todas as informaes de insero, alterao e excluso so armazenadas
em tabelas temporrias e excludas aps a concluso, com sucesso, do processo de
replicao dos dados l armazenados.
O modelo de dados da PREVIDAS constitudo de aproximadamente 800
tabelas, as quais devem ser 100% replicadas entre os sites. Neste projeto est
sendo feita uma amostragem de somente 4 tabelas (modelo abaixo), que serviro
para demonstrar o uso da ferramenta de replicao.
MMRS_CONTRATOSEPT
MMRS_CLIENTES
MMRS_CLMATR
MMRS_EMPCOD
MMRS_CLINM
MMRS_CLINMPAI
MMRS_CLINMMAE
MMRS_CLIDTNASC
MMRS_CLISX
MMRS_CLICPF
MMRS_CLIIDT
MMRS_CLIOEXIDT
MMRS_CLIDTEMIIDT
MMRS_CLILOGR
MMRS_CLINRLOGR
MMRS_CLICOMPLOGR
MMRS_CLIBAIR
MMRS_CLICID
MMRS_CLICEP
MMRS_CLIUF
MMRS_CLITEL
MMRS_CLITELCOM
MMRS_CLITELCEL
MMRS_CLIEMAIL
MMRS_CLIDTSIS
CHAR(9)
<pk>
CHAR(3)
<pk,fk>
VARCHAR2(45)
VARCHAR2(40)
VARCHAR2(40)
DATE
CHAR(1)
CHAR(11)
VARCHAR2(13)
VARCHAR2(10)
DATE
VARCHAR2(60)
VARCHAR2(5)
VARCHAR2(30)
VARCHAR2(30)
VARCHAR2(40)
CHAR(8)
CHAR(2)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(16)
VARCHAR2(45)
DATE
CONTRATA
MMRS_CTTCOD
MMRS_CLMATR
MMRS_EMPCOD
MMRS_CTTDTSOL
MMRS_CTTDTCOS
MMRS_CTTDTBAS
MMRS_CTTQTPRZ
MMRS_CTTVRSOL
MMRS_CTTVRLIQ
MMRS_CTTVRSDODVDINI
MMRS_CTTSITEPT
MMRS_CTTDTCAN
MMRS_CTTSITPAG
MMRS_CTTDTLIQ
MMRS_CTTSDODVDATU
MMRS_CTTDTULTMOV
CHAR(10)
<pk>
CHAR(9)
<fk>
CHAR(3)
<fk>
DATE
DATE
DATE
NUMBER(6)
NUMBER(15,8)
NUMBER(15,8)
NUMBER(15,8)
CHAR(2)
DATE
CHAR(1)
DATE
NUMBER(15,8)
DATE
CALCULA
MMRS_PARCELASEPT
MMRS_PCLMESREF
MMRS_CTTCOD
MMRS_PCLNUM
MMRS_PCLSIT
MMRS_PCLDTPAG
MMRS_PCLSDODVDANT
MMRS_PCLCOB
MMRS_PCLPAG
MMRS_PCLJUR
MMRS_PCLCORMON
MMRS_PCLMORA
MMRS_PCLJURMORA
MMRS_PCLCORMORAPG
MMRS_PCLMORAPG
MMRS_PCLJURMORAPG
MMRS_PCLCMPG
MMRS_PCLSDODVDATU
MMRS_PCLVLRFUT
TRABALHA
MMRS_EMPRESAS
MMRS_EMPCOD CHAR(3)
<pk>
MMRS_EMPDESC VARCHAR2(50)
Figura 6 Diagrama Fsico do Banco de Dados
42
CHAR(6)
<pk>
CHAR(10)
<fk>
NUMBER(3)
CHAR(1)
DATE
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER(12,2)
NUMBER
NUMBER(12,2)
4.5.
RESOLUO DE CONFLITOS NO PROCESSO DE REPLICAO

Conforme citado no item 2.9.4, a ferramenta ObjectMMRS, escolhida neste
projeto para replicao, possui o tratamento automtico de conflitos de update, por

tempo real ou prioridade de base de dados.
Para que a ferramenta funcionasse adequadamente conforme o previsto pelo
fabricante foi necessria a sincronizao de horrio com servidores NTP (Network
Time Protocol), para garantir que a hora dos servidores de replicao e de banco de
dados sempre estejam sincronizados de acordo com a hora atual do observatrio
nacional, evitando assim conflitos de update, insert e delete que comumente
ocorrem em replicadores multi-master sem horrios sincronizados.
4.6.
CRIAO DO PROCESSO DE REPLICAO

Para instalao do replicador foi necessrio solicitar empresa Object
Sistemas, uma verso Trial da ferramenta ObjectMMRS, e descompact-la no

diretrio home do usurio de sistema operacional object, criado especificamente
para
este
projeto.
estrutura
de
diretrios
do
replicador
ficou
/home/object/objectmmrs.
Todos os servidores que desempenharo o papel de master (replicador)
precisaro da ferramenta ObjectMMRS instalada neles.
Em conformidade com o manual, no banco de dados ser necessrio criar no
mnimo trs usurios, sendo um proprietrio do dicionrio de dados do replicador
(objectmmrs), um usurio que ser o proprietrio das tabelas a serem replicadas
(mmrs) e um usurio que ser utilizado por outro servidor master para replicar dados
para este (repmmrs), quando este estiver no papel de slave, conforme detalhado na
figura seguinte.
43
Matriz
Nome do host: mmrs1
Usurios Oracle:
.objectmmrs1
.mmrs
.repmmrs2
.repmmrs3
Replicao utilizando
o usurio repmmrs2
Replicao utilizando
o usurio repmmrs1
Replicao utilizando
o usurio repmmrs3
Replicao utilizando
o usurio repmmrs1
Site Alternativo 1
Nome do host: mmrs2
Usurios Oracle:
.objectmmrs2
.mmrs
.repmmrs1
Site Alternativo 2
Nome do host: mmrs3
Usurios Oracle:
.objectmmrs3
.mmrs
.repmmrs1
Figura 7 - Usurio de Banco de Dados
Conforme o diagrama acima, todos os bancos de dados deste projeto sero

multimaster, ou seja, replicaro e recebero replicao. Por este motivo, em cada
servidor precisar existir no mnimo os usurios citados no pargrafo acima. Logo
adiante so demonstradas as telas com todo o processo de criao de um servidor
de replicao.
Redimensionamento da tablespace System pelo fato do tamanho default do
Oracle Express (350 MB) no suportar uma grande quantidade de operaes
realizadas neste projeto. O replicador trabalhar mais estvel se for utilizada uma
tablespace com bastante espao, como o deste caso, que foi redefinida para 3GB.
44
Figura 8 - Redefinio de tamanho da tablespace System
Criao do usurio (mmrs) proprietrio das tabelas que sero replicadas aos
sites alternativos, objectmmrs1 (proprietrio do dicionrio de dados do replicador),
repmmrs2 e repmmrs2 (que sero utilizados pelos sites alternativos 1 e 2 para
replicar dados para este servidor sede).
45
Figura 9 - Criao dos usurios do Banco de Dados
46
Criao das tabelas do usurio mmrs, as quais sero replicadas para os

servidores slaves dos sites alternativos.
Figura 10 - Criao das tabelas que sero replicadas
Concesso de privilgios aos usurios de banco de dados (repmmrs2,

repmmrs3 e objectmmrs1), para que possam manipular as pertencentes ao usurio
mmrs, as quais sero replicadas.
47
Figura 11 - Concesso de privilgios aos usurios de banco
Alm dos privilgios j concedidos, pr-requisito da ferramenta que o

usurio proprietrio do dicionrio de dados (objectmmrs1) do replicador possua
privilgio de create any trigger.
Figura 12 - Concesso de privilgio de "Create Any Trigger"
48
Criao do dicionrio de dados do replicador em conformidade com o manual

da ferramenta de replicao, a qual prev um diretrio para cada tipo de Banco de
Dados
ser
configurado.
Neste
caso
diretrio
do
Oracle
/home/object/objectmmrs/sql/oracle, onde esto os arquivos a serem executados

(or_master_schema.sql e or_setup.sql).
Figura 13 Arquivos de criao do Dicionrio de Dados
Execuo dos scripts de criao do dicionrio de dados do replicador

(or_master_schema.sql).
Figura 14 - Execuo do Script de Criao do Dicionrio de Dados
49
Execuo do script de carga inicial nos parmetros do dicionrio de dados do

replicador.
Figura 15 - Carga inicial do Dicionrio de Dados
Criao das tabelas de log de replicao, conforme previsto no manual, com

base nas tabelas modelo (or_tb_logoutput e or_tb_logoutput_t), criadas pelo script
do dicionrio da dados do replicador. As tabelas que esto sendo criadas so
or_tb_logoutputmmrs2/ or_tb_logoutputmmrs2_t, as quais armazenaro os logs os
dados
serem
replicados
ao
servidor
alternativo
mmrs2
as
tabelas
or_tb_logoutputmmrs3/ or_tb_logoutputmmrs3_t, as quais armazenaro os logs dos

dados a serem replicados ao servidor alternativo mmrs3.
50
Figura 16 - Criao das tabelas de Log de replicao
Concesso de privilgio de select para os usurios repmmrs2 e repmmrs3,

nas tabelas or_tb_* e select e alter nos sequences or_seq_*.
Figura 17 - Grants no dicionrio de dados para os usurios de replicao
51
Concesso de privilgio de select, insert, update e delete para o usurio

mmrs, nas tabelas or_tb_* e select e alter nos sequences or_seq_*.
Figura 18 - Grants no dicionrio de dados para o proprietrio das tabelas
Aps a preparao do dicionrio de dados do replicador, necessrio

configurar a aplicao no servidor Linux.
Originalmente os arquivos disponibilizados no esto prontos para execuo
no Linux ento necessrio prepar-los antes do uso, tornando-os executveis,
conforme segue (Figuras 19 e 20).
Figura 19 - Tornando scripts Executveis
52
Convertendo os arquivos *.properties e *.sh para o formato Unix.
Figura 20 - Converso de arquivos para o formato Unix
Agora que foi tudo devidamente preparado iniciado o processo de

configurao
do
replicador.
Inicialmente
sero
objectmmrs.properties e objectdb.properties.
Figura 21 - Arquivo objectmmrs.properties
53
configurados
os
arquivos
No parmetro databases devem ser identificados todos os servidores que

participaro do processo de replicao. Neste caso, master o servidor que est
enviando a replicao (mmrs1 neste caso), slave1 ser o servidor mmrs2 e slave2 o
servidor mmrs3. Estes nomes so super importantes e devem estar em
conformidade com a parametrizao realizada nas tabelas or_tb_config (master) e
or_tb_client (slaves).
Figura 22 Arquivo objectdb.properties (Parmetro databases)
Nas linhas seguintes so detalhadas as propriedades do master e dos slaves,

as quais precisam ter alguns parmetros ajustados: dtbType, dtbDriver, dtbUrl,
dtbDAC e connectionTestStatement, deixando conforme abaixo (Figuras 22, 23 e
24).
Figura 23 - Arquivo objectdb.properties (Parmetro do master)
54
Figura 24 - Arquivo objectdb.properties (Parmetro do Slave1)
Figura 25 - Arquivo objectdb.properties (Parmetro do Slave2)
Para o funcionamento da ferramenta foi baixado no site da Oracle o driver de

conexo ojdbc14.jar, o qual foi alocado no diretrio /home/object/objectmmrs/lib/
do Linux. Aps isso a configurao do CLASSPATH foi realizada conforme
instrues do manual.
55
Figura 26 - Configurao do Classpath (Conforme Manual)
A figura abaixo apresenta uma configurao alternativa do Classpath, a qual

realizada no profile do Linux para garantir que a varivel sempre seja setada e
exportada para o Sistema Operacional independente sempre que este for carregado.
Figura 27 - Export do Classpath no Profile do Linux
Neste momento possvel a realizao de um teste preliminar para teste de

conexo com as base de dados utilizando o script contest.sh do replicador.
Figura 28 - Teste preliminar de conexo com as bases de dados
O teste acima foi realizado parcialmente com sucesso, pois a avaliao

apresentou o status de OK para a conexo com a base de dados master, no entanto
no conectou com nenhuma slave pelo fato no haver nenhum registro na tabela
or_tb_client do dicionrio de dados do replicador. Isto ser solucionado aps a
concluso dos passos seguintes.
56
Edio do arquivo publicar.sh que se encontra no diretrio raiz do replicador,

preenchendo os parmetros em conformidade com o manual da ferramenta.
Figura 29 - Arquivo Publicar.sh
Execuo do script publicar.sh, aps a edio realizada na figura acima, o

qual gerou o arquivo publicar.sql, que se trata das triggers de replicao que devem
ser criadas.
Figura 30 - Execuo do script publicar.sh
Viso parcial do arquivo publicar.sql:
Figura 31 - Viso parcial do arquivo publicar.sql
57
Publicao das tabelas que sero replicadas e criao das triggers no

dicionrio de dados do replicador, com os dados contidos no arquivo publicar.sh
(Figura 30).
Figura 32 Criao de Triggers de replicao
58
Registro dos slaves na tabela or_tb_client do dicionrio de dados.
Figura 33 - Cadastro dos servidores slaves de replicao
O teste de conexo preliminar (figura 27) apresentou problema de conexo

com os slaves porque eles no estavam cadastrados na tabela or_tb_config do
replicador. Como no passo acima (figura 33) foi realizado o cadastramento dos
slaves, possvel realizar um novo teste para identificar que o resultado ser OK
tanto para o servidor master quanto para os slaves.
Figura 34 - Teste final de conectividade entre servidores
59
Cadastramento das assinaturas conforme script disponibilizado no manual de

instalao do replicador.
Figura 35 - Cadastramento de Assinaturas
Aps estas configuraes, o servio de replicao foi iniciado com a execuo

do script ./run.sh, o qual se encontra no diretrio raiz do replicador
(/home/object/objectmmrs).
Todas as configuraes realizadas na sede foram tambm realizadas nos sites

alternativos com a finalidade de haver a replicao bidirecional.
60
4.7.
TESTES DE REPLICAO
Com a finalidade de validar se o processo de replicao est ocorrendo
adequadamente entre todos os sites, a seguir so realizadas algumas operaes de

Insert, Update e Delete em um servidor master de cada vez e, em seguida est
sendo avaliado se os eventos esto se replicados aos demais servidores slaves. Em
cada figura est destacado com um retngulo o servidor que est sofrendo a
alterao ou ajuste.
4.7.1. Operaes de Insert.
Insero de um registro na tabela mmrs_empresas do servidor mmrs1 a
verificao do dado utilizando o select.
Figura 36 Insero e Consulta em mmrs1
Consulta da tabela mmrs_empresas no servidor mmrs2 para verificar se o

registro replicado pelo servidor mmrs1 foi gravado com sucesso.
61
Figura 37 - Consulta em mmrs2
Consulta da tabela mmrs_empresas no servidor mmrs3 para verificar se o

registro replicado pelo servidor mmrs1 foi gravado com sucesso.
Insero de mais um registro na tabela mmrs_empresas do servidor mmrs2 e

a respectiva consulta atravs de select.
62
Figura 39 - Insero e Consulta em mmrs2
Insero de um registro na tabela mmrs_empresas do servidor mmrs3 e

verificao do registro inserido.
Figura 40 - Insero e Consulta em mmrs3
63
Consulta ao servidor mmrs1, no qual est evidente que os registros inseridos nos
servidores mmrs2 e mmrs3 j foram enviados pelos replicadores daqueles sites e j esto
disponveis na tabela deste servidor.
Consulta ao servidor mmrs2 e identificao de que o registro inserido em mmrs3 j

est disponvel neste servidor.
64
Consulta ao servidor mmrs3 e identificao de que o registro inserido em

mmrs2 j est replicado para este servidor.
4.7.2. Operaes de Update

Alterao de registro no servidor mmrs3, para testar a propagao das
operaes de update.
Figura 44 - Alterao e Consulta aos Dados
65
Consulta no servidor mmrs1 para verificar se o registro (001) alterado no

servidor mmrs3 foi replicado corretamente.
Figura 45 - Consulta de dado alterado replicado ao mmrs3
Consulta no servidor mmrs2 para verificar se o registro (001) alterado no

servidor mmrs3 foi replicado corretamente
Figura 46 - Consulta de dado alterado replicado ao mmrs2
66
4.7.3. Operaes de Delete

Excluso de registro no servidor mmrs2, para testar a propagao das
operaes de delete.
Figura 47 - Excluso e consulta a dados
Consulta no servidor mmrs1 para verificar se o registro (002) excludo no

Figura 48 - Consulta a replicao em mmrs1
67
Consulta no servidor mmrs3 para verificar se o registro (002) excludo no

Figura 49 - Consulta a replicao em mmrs3
De acordo com os testes realizados nesta fase, o replicador funcionou

corretamente o que indica que todo o processo de configurao foi feito em
conformidade com o manual da ferramenta.
4.8.
DESEMPENHO DO REPLICADOR
No processo de validao do replicador foram realizados diversos testes com
as operaes DML (update, delete e insert), com uma amostragem de 807 registros
sendo replicados para um dos sites alternativos, devido ao limite de operaes de
replicao da ferramenta estar limitada a 1000 em sua verso Trial. Todos os
processos funcionaram adequadamente, conforme previsto pela ferramenta.
Antes do incio do processo de carga no servidor da sede, foi iniciado no
Linux o processo responsvel pela replicao (/home/object/objectmmrs/run.sh) e
em seguida iniciado o processo de carga das tabelas, conforme demonstrado nas
figuras a seguir:
68
Figura 50 - Tabelas a serem replicadas vazias as 10:51:36
Na figura acima so demonstradas as tabelas de todos os sites (sede mmrs1, site alternativo 1- mmrs2 e site alternativo 2 - mmrs3).
Devido a limitaes da ferramenta Trial, ser demonstrada a replicao de
807 registros para apenas um dos sites alternativos.
Figura 51 - Realizao da Carga no site mmrs1
Na figura acima est sendo demonstrado o andamento do processo de carga

no servidor da sede e logo adiante a so apresentadas as tabelas da sede
69
devidamente carregadas e do site alternativo com seus dados j recebidos da sede

atravs do processo de replicao.
Figura 52 - Tabelas da sede e do o site alternativo 1 s 10:53:01
Alm dos testes de funcionamento da ferramenta, foi verificado o

desempenho do processo de replicao, utilizando o aplicativo IPTraf para medir a
quantidade de Bytes trafegados no servidor slave no momento da replicao.
Durante o intervalo de 1min25seg (Tempo decorrido at 100% da replicao),
trafegou pelo servidor mmrs2 o total de 3.351.950 Bytes, conforme figura a seguir.
Figura 53 - Bytes trafegados na replicao para o Servidor Alternativo 1 (mmrs2)
70
Com base nas informaes coletadas foi possvel elaborar uma planilha para
o clculo do desempenho da ferramenta em kbps e Mbps de acordo com o volume
de dados.
Clculo Estatstico com Base e Dados Coletados
Qtde. registros da tabela mmrs_clientes
95
Qtde. registros da tabela mmrs_contratosept
662
Qtde. registros da tabela mmrs_empresas
5
Qtde. registros da tabela mmrs_parcelasept
45
Total de Registros:
807
Hora de i ncio da replicao .
Hora e m que a replicao foi concluda ..
Tempo total gasto no processo de replicao
10:51:36
10:53:01
00:01:25 ==> Equivale a
85 segundos
Bytes Trafegados no perodo da replicao:

Bytes Trafegados ( convertidos e m Kbits):
3.531.950 ==> Equivale a 3,37 Mbytes

27.593,36 Frmula: (Dados e m Bytes/1024*8)
Velocidade Mdia de replicao ( kbps):
324,63
Velocidade Mdia de replicao ( Mbps):
0,32
Frmula: (Bytes Trafegados (convertidos e m

Kbits)/Tempo gasto e m s egundos)
Frmula: (Velocidade e m Kbps / 1 024)
Figura 54 - Apurao do desempenho do replicador
Conforme quadro acima, a velocidade de replicao, para 807 registros

(3,37 MB) foi de 324,63 Kbps, o que significa que esta amostragem passaria com
folga pelo canal de fibra ptica de 2 Mbps definido no item 4.1 do estudo de caso
deste projeto.
4.9.
GRFICO DE INVESTIMENTO
O grfico a seguir demonstra que a replicao sem o uso de software
especfico para este fim pode gerar um custo elevado para a empresa, alm da
probabilidade de erros e o surgimento da necessidade de correes manuais, as
quais muitas das vezes poderiam ser evitadas atravs do uso de um software
replicador.
Os dados analisados para gerao deste grfico so:
O custo do link de 10Mbps (R$ 6.000,00), necessrio para a

Replicao Rstica (sem software), acrescido de 10% de correo a
cada 12 meses; e,
O custo do link de 2Mbps (R$ 1.700,00), necessrio para a

Replicao via software, acrescido de 10% de correo a cada 12
71
meses, somado a aquisio de licena do software replicador e

respectiva renovao anual.
O custo da soluo sem o replicador, no perodo de 5 (cinco) anos seria por
aproximadamente R$ 439.000,00, enquanto com a utilizao do software replicador
Goldengate ficaria aproximadamente R$ 161.000,00 e com o Objectmmrs R$
130.000,00.
Compara'vo de Custos de Replicao

Replicao Rs9ca
Replicao c/ Goldengate
Replicao c/ Objectmmrs
500
400
300
200
-
Ms 1
Ms 3
Ms 5
Ms 7
Ms 9
Ms 11
Ms 13
Ms 15
Ms 17
Ms 19
Ms 21
Ms 23
Ms 25
Ms 27
Ms 29
Ms 31
Ms 33
Ms 35
Ms 37
Ms 39
Ms 41
Ms 43
Ms 45
Ms 47
Ms 49
Ms 51
Ms 53
Ms 55
Ms 57
Ms 59
100
Figura 55 - Grfico de Custos da Replicao
A soluo tem um custo elevado, mas levando em considerao que a

replicao gera segurana e alta disponibilidade para os dados, tal custo
perfeitamente justificvel, pois estar preservando dados que so altamente
importantes para a continuidade do negcio da empresa, pois caso haja uma
catstrofe e a empresa perder todos os dados, esta ficar impossibilitada de pagar
salrios dos funcionrios, aposentadorias, penses e outros tipos de benefcios que
fazem parte do negcio.
Consequentemente a empresa pode falir, ter problemas de imagem perante
o pblico e mdia, pode receber multas de rgos reguladores devido
impossibilidade de prestar informaes dentro dos prazos legais, alm de expor o
corpo Funcional e Diretoria a sanes judiciais.
4.10. FUNCIONAMENTO E MANUTENO DO REPLICADOR
O servio do objectmmrs pode ser customizado para ser inicializado junto
com o sistema operacional ou de forma manual. Aps inicializado ele permanece em
72
constante funcionamento, sempre verificando em determinado intervalo de tempo

(customizvel) se existe alguma replicao a ser realizada.
Este servio s ser parado por requisio do operador do servidor ou por
alguma outra anormalidade no sistema (falta de memria, falta de espao em disco,
tablespace estourada, falha de hardware, etc). No entanto estas paradas anormais
no implica na perda da replicao, pois todos os processo que vo acontecendo no
servidor de banco de dados vo sendo registrados na tabela de log do objectmmrs e
quando o servio restabelecido todos os dados que esto na tabela de log com o
status de pendente de replicao, so automaticamente replicados.
Antes do servidor master enviar algum registro ao slave, ele analisa se o
destino esto operando normalmente e, se no estiver, os registros so
armazenados em tabelas temporrias at a soluo do problema. Aps o
restabelecimento do servio o replicador sincroniza os dados que ficaram pendentes
na fila.
No existe nenhuma rotina manuteno a ser seguida para o uso do
replicador, apenas recomendvel que os servidores estejam com seus horrios
sincronizados e que o DBA sempre se esteja atento aos arquivos de log a fim de
identificar e tratar eventuais erros que possam vir a ocorrer.
73
5.
ANLISE
Neste captulo, so descritas algumas observaes a respeito deste trabalho
de concluso de curso, bem como os resultados obtidos.

5.1.
CONSIDERAES GERAIS
A implementao da tecnologia de BDD uma inovao interessante para
empresas de todos os portes, pois atravs dela possvel tornar consultas a banco
de dados mais geis, deixar os mesmos dados disponveis em vrios sites ao
mesmo tempo, ou em intervalos pr-definidos, dando assim, segurana guarda de
informaes e alta disponibilidade no caso de instabilidade ou pane em algum
servidor que faz parte do conjunto de distribuio.
Existem diversas formas de se implementar um modelo de BDD, cabendo s
empresas interessadas em desenvolver esta tecnologia a avaliao da melhor
soluo, sempre levando em considerao o custo/benefcio, sem deixar de lado os
quesitos relacionados a segurana, disponibilidade, confidencialidade, integridade,
transparncia.
Apesar da complexidade adicional para administrao da estrutura e dos
dados, o uso desta tecnologia vale a pena.
5.2.
RESULTADOS OBTIDOS
Ficou evidente que no decorrer do trabalho, que o processo de replicao de
dados em um SBDD depende da preparao de toda uma estrutura, para que a

soluo funcione de forma satisfatria. Pde-se observar que a estrutura de
replicao montada funciona bem, conforme o planejamento inicial. Os sites ficam
com acesso independente aos dados, o que possibilita o funcionamento da empresa
mesmo em situaes em que haja problema de ligao da rede da empresa rede
de outra, fazendo com que no haja prejuzos decorrentes de eventuais falhas. Isso
benfico para a empresa, pois no cenrio anterior, quando se tinha um Banco de
Dados centralizado, a situao era bem diferente, ou seja, caso um problema
ocorresse na rede que impossibilitasse o acesso ao Banco de Dados significaria a
impossibilidade da empresa poder operar. Do ponto de vista estratgico das
empresas, os benefcios so vistos imediatamente aps a implementao, o que
justifica e valida todo o trabalho e investimento em um projeto deste tipo.
74
6.
CONCLUSES
6.1.
QUANTO AO PROBLEMA E A SOLUO

Os problemas inicialmente levantados foram a necessidade de se manter o
sistema corporativo de uma empresa sempre operante, independente de algum

servidor de banco de dados estar com alguma tipo de pane, reduzir o troughput de
rede quando da necessidade da realizao de consultas e atualizaes de dados e
aumentar o nvel de segurana dos dados, mantendo-os em mais de um servidor de
BD.
Na fase de desenvolvimento deste trabalho, foi possvel perceber que
completamente possvel a implementao de um BDD, no entanto, cabe ao gestor
de TI avaliar qual a melhor soluo, sempre levando em considerao a estratgia
da empresa.
Apesar de ser uma soluo de custo elevado, um BDD proporciona vantagens
em relao ao centralizado, como por exemplo a reduo de troughput no canal de
rede e a replicao de dados em mais e um site, proporcionando assim mais
segurana e disponibilidade das informaes.
Como citado, esta no uma soluo simples de ser implementada,
precisando de bastante conhecimento tcnico e o uso de ferramentas adequadas
para o perfeito funcionamento da poltica de replicao, principalmente quando se
tratar de bancos de dados muito grandes e complexos.
75
7.
SUGESTO DE TRABALHOS FUTUROS

A seguir so apontados alguns itens que podem servir de complementao
de estudo a cerca do assunto abordado neste trabalho:
Replicao de Dados em um SBDD heterogneo;
Sincronizao de hora com base em servidores atmicos;
Replicao
de
Dados
suas
Archivelogs.
76
respectivas
estruturas
utilizando
8.
REFERNCIAS BIBLIOGRFICAS
ALVARES, R. V. Modelagem. Disponvel em

http://www.sqlmagazine.com.br/Colunistas/Reinaldo/06_Modelagem_P3.asp
Acesso em 25 de out. 2010.
ANDRADE, M. M. Introduo metodologia de trabalho cientfico: elaborao
de trabalhos na graduao. 8. Ed. So Paulo: Atlas, 2007.
BONOMA, T. V. Case research in marketing: opportunities, problems and a
process. Journal of Marketing Reserarck, Chicago, v. XXII, may 1985.
CERVO, A. L.; BERVIAN, P. A. Metodologia cientfica. 4. ed. So Paulo: Makron
Books, 1996.
DATE, C. J. Introduo a sistemas de banco de dados, traduo (da 4 ed.
original) de Contexto tradues, Rio de Janeiro. Campus, 1991.
ELMASRI, R. and NAVATHE, S. B.
Sistemas de Banco de Dados, 4 ed., So
Paulo. Addison-Wesley, 2005.

KORTH, H. F., Sistema de Banco de Dados, traduo [da 2 ed. ver] Maurcio
Heihachiro Galvan Abe. So Paulo. Makron Books, 1995.
ZSU, M. T.; VALDURIEZ, P.. Principles of Distributed Database Systems.
traduo [da 2 ed. americana] Vandenberg D. de Souza. Rio de Janeiro. Campus,
2001.
MACHADO, F.; ABREU, M.. Projeto de Banco de Dados Uma Viso Prtica. 16
edio, So Paulo. rica, 2010.
OLIVEIRA, Alexandre Pereira de. Modelo de Replicao de Dados entre SGBD

Heterogneos. Monografia (Graduao em Cincias da Computao). 2006.
Gravata. Universidade Luterana do Brasil.
77
SETZER, V. V., SILVA, F. S. C. Bancos de Dados. 1 ed., So Paulo. Edgard

Blucher, 2005.
SILBERSCHATZ, A., KORTH, H. F., SUDARSHAN, S. Sistema de Banco de
Dados. 5 ed., Rio de Janeiro. Campus, 2006.
SMANIOTO, C. A. Replicao e Alta Disponibilidade no PostgreSQL. Disponvel
em
http://www.devmedia.com.br/artigo-da-sql-magazine-24-replicaca-e-alta-
disponibilidade-no-postegresql/6140
Acesso em 08 de mar. 2012.
SISTEMAS, O. Conceitos Gerais de Replicao de Banco de Dados. Disponvel
em http://www.object.com.br/wiki/ConceitosGerais
Acesso em 08 de mar. 2012.
WATSON, John. OCA Oracle Database 11g Administrao I: Guia do Exame

1Z0-052. Porto Alegre: Brookman, 2010.
78
9.
GLOSSRIO
API (Application Programming Interface) um conjunto de rotinas e padres

estabelecidos por um programa de computador para a utilizao de suas
funcionalidades pro programas aplicativos que no querem se envolver nos detalhes
da implementao do software, mas apenas usar seus servios.
Background Em se tratando de processos, refere-se aos processos que so
processados em computador ou servidor e que o usurio no consegue enxergar
sem a execuo de comandos especficos de listagem de processos ativos.
Buffer a rea de memria reservada para armazenar dados que esto sendo
utilizados em tempo de processamento.
Business Intelligence o nome dado ao processo de coleta, organizao,
anlise, compartilhamento e monitoramento de informaes que oferecem suporte a
tomada de deciso.
Cache o armazenamento temporrio de dados para tornar mais veloz as
consultas aos mesmos tipos de dados j consultados anteriormente.
Clock Controlador de tempo para execuo de atividades por um computador.
Commit Processo utilizado para persistir alteraes realizadas nos dados de uma
ou vrias tabelas de bancos de dados.
Constraints Regras restritivas.
Control files So arquivos binrios utilizados para rastrear o status do banco de
dados e a estrutura fsica.
CPU O mesmo que processador. a parte fsica de um sistema de computador
responsvel pela execuo as instrues de um programa de computador.
79
Data Warehouse um sistema de computao utilizado para armazenar

informaes relativas s atividades de uma organizao em bancos de dados, de
forma consolidada.
Database Na arquitetura de banco de dados refere-se rea onde ficam
armazenados os data files, control files e os online redo log files, archivelog e etc.
Data files So os arquivos onde ficam armazenados em disco os dados do banco
de dados.
DBLink um canal utilizado pelo Oracle para fazer com que, atravs de uma rede
de computadores, um banco de dados localizado em determinado site possa
acessar os dados existentes em outro site.
Delete comando SQL utilizado para excluir dados em uma ou mais tabelas.
Driver um programa de computador que permite ao sistema operacional utilizar
as funcionalidades de um dispositivo ou programa especfico.
Eager A traduo desta palavra ansioso. Voltado para replicao de BDD,
refere-se ao modo que a replicao realizada, que direta, sem buscar dados nos
logs.
Full cheio, completo.
Grant Conceder privilgio.
Hardware - a parte fsica (tangvel) de um computador e caracteriza-se pelo
conjunto de componentes eletrnicos, circuitos integrados e placas.
Insert comando SQL utilizado para inserir dados em uma ou mais tabelas.
80
Instance Na arquitetura de banco de dados refere-se a rea onde ficam os

processos rodando em background e memria.
Lazy A traduo desta palavra significa preguioso. Voltado para replicao de
BDD, refere-se ao modo que a replicao realizada, que atravs de logs dentro
de determinado intervalo de tempo conforme parametrizado no replicador.
Link o elo que une atravs de um meio especfico (fibra-ptica, rdio, etc) o
usurio da informao prpria informao.
Log registro detalhado de eventos que ocorreram no banco de dados.
Master Em se tratando de replicao, esta a denominao do servidor que envia
dados ao servidor slave.
Nodos Vide o termo Site neste glossrio.
Online redo log file Arquivos de segurana que permitem que uma instncia de
banco de dados se recupere em caso de falha.
OLTP (Online Transaction Processing) - so sistemas que se encarregam de
registrar
todas
as
transaes
contidas
em
uma
determinada
operao
organizacional.
Overhead qualquer processamento ou armazenamento em excesso, seja de
tempo de computao, memria, largura de banda ou qualquer outro recurso
requerido ou gasto para executar uma determinada atividade.
Select comando SQL utilizado para selecionar dados em uma ou mais tabelas.
Site No contexto deste trabalho, site significa uma instalao (localidade) que
possua um servidor com um sistema de banco de dados distribudo nele instalado.
81
Slave Em se tratando de replicao de banco de dados distribudo, a

denominao do servidor que receber dados de um servidor master.
Sute conjunto de softwares aplicativos.
BDD Banco de Dados Distribudo.
Primary Key Restrio de integridade que define o atributo que dever ser nica
em uma tabela.
Revoke Revogar, retirar o privilgio dado atravs do comando grant.
Rollback Nome dado ao processo que volta os dados ao estado original, caso
haja algum problema na transao.
SBDD Sistema de Banco de Dados Distribudo
SGBD Trata-se de um o conjunto de programas de computador responsveis pelo
gerenciamento de uma base de dados, que possui como objetivo principal retirar do
cliente a responsabilidade de gerncia de acesso, manipulao e organizao de
dados. O SGBD disponibiliza uma Application Programming Interface (API) ou
Driver, atravs da qual os clientes podem incluir, alterar e consultar dados atravs
de comandos SQL.
SGBDD - o software responsvel por controlar todas as aes efetuadas em um
Banco de Dados Sistema de Gerenciamento de Bancos de Dados Distribudos.
Software Programa de computador criado para ser instalado em um hardware
para desempenhar atividades especficas.
Tablespace Sub-diviso lgica de um banco de dados utilizado para agrupar
estruturas lgicas relacionadas.
82
Timestamp o registro do tempo ou momento em que determinado processo

executado.
Troughput - a quantidade de dados transferidos de um lugar a outro, ou a
quantidade de dados processados em um determinado espao de tempo, pode-se
usar o termo throughput para referir-se a quantidade de dados transferidos em
discos rgidos ou em uma rede.
Unique Key Restrio de integridade que define que a chave do registro no
poder se repetir na tabela. Toda Primary Key Unique Key.
Update comando SQL utilizado para alterar dados em uma ou mais tabelas.
View a viso parcial ou total de tabelas de banco de dados.
83
10.
ANEXOS
DVD com o seguinte contedo:
Este trabalho de concluso de curso;
Scripts de preparao da base de dados do replicador;
Scripts de criao das tabelas utilizadas no estudo de caso;
Scripts de carga em tabelas utilizadas no estudo de caso;
Replicador ObjectMMRS na verso trial (configurada para mmrs1);
Script de criao da Database Link;
Script de contagem de registros das tabelas do estudo de caso; e,
Vdeo apresentao do funcionamento do replicador.
84

TCC BDD Sidnei

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TCC BDD Sidnei

Загружено:

Авторское право:

Доступные форматы

Centro Universitrio - IESB

BANCO DE DADOS DISTRIBUDOS

Matrcula: 0931004012 - Sidnei Fernandes das Neves

Sidnei Fernandes das Neves

BANCO DE DADOS DISTRIBUDO

Trabalho de Concluso de Curso apresentado

Sidnei Fernandes das Neves

BANCO DE DADOS DISTRIBUDO

Trabalho de Concluso de Curso apresentado

Figura 49 - Consulta a replicao em mmrs3 ................................................................ 68

Tabela 1 - Matriz de Comparao de Replicadores ...................................................... 41

LISTA DE ABREVIATURAS E SIGLAS

SQL (Structured Query Language) Linguagem estruturada de pesquisa.

MOTIVAO E CARACTERIZAO DO PROBLEMA................................ 13

Objetivo geral ............................................................................................. 14

Objetivo especfico .................................................................................... 14

RESULTADOS ESPERADOS ...................................................................... 15

ESTRUTURA DO TRABALHO ..................................................................... 15

2. REVISO DA LITERATURA ................................................................................... 16

SISTEMA DE BANCO DE DADOS ............................................................... 16

TIPOS DE BANCOS DE DADOS ................................................................. 16

Banco de Dados Centralizado ................................................................... 16

Banco de Dados Distribudo ...................................................................... 17

VANTAGENS DE UM BANCO DE DADOS DISTRIBUDO.......................... 18

DESVANTAGENS DE UM BANCO DE DADOS DISTRIBUDO .................. 20

PROBLEMTICAS DE UM BANCO DE DADOS DISTRIBUDO ................. 21

ARQUITETURA DO BANCO DE DADOS ORACLE..................................... 22

Funcionamento da Instance ...................................................................... 23

Detalhamento da SGA ............................................................................... 24

Detalhamento da Database ....................................................................... 24

Processos em background ........................................................................ 24

STRUCTURED QUERY LANGUAGE (SQL) ................................................ 26

REPLICAO DE DADOS ENTRE BANCOS DE DADOS DISTRIBUDOS 26

Modelo de Replicao ............................................................................... 27

Mtodos de Replicao ............................................................................. 28

Conflitos de Replicao ............................................................................. 29

Oracle Goldengate ..................................................................................... 30

METODOLOGIA UTILIZADA ........................................................................ 35

PLANEJAMENTO DE CRIAO DO BANCO DE DADOS DISTRIBUDO.. 35

MODELO DE DADOS ................................................................................... 35

Modelo entidade-relacionamento .............................................................. 35

ETAPAS PARA O DESENVOLVIMENTO E IMPLMENTAO ................... 36

CONTEXTUALIZAO DO ESTUDO DE CASO ......................................... 37

PROCEDIMENTO DE PESQUISA ............................................................... 37

4. ESTUDO DE CASO ................................................................................................ 38

DIAGRAMA DA SOLUO .......................................................................... 38

SGBD UTILIZADO ........................................................................................ 39

DESCRIO DA SOLUO ........................................................................ 40

CRIAO DO PROCESSO DE REPLICAO ............................................ 43

TESTES DE REPLICAO .......................................................................... 61

Operaes de Insert. ................................................................................. 61

Operaes de Update ................................................................................ 65

Operaes de Delete ................................................................................. 67

DESEMPENHO DO REPLICADOR .............................................................. 68

GRFICO DE INVESTIMENTO .................................................................... 71

FUNCIONAMENTO E MANUTENO DO REPLICADOR.......................... 72

CONSIDERAES GERAIS ........................................................................ 74

QUANTO AO PROBLEMA E A SOLUO .................................................. 75

7. SUGESTO DE TRABALHOS FUTUROS ............................................................. 76

de dados distribudo e explicar os seus principais conceitos, bem como compar-lo

segurana e alta disponibilidade nos processos, sejam de uma pequena empresa ou

MOTIVAO E CARACTERIZAO DO PROBLEMA

eles os processos no conseguem seguir o fluxo normal.