Estudo de Algoritmos e Replicação de Banco de Dados em Software Livre

Prévia do material em texto

ESTUDO DE ALGORITMOS E TÉCNICAS DE 
REPLICAÇÃO DE BANCO DE DADOS EM SOFTWARE 
LIVRE
Daniel Afonso Heisler
Lajeado, junho de 2008
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
CENTRO UNIVERSITÁRIO UNIVATES
CURSO DE ENGENHARIA DA COMPUTAÇÃO
ESTUDO DE ALGORITMOS E TÉCNICAS DE 
REPLICAÇÃO DE BANCO DE DADOS EM SOFTWARE 
LIVRE
Daniel Afonso Heisler
Trabalho de Conclusão de Curso – Etapa II, 
apresentado   ao   Curso   de   Engenharia   da 
Computação,   do   Centro   Universitário   ­ 
UNIVATES,   para   a   obtenção   do   título   de 
Engenheiro de Computação.
Orientador: Maglan Cristiano Diemer
Lajeado, julho de 2008
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
Dedico este trabalho aos meus pais
que me deram a educação
para que eu conseguisse fazer
minhas escolhas com sabedoria.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
AGRADECIMENTOS
Agradeço a Deus pela minha vida e toda a saúde para chegar até aqui; 
agradeço a meus pais, à minha namorada, aos meu irmãos por todo o apoio e 
amor necessário para chegar até  aqui; agradeço a meus amigos e colegas de 
aula pela ajuda e compreensão necessária; agradeço aos mestres por todos seus 
ensinamentos e companheirismo; agradeço ao meu orientador por todo o apoio e 
incentivo para conseguir elaborar este trabalho.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
Quem quer fazer alguma coisa
encontra um meio.
Quem não quer fazer nada
encontra uma desculpa.
Roberto Shinyashiki
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
RESUMO
A tecnologia de sistemas de bancos de dados distribuídos é  a união de 
duas abordagens para processamento de dados: as tecnologias de sistemas de 
bancos de dados  e de  redes de computadores.  Existem diversas técnicas para 
que seja possível a distribuição de bancos de dados, uma delas é a  replicação. 
Este  trabalho visa estudar os diferentes algoritmos e as técnicas de replicação 
para banco de dados em software livre.
PALAVRAS­CHAVE: Banco de dados distribuídos. Replicação.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
ABSTRACT
The tecnology of distributed database systems is a union of two approaches 
to processing data: the tecnology of databases systems and computer networks. 
There are several techniques in order to the database distribution, one of them is a 
replication.  This  paper  aims  to  study  the various algorithms and  techniques of 
database replication in free softwares.
KEYWORDS: Distributed database. Replication.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
LISTA DE FIGURAS
FIGURA 1 ­ Rede de computadores.......................................................................35
FIGURA 2 ­ Modelo relacional................................................................................42
FIGURA 3 ­ Arquitetura cliente/servidor de referência...........................................47
FIGURA 4 ­ Arquitetura de banco de dados distribuído de referência...................48
FIGURA 5 ­ Arquitetura de SVBD com um ECG....................................................49
FIGURA 6 ­ Exemplo do modelo de replicação single­master...............................56
FIGURA 7 ­ Exemplo do modelo de replicação multi­master.................................57
FIGURA 8 ­ Exemplo de replicação utilizando a ferramenta DBLink com Triggers
.................................................................................................................................66
FIGURA 9 ­ Exemplo de servidores de banco de dados utilizando a ferramenta 
PgCluster para replicação.......................................................................................69
FIGURA 10   ­  Exemplo  de   servidores   com  replicação  de  de  banco  de  dados 
cascateada utilizando a ferramenta Slony­I............................................................70
FIGURA 11 ­ Exemplo de disposição dos computadores na rede do laboratório..74
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
8
FIGURA 12 ­ Definição da estrutura do cenário 1..................................................76
FIGURA 13 ­ Definição da estrutura do cenário 2..................................................77
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
LISTA DE GRÁFICOS
GRÁFICO 1  ­  Dados  coletados  das   ferramentas   replicadoras,   com 1  servidor 
master   replicando  para  2  servidores  slaves  as  alterações  da  base  de  dados, 
geradas por 1 cliente, durante aproximadamente 10 minutos...............................85
GRÁFICO 2  ­  Dados  coletados  das   ferramentas   replicadoras,   com 1  servidor 
master   replicando  para  2  servidores  slaves,  as  alterações  da  base  de  dados 
geradas por 5 clientes, durante aproximadamente 10 minutos..............................87
GRÁFICO 3  ­  Dados  coletados  das   ferramentas   replicadoras,   com 1  servidor 
master   replicando  para  2  servidores  slaves,  as  alterações  da  base  de  dados 
geradas por 10 clientes, durante aproximadamente 10 minutos............................88
GRÁFICO 4  ­  Dados  coletados  das   ferramentas   replicadoras,   com 1  servidor 
master   replicando  para  2  servidores  slaves,  as  alterações  da  base  de  dados 
geradas por 20 clientes, durante aproximadamente 10 minutos............................90
GRÁFICO 5 ­ Dados coletados na replicação entre os três servidores, durante 10 
minutos, onde suas bases de dados foram acessadas por apenas 1 cliente........94
GRÁFICO 6 ­ Dados coletados na replicação entre os três servidores, durante 10 
minutos, onde suas bases de dados foram acessadas por apenas 5 clientes......94
GRÁFICO 7 ­ Dados coletados na replicação entre os três servidores, durante 10 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
10
minutos, onde suas bases de dados foram acessadas por apenas 10 clientes....95
GRÁFICO 8 ­ Dados coletados na replicação entre os três servidores durante 10 
minutos onde suas bases de dados era acessadas por apenas 20 clientes.........96
GRÁFICO 9  ­  Dados  coletados  das   ferramentas   replicadoras,   com 1  servidor 
master replicando para 2 servidores slaves de forma assíncrona a cada 5, 10 e 20 
minutos,   as   alterações   da   base   de   dados   geradas   por   1   cliente,   durante 
aproximadamente 41 minutos.................................................................................99
GRÁFICO 10 ­  Dados coletados das ferramentas replicadoras,  com 1 servidor 
master replicando para 2 servidores slaves de forma assíncrona a cada 5, 10 e 20 
minutos,   as   alterações   da   base   de   dados   geradas   por   5   clientes,   durante 
aproximadamente 41 minutos...............................................................................101
GRÁFICO 11 ­  Dados coletados das ferramentas replicadoras,  com 1 servidor 
master replicando para 2 servidores slaves, de forma assíncrona, a cada 5, 10 e 
20 minutos, as alterações da base de dados geradas por 10 clientes, durante 
aproximadamente 41 minutos...............................................................................102
GRÁFICO 12 ­  Dados coletados das ferramentas replicadoras,  com 1 servidor 
master replicando para 2 servidores slaves, de forma assíncrona, a cada 5, 10 e 
20 minutos, as alterações da base de dados geradas por 20 clientes, durante 
aproximadamente41 minutos...............................................................................103
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
LISTA DE QUADROS
QUADRO 1 ­ Avaliação dos SGBDs.......................................................................34
QUADRO 2 ­ Características do uso de dblink e triggers.......................................65
QUADRO 3 ­ Características da ferramenta PgCluster..........................................68
QUADRO 4 ­ Características da ferramenta Slony­I..............................................72
QUADRO 5 ­ Características dos computadores utilizados nos testes.................74
QUADRO 6 ­ Médias dos dados, coletados das ferramentas replicadoras, com 1 
servidor master replicando para 2 servidores slaves, as alterações da base de 
dados geradas por 1 cliente....................................................................................85
QUADRO 7 ­ Médias dos dados coletados das ferramentas replicadoras, com 1 
servidor master replicando para 2 servidores slaves, as alterações da base de 
dados geradas por 5 clientes..................................................................................86
QUADRO 8 ­ Médias dos dados coletados, das ferramentas replicadoras, com 1 
servidor master replicando para 2 servidores slaves, as alterações da base de 
dados geradas por 10 clientes................................................................................88
QUADRO 9 ­ Médias dos dados coletados das ferramentas replicadoras, com 1 
servidor master replicando para 2 servidores slaves, as alterações da base de 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
12
dados geradas por 20 clientes................................................................................89
QUADRO 10 ­ Médias das replicações coletadas nas simulações do cenário 2...96
QUADRO 11 ­ Médias dos dados coletados das ferramentas replicadoras, com 1 
servidor master  replicando para 2 servidores slaves as alterações da base de 
dados geradas por 1 cliente, no intervalo de tempo de 5, 10 e 20 minutos...........99
QUADRO 12 ­ Médias dos dados coletados das ferramentas replicadoras, com 1 
servidor master  replicando para 2 servidores slaves as alterações da base de 
dados geradas por 5 clientes, no intervalo de tempo de 5, 10 e 20 minutos.......100
QUADRO 13 ­ Médias dos dados coletados das ferramentas replicadoras, com 1 
servidor master replicando para 2 servidores slaves, as alterações da base de 
dados geradas por 10 clientes, no intervalo de tempo de 5, 10 e 20 minutos.....102
QUADRO 14 ­ Médias dos dados coletados das ferramentas replicadoras, com 1 
servidor master replicando para 2 servidores slaves, as alterações da base de 
dados geradas por 20 clientes, no intervalo de tempo de 5, 10 e 20 minutos.....103
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
LISTA DE ABREVIATURAS E SIGLAS
ACID ­ Atomicidade, Consistência, Isolamento e Durabilidade.
Bps – bits por segundo.
DCL – Data Control Language (Linguagem de Controle de Dados)
DDL – Data Definition Language (Linguagem de Definição de Dados)
DML   –  Data   Manipulation   Language  (Linguagem   de   Manipulação   de 
Dados)
DQL – Data Query Language (Linguagem de Consulta de Dados)
ECG – Esquema conceitual global
EEC ­ Error Correction Code (Código de Correção de Erros)
EIL ­ Esquema Interno Local
Kbps – Kilobits por segundo
KBps – Kilobytes por segundo
LAN – Local Area Network (Rede Local)
MANs – Metropolitan Area Networks (Redes metropolitanas)
Mbps – Megabits por segundo
MBps – Megabytes por segundo
QBE –  Que é uma aplicação visual do cálculo de domínios
QUEL  –   Uma   antiga   linguagem   de   consulta   para   banco   de   dados 
relacionais. É uma linguagem antecessora ao SQL
SGBD ­ Sistema Gerenciador de Banco de Dados
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
14
SQL – Structured Query Language (Linguagem de Consulta Estruturada)
SVBD – Sistemas de vários bancos de dados
WAN – Wide Area Network (Rede que abrange grandes áreas)
XML – EXtensible  Markup Language (Linguagem de marcação estendida)
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
LISTA DE EXEMPLOS
EXEMPLO 1 ­ Consulta SQL..................................................................................42
EXEMPLO 2 ­ Exemplo hipotético de instruções SQL para replicação síncrona. .54
EXEMPLO 3 ­ Exemplo hipotético de instruções SQL para replicação assíncrona
.................................................................................................................................55
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
SUMÁRIO
1 INTRODUÇÃO.....................................................................................................20
2 FUNDAMENTAÇÃO TEÓRICA..........................................................................23
2.1 SGBD................................................................................................................24
2.1.1 Modelo de dados............................................................................................24
2.1.1.1 Modelos lógicos com base em objetos.......................................................25
2.1.1.2 Modelos lógicos com base em registros.....................................................25
2.1.1.3 Modelos físicos...........................................................................................25
2.1.2 Segurança e integridade................................................................................26
2.1.3 Recuperação e concorrência.........................................................................27
2.1.4 Linguagem de banco de dados......................................................................28
2.1.4.1 Álgebra relacional.......................................................................................28
2.1.4.2 Cálculo relacional........................................................................................29
2.1.4.3 SQL.............................................................................................................30
2.1.5 SGBDs em software livre...............................................................................32
2.2 Redes de computadores...................................................................................34
2.2.1 Escala das redes............................................................................................36
2.3 Sistema de banco de dados distribuídos..........................................................37
2.3.1 Sistemas distribuídos.....................................................................................37
2.3.2 Banco de dados distribuídos..........................................................................41
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
17
2.3.3 Transparência e formas de distribuição.........................................................42
2.3.3.1 Fragmentação de dados.............................................................................43
2.3.3.2 Replicação de dados...................................................................................44
2.3.3.3 Transparência.............................................................................................44
2.3.4 Arquitetura de SGBDDs.................................................................................46
2.3.4.1 Sistemas cliente/servidor............................................................................46
2.3.4.2 Sistemas distribuídos não­hierárquicos......................................................482.3.4.3 Arquitetura de SVBDs.................................................................................49
2.3.5 Tolerância a falhas.........................................................................................49
2.3.5.1 Dependabilidade.........................................................................................50
2.3.5.2 Tipos de falhas............................................................................................51
2.3.5.3 Mascarando falhas com redundância.........................................................51
2.4 Replicação.........................................................................................................53
2.4.1 Tipos de replicação........................................................................................53
2.4.1.1 Síncrona......................................................................................................53
2.4.1.2 Assíncrona..................................................................................................54
2.4.2 Modelos de replicação...................................................................................55
2.4.2.1 Single­master ou master­slave...................................................................55
2.4.2.2 Multi­master.................................................................................................56
2.4.3 Protocolo de controle de réplica....................................................................57
2.4.3.1 Primary­Copy Method ................................................................................57
2.4.3.2 Quorum­Consensus Method ......................................................................58
2.4.3.3 Available­Copies Method ...........................................................................58
2.4.4 Métodos de replicação...................................................................................59
2.4.4.1 Arquivos de registros (logs)........................................................................59
2.4.4.2 Triggers.......................................................................................................60
2.4.5 Modelo de transações distribuídas................................................................60
2.4.5.1 Protocolo de efetivação em duas fases – 2PC...........................................61
2.4.5.2 Protocolo de efetivação em três fases – 3PC.............................................62
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
18
3 FERRAMENTAS UTILIZADAS...........................................................................63
3.1 DBLink e triggers...............................................................................................64
3.2 PgCluster...........................................................................................................67
3.3 Slony­I...............................................................................................................70
4 AVALIAÇÃO DAS FERRAMENTAS..................................................................73
4.1 Cenários............................................................................................................73
4.1.1 Cenário 1 – master­slave...............................................................................75
4.1.2 Cenário 2 – multi­master................................................................................76
4.2 Bases de dados................................................................................................78
4.3 Metodologia.......................................................................................................78
5 RESULTADOS OBTIDOS...................................................................................82
5.1 Replicação síncrona..........................................................................................82
5.1.1 Cenário 1 ­ master­slave................................................................................83
5.1.1.1 Acesso à base de dados por um cliente.....................................................83
5.1.1.2 Acesso à base de dados por cinco clientes................................................85
5.1.1.3 Acesso à base de dados por dez clientes..................................................87
5.1.1.4 Acesso à base de dados por vinte clientes................................................88
5.1.1.5 Conclusões sobre o cenário 1 ­ master­slave............................................90
5.1.2 Cenário 2 ­ multi­master.................................................................................92
5.1.2.1 Acesso à base de dados por um cliente.....................................................93
5.1.2.2 Acesso à base de dados por cinco clientes................................................94
5.1.2.3 Acesso à base de dados por dez clientes..................................................95
5.1.2.4 Acesso à base de dados por vinte clientes................................................95
5.1.2.5 Conclusões sobre o cenário 2 – multi­master............................................96
5.2 Replicação assíncrona......................................................................................97
5.2.1 Cenário 1 ­ master­slave................................................................................97
5.2.1.1 Acesso à base de dados por um cliente.....................................................98
5.2.1.2 Acesso à base de dados por cinco clientes..............................................100
5.2.1.3 Acesso à base de dados por dez clientes................................................101
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
19
5.2.1.4 Acesso à base de dados por vinte clientes..............................................102
5.2.1.5 Conclusões sobre o cenário 1 ­ master­slave..........................................104
5.2.2 Cenário 2 ­ multi­master...............................................................................105
6 CONCLUSÃO....................................................................................................106
REFERÊNCIAS.....................................................................................................108
GLOSSÁRIO.........................................................................................................111
APÊNDICES.........................................................................................................113
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
1 INTRODUÇÃO
Num ambiente de negócios não há tempo para atrasos, pois a perda de 
tempo,  resulta em perda de oportunidades.  Os dados são a base crítica para 
todas   as   organizações,   porque   é   através   da   consulta   dos   mesmos   que   são 
tomadas as decisões. Sendo assim, é extremamente necessário que os dados 
estejam   sempre   disponíveis   no   local   e   velocidade   desejados.   Através   dos 
sistemas gerenciadores de banco de dados (SGBDs), é possível armazenar os 
mesmos em banco de dados.
A grande vantagem na utilização de SGBDs está justamente na abstração 
dos dados, isto é, na possibilidade de visualizar somente aquilo que é necessário 
para   tomar   uma   decisão.   Enquanto  que  a   distribuição  dos   bancos  de   dados 
permite que os mesmos sejam acessados com maior velocidade e com um menor 
risco de indisponibilidade. A maior velocidade está relacionada diretamente com a 
possibilidade de distribuir os bancos de dados em diferents computadores e como 
conseqüência também distribuir a carga de processamento entre os mesmos. O 
menor risco de indisponibilidade através da utilização da distribuição dos bancos 
de dados está  relacionado com a quantidade de cópias idênticas dos mesmos 
(Silberschatz,1999).
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
21
Segundo   Özsu   (2001),   a   tecnologia   de   sistemas   de   bancos   de   dados 
distribuídos   (SBDDs)   é   a   união  de  duas  abordagens  para  processamento  de 
dados:   as   tecnologias   de  sistemas   de   bancos   de   dados  e   a   de  redes   de 
computadores.
Existem diversas   técnicas  que  possibilitam a  distribuição  de  bancos  de 
dados, sendo que uma delas é a replicação. Os dois principais motivos para fazer 
uma replicação são: a confiabilidade e a performance. No caso da confiabilidade, 
existe a garantia de se ter sempre um  backup  (cópia de segurança) em tempo 
real e, por conseqüência, alta disponibilidade do sistema. Já  a performance, é 
importante quando existem muitos acessos aos dados num mesmo intervalo de 
tempo, ou quando os acessos são de lugares espalhados geograficamente, pois 
dessa  forma é  possível  balancear  a  carga de acessos através de paralelismo 
(Tanenbaum, 2002; Silberschatz, 1999).
O próprio Google, o site de busca mais popular do mundo, especula­se que 
utiliza algumas centenas de milhares de computadores comuns, que rodam Linux 
Red Hat com o Kernel modificado e fazem replicação de banco de dados. Pois, 
com   quantidade   tão   grande   de   computadores,   é   muito   provável   que 
periodicamente ocorram falhas nos equipamentos. Contudo, usando replicação e 
redundância, mesmo tendo múltiplas falhas, têm­se sempre alta disponibilidade 
(Gedda, 2006).
O objetivo desse trabalho é fazer um estudo dos algoritmos e das técnicas 
de   replicação  de  banco  de  dados,  ou   seja,  estudar  as     possíveis   formas  de 
replicação de banco de dados e, conseguir, através de métricas, fazer a análise 
de   alguns   casos   práticos   de   replicação.   Assim,   a   seção   2   apresenta   um 
levantamento  bibliográfico   feito  através  de   livros,   revistas,   trabalhos  e  artigos 
científicos  sobre  assuntos  pertinentes  ao   tema  do  mesmo.  São  apresentados 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
22
vários   conceitos   relacionados   a   SGDBs,   sistemas   distribuídos   e   replicação, 
formando assim, a fundamentação teórica do trabalho.
Já a seção 3 do trabalho, apresenta as ferramentas replicadoras utilizadas 
nesse estudo. Nessa seção são descritas suas características, classificando­as 
conforme a fundamentação teórica vista na seção anterior.
A   seção  4,   descreve  a  metodologia   adotada  para   fazer   os   testes  e  a 
avaliação  das  diferentes   técnicas,   ferramentas  e  algoritmos,   de   replicação  de 
dados. Os resultados obtidos a partir dessas testes, são exibidos na seção 5.
Finalizando, são apresentadas as conclusões deste trabalho, contribuições 
do mesmo e sugestões de trabalhos futuros.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
2 FUNDAMENTAÇÃO TEÓRICA
Esta   seção   apresenta   a   fundamentação   teórica   necessária   para   o 
desenvolvimento deste trabalho. A mesma é dividida em quatro subseções que 
abordam os assuntos:  SGBDs,   redes de computadores,  SGBDs distribuídos e 
replicação.
Na   subseção   2.1,   são   abordadas   algumas   características   dos   SGBDs, 
como: integridade, segurança, transações, modelos de dados e linguagens para 
manipulação de banco de dados.  Além disso,   também há  um comparativo de 
SGBDs livres para definição de qual deles será utilizado no desenvolvimento do 
trabalho. Essas abordagens estudadas são fundamentais, pois na utilização de 
replicação, além das diferentes técnicas, as características dos SGBDs também 
influenciam no desempenho e na forma com que esses dados são replicados.
A subseção 2.2 traz definições e características de redes de computadores, 
comunicação dos dados e as diferentes escalas de rede. Como já introduzido, a 
distribuição   de   banco   de   dados   é   a   união   de   duas   abordagens:   redes   de 
computadores   e   SGBDs.   Assim,   os   conceitos   definidos   nesta   subseção   são 
importantes,   pois   para   cada   modelo  ou   escala   de   rede,   existem   técnicas   de 
replicação que podem ou não ser aplicadas com ou sem a performance desejada.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
24
As subseções 2.3 e 2.4 detalham os conceitos de distribuição e replicação 
de   banco   de   dados.   Apresentam   desde   as   características   necessárias   para 
alcançar   a   distribuição,   até   as   diferentes   técnicas   existentes   para   fazer   uma 
replicação.
2.1 SGBD
De acordo com Sisberschatz (1999), um SGBD é constituído por dados e 
programas que permitem seu acesso e sua manipulação. Sua principal finalidade 
é   permitir   o   armazenamento   de   dados   de   forma   segura,   íntegra   e   que   a 
recuperação dos mesmos possa ser feita de forma eficiente. Também é tarefa dos 
sistemas gerenciadores de banco de dados, permitirem a criação de estruturas 
para seu armazenamento, assim como, a gerência ao seu acesso, de forma que, 
somente consigam acessá­los quem tiver a devida autorização. O conjunto de 
dados   de   uma   estrutura   de   um   sistema   gerenciador   de   banco   de   dados, 
normalmente é chamada de banco de dados.
2.1.1 Modelo de dados
Silberschatz (1999), diz que sobre a estrutura de um banco de dados está 
definido  um  modelo  de  dados,   isto   é,   um conjunto  de   regras  que  definem a 
semântica,   o   relacionamento   e   a   consistência   dos   mesmos.   Esse   modelo   é 
classificado em três grupos: lógicos com base em objetos, lógicos com base em 
registros e físicos.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
25
2.1.1.1 Modelos lógicos com base em objetos
Modelos lógicos com base em objetos são modelos amplamente utilizados 
e, inclusive alguns, ainda estão por surgir. Utilizados na descrição de dados no 
nível lógico e de visões, possuem recursos de estruturação bem flexíveis, além de 
viabilizarem a especificação explícita de restrições. Segundo Silberschatz (1999), 
existem diversos modelos lógicos com base em objetos. Dentre os amplamente 
conhecidos, destacam­se o entidade­relacionamento e o orientado a objetos.
2.1.1.2 Modelos lógicos com base em registros
Modelos lógicos com base em registros são utilizados para descrever os 
dados no nível lógico e de visão. Ao contrário do modelo lógico com base em 
objetos,   esse   especifica   a   estrutura   lógica   do   banco   de   dados   quanto   a 
implementação de descrições de alto nível.
Esses modelos são assim chamados por possuírem a estrutura do banco 
de dados em registros de formato fixo de todos os tipos. Cada registro define um 
número fixo de campos, e cada campo possui normalmente tamanho fixo.
Os modelos de dados com base em registros mais utilizados, normalmente 
são: modelo relacional, modelo de rede e modelo hierárquico (Silberschatz, 1999).
2.1.1.3 Modelos físicos
Os modelos físicos de dados são usados para descrever os dados num 
nível  mais  baixo.  Ao  contrário  dos  modelos   lógicos,  existem poucos  modelos 
físicos de dados ainda em uso. Os dois mais conhecidos são o modelo unificado 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
26
(unifying   model)   e   o   modelo   de   partição   de   memória   (frame­memory   model) 
(Silberschatz, 1999).
2.1.2 Segurança e integridade
Em   banco   de   dados,   é   muito   comum   o   uso   dos   termos   segurança   e 
integridade dos dados. Embora os dois conceitos sejam bem distintos, em ambos 
os casos, o sistema precisa estar ciente daquilo queo usuário não pode violar. De 
forma geral, a segurança garante que os usuários tenham permissão de fazer o 
que estiverem tentando fazer, enquanto a integridade garante que aquilo que os 
usuários estão tentando fazer, está correto (Date, 1990).
A segurança dos dados  inclui  dois aspectos: a  proteção dos dados e o 
controle   de  autorização.  A  proteção  dos  dados   é   necessária   para  evitar   que 
usuários não autorizados conheçam o conteúdo físico dos mesmos e o principal 
meio  para  conseguir   isso  é   a   criptografia.   Já   o   controle  de  autorização  deve 
garantir que os usuários executem no banco de dados, apenas operações a que 
eles têm permissão.
Diferentemente do controle de autorização dos sistemas operacionais, os 
SGBDs   possibilitam   que   as   autorizações   possam   ser   redefinidas,   para   que 
usuários  diferentes   tenham direitos  diferentes  sobre  os  mesmos  objetos.   Isso 
possibilita uma maior precisão no controle de autorização dos usuários perante os 
objetos do banco de dados.
Manter um banco de dados consistente requer diversos mecanismos como 
controle   de   concorrência,   confiabilidade,   proteção   e   controle   de   integridade 
semântica. Este último, é um conjunto de restrições que, se satisfeitas, indicam 
que um banco de dados está consistente.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
27
Existem   dois   tipos   principais   de   restrições   de   integridade:  restrições 
estruturais  e  restrições   comportamentais.   As   restrições   estruturais   expressam 
propriedades semânticas básicas inerentes a um modelo. Como exemplo, num 
modelo relacional, pode­se citar as restrições de chave exclusiva. Já as restrições 
comportamentais   permitem   captar   a   semântica   dos   aplicativos,   podendo 
expressar as associações entre objetos, assim como, a dependência da inclusão 
num modelo relacional (Özsu, 2001).
2.1.3 Recuperação e concorrência
Os problemas de concorrência e recuperação em banco de dados estão 
fortemente ligados ao processamento de transações. Uma transação é uma única 
unidade   de   trabalho   lógica.   A   integridade   de   uma   transação   depende   de   4 
propriedades  conhecidas  como ACID  (atomicidade,  consistência,   isolamento  e 
durabilidade) (Date, 1990).
Por exemplo, a transferência do valor de uma conta bancária A para uma 
conta bancária B, implica em debitar o valor de A e creditar o mesmo valor em B. 
O primeiro princípio é que, de forma alguma, o valor deve ser debitado de A se 
não for creditado em B, isto é, ou a operação é executada como um todo, ou não 
é  executada.  Este   “tudo  ou  nada”  é   chamado de  atomicidade.  Além disso,  o 
somatório, após a transferência das contas A e B, deve ser o mesmo que era 
antes da transferência. Essa exigência é conhecida como consistência. Se duas 
transferências estiverem ocorrendo ao mesmo tempo, uma não deve interferir na 
outra. Esta propriedade é conhecida como isolamento. Por fim, após a efetivação 
da  transferência,  os  novos  valores  de  A e  B  devem persistir,  a  despeito  das 
possibilidades de falhas do sistema. Esta persistência é chamada de durabilidade. 
Dessa forma, cada transação é uma unidade de ACID que não pode violar as 
regras de consistência de um banco de dados (Silberschatz, 1999).
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
28
Silberschatz   (1999),  segue  afirmando que devido  ao  grande número de 
possibilidades de  falhas  de  um banco de dados durante  a  execução de uma 
transação,  uma transação pode não se completar  com sucesso.  Garantindo a 
atomicidade   do   banco   de   dados,   uma   transação   incompleta   não   poderá 
comprometer o estado do banco de dados e dessa  forma, o banco de dados 
deverá   retornar ao estado anterior ao da transação. Essa responsabilidade de 
detectar eventuais falhas e de retornar ao estado anterior é responsabilidade do 
SGBD.
Por fim, Silberschatz (1999) conclui que quando existem várias transações 
num   banco   de   dados   sendo   executadas   ao   mesmo   tempo,   é   possível   que 
algumas delas violem as regras de consistência do banco de dados. Isso pode 
ocorrer, mesmo que as transações individualmente sejam executadas de forma 
correta. Essa responsabilidade de gerenciar as transações concorrentes também 
pertence ao SGBD.
2.1.4 Linguagem de banco de dados
As linguagens para manipulação de dados em banco de dados relacionais, 
entram em dois grupos fundamentais: As baseadas na  álgebra relacional  e as 
baseadas em cálculo relacional (Özsu, 2001).
2.1.4.1 Álgebra relacional
A álgebra relacional é uma linguagem de consulta procedural formada por 
um conjunto de operadores que operam sobre as relações. É derivada da teoria 
dos conjuntos e é  mais utilizada que o cálculo relacional. Cada operador toma 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
29
uma ou duas relações como operandos, produzindo uma nova relação resultante 
(Silberschatz, 1999).
Segundo Özsu (2001), os operadores fundamentais da álgebra relacional 
são: seleção, projeção, união, diferença de conjuntos e produto cartesiano. Além 
desses  operadores   fundamentais,  ainda  existem outros  operadores  adicionais, 
formados a partir dos fundamentais, que são: interseção, junção Ɵ (theta), junção 
natural, semijunção e quociente. Na prática, a álgebra relacional é estendida com 
operadores, para agrupar ou classificar os resultados, e para executar as funções 
aritméticas   de   agregado.   Outros   operadores,   como   os   de  junção   externa  e 
fechamento transitivo,   também são utilizados algumas vezes para proporcionar 
funcionalidades adicionais.
Uma das linguagens mais utilizadas entre as que seguem as definições da 
álgebra   relacional  é  a   linguagem SQL1.  Embora  alguns autores  definam essa 
linguagem como um ponto entre a álgebra relacional e ao cálculo relacional de 
tuplas, seus criadores a definem como linguagem de mapeamento.
2.1.4.2 Cálculo relacional
Nas linguagens de cálculo relacional, ao invés de especificar como obter 
um resultado, especifica­se o que é o resultado. Um banco de dados pode ser 
visto como uma coleção de  tuplas ou de domínios,  dessa  forma existem dois 
grupos sob os quais cai o cálculo relacional: cálculo relacional de tuplas e cálculo 
relacional de domínios. A diferença entre os dois está basicamente sob a variável 
primitiva da consulta (Özsu, 2001).
1 Structured   Query   Language  ou   Linguagem  de   Consulta   Estruturada,   é   a   linguagem   para 
manipulação de banco de dados mais utilizada. Fonte: Silberschatz (1999).
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
30
Em   álgebra   relacional,   as   consultas   são   escritas   sob   forma   de   uma 
seqüência de procedimentos. Já no cálculo relacional de tuplas é uma linguagem 
não­procedural. Ela permite a descrição da consulta desejada sem especificar os 
procedimentos para obter essas informações. Há várias linguagens baseadas em 
cálculo relacional de tuplas, sendo as mais populares SQL e QUEL (Silberschatz, 
1999; Özsu, 2001).
O cálculo relacional de domínios utiliza variáveis de domínio, que tomam 
valores do domínio de um atributo, em vez de valores da tupla inteira. Em outras 
palavras, o intervalo de uma variável de domínios consiste nos domínios sobre os 
quais a relação é definida. Mesmo assim, o cálculo relacional de domínios está 
intimamente ligado ao cálculo relacional de tuplas. O sucesso desta linguagem 
deve­se   principalmente   à   QBE,   que   é   uma   aplicação   visual   do   cálculo   de 
domínios (Özsu, 2001).
2.1.4.3 SQL
A SQL – Struct Query Language, é a linguagemde banco de dados que 
surgiu no  início  dos anos 70 e hoje,  é  a  linguagem de banco de dados mais 
utilizada.   Ela   utiliza   uma   combinação   de   construtores   em   álgebra   e   cálculo 
relacional e, dessa forma, é bastante fácil sua utilização. Embora conhecida como 
uma   linguagem   de   consulta,   ela   possui   vários   outros   recursos   (Silberschatz, 
1999).
A SQL é uma sublinguagem do SGBD. Possui tanto uma linguagem para 
definição de dados (DDL – data definition language), como uma linguagem para 
manipulação de dados  (DML –  data manipulation  language)  e  uma  linguagem 
para consulta de dados (DQL – data query language). Além disso possui recursos 
especiais de controle de dados que não se enquandram nem na DDL, nem na 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
31
DML. Alguns autores chamam esses recursos de linguagem de controle de dados 
(DCL – data control language) (Date, 1990).
Segundo   Silberschatz   (1999),   a   linguagem   SQL   pode   ser   dividida   em 
diversas partes:
Linguagem   de   definição   de   dados:  possui   comandos   para   criação, 
alteração e exclusão de esquemas de relações,  bem como a manipulação de 
índices.
Linguagem interativa de manipulação de dados: é a linguagem baseada 
na   álgebra   relacional   e   no   cálculo   relacional   para   criar   consultas.   Também 
engloba comando para   inserção,  alteração e exclusão de  tuplas no banco de 
dados.
Incorporação   DML:  é   a   forma   de   comandos   SQL   incorporados   para 
permitir o uso de outras linguagens de uso geral como o C, PL/I, Cobol etc.
Definição de visões: comandos para definição de visões, isto é, relações 
simbólicas criadas a partir de consultas.
Autorização:  comandos para especificação de direitos ou  restrições de 
acesso e manipulação dos dados de relações e visões.
Integridade:  comandos para especificação de regras de integridade, que 
os dados que serão armazenados no banco de dados deverão satisfazer.
Controle de transações: comandos para a especificação de inicialização 
e   finalização   de   transações.   Algumas   implementações   também   permitem 
explicitar o bloqueio de dados para controle de concorrência.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
32
O SQL foi revisto em 1992 e a esta versão foi dado o nome de SQL­92. Foi 
revisto   novamente   em   1999   e   2003   para   se   tornar   SQL:1999   e   SQL:2003, 
respectivamente. O SQL:1999 utiliza expressões regulares de emparelhamento, 
queries  recursivas e  triggers. Também foi feita uma adição controversa de tipos 
não­escalados e de algumas características de orientação a objetos. O SQL:2003 
introduz características relacionadas ao XML, seqüências padronizadas e colunas 
com valores de auto­generalização (inclusive colunas­identidade) (ISO/IEC 9075, 
2006).
2.1.5 SGBDs em software livre
Atualmente  existem diversos  SGBDs,  mas  neste   trabalho,  optou­se  por 
utilizar um que seja software livre. Dentre os diversos motivos que levaram a essa 
escolha,   o   principal   é   a   possibilidade   de  acessar   o   código   fonte   do   mesmo, 
podendo­se assim fazer um estudo mais aprofundado e até mesmo alterações.
Para decisão de qual banco de dados utilizar, foi realizada uma tabulação 
comparativa entre alguns dos SGBDs em software livre, onde avaliou­se várias 
características técnicas dos mesmos.
Os seguintes SGBDs foram avaliados:
PostgreSQL:  SGBDs  objeto­relacional,   de  código  aberto.  Optou­se  pela 
versão 8.2.6 disponível em http://www.postgresql.org.
Firebird: SGBDs relacional, de código aberto. Optou­se pela versão 2.0.3 
disponível em http://www.firebirdsql.org   .  
http://www.postgresql.org/
http://www.postgresql.org/
http://www.firebirdsql.org/
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
33
MySQL: SGBDs relacional, de código aberto. Optou­se pela versão 5.0.45 
disponível em http://www.mysql.com.
O QUADRO 1 mostra a avaliação baseada apenas nas documentações 
disponíveis nos respectivos sites, utilizando como referência a documentação da 
última   versão   estável   dos   SGBDs.   O   acesso   aos   sites   para   coleta   das 
informações   e   para   definição   das   versões   dos   SGBDs,   foi   realizado   no   dia 
19/10/2007.
PostgreSQL MySQL Firebird
Sistema Operacional
Linux/Unix + + +
FreeBSD + + +
Windows + + +
Sun Solaris + + +
Mac OS X + + +
HP UX + + +
Características
ACID + * +
Integridade referencial + * +
Transações + * +
Tabelas temporárias + * ­
Materialize views * * *
Stored Procedures + * +
Cursores + + +
Triggers + + +
SQL­92 + * +
SQL:1999 + * *
SQL:2003 * * *
Funções de linguagens + * *
Esquemas + ­ ­
Expressões regulares + + *
Savepoints + * +
Point­in­time recovery + + *
Efetivação em 2 fases + * ?
http://www.mysql.com/
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
34
PostgreSQL MySQL Firebird
Efetivação em 3 fases ? ? ?
Inserções múltiplas + + +
Índices
R­/R+ tree + * ­
Hash + * ­
Expression + ­ +
Partial + ­ ­
Reverse * ­ *
Bitmap * ­ ­
GIST + ­ ­
GIN + ­ ­
Particionamento
Range + * ­
Hash + * ­
Composite (Range + Hash) + * ­
List + * ­
Shadow ? ? +
Replication API + + +
Legenda:
(+) : característica é suportada inteiramente
(­) : característica não é implementada
(*) : característica é implementada parcialmente ou não em conformidade com o padrão
(?) : sem opinião clara sobre o suporte
QUADRO 1 ­ Avaliação dos SGBDs
Fonte:  Elaborado pelo autor com base em  PostgreSQL (c1996­2008),  MySQL (c1997­2008) e 
Firebird (c2000­2008).
2.2 Redes de computadores
Segundo   Özsu   (2001),   redes   de   computadores   são   uma   coleção   de 
computadores autônomos que conseguem trocar informação entre si. Nesta rede, 
estes   computadores   normalmente   são   chamados   de  hosts  ou  nós,  e,   para 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
35
conseguirem trocar informações entre si, deve existir algum meio de interconexão 
entre os mesmos. A FIGURA 1 faz essa ilustração.
FIGURA 1 ­ Rede de computadores
Fonte: Elaborado pelo autor com base em (Özsu, 2001).
[...]dados   [são   definidos]   como   entidades   que   carregam   algum 
significado.  Sinais   são  a  codificação   elétrica  ou   eletromagnética   dos 
dados. Sinalizar é  o ato de propagar o sinal ao longo de algum meio 
apropriado.   Por   fim,   transmissão   é   a   comunicação   dos   dados   pela 
propagação e pelo processamento de sinais (Stallings, 1988 apud Özsu, 
2001).
Em uma   rede  de   computadores,   os  equipamentos   são   conectados  por 
links. Cada link pode transportar um ou mais canais. O link é uma entidade física, 
enquanto o canal é  uma entidade  lógica. Os canais de comunicação têm uma 
capacidade  que pode ser definida como a quantidade de dados, que pode ser 
transmitida pelo canal em uma determinada unidade de tempo. Essa capacidade 
é  chamada de  largura de banda  do canal e geralmente é  medida em  bits por  
segundo (bps) (Özsu, 2001).
Switches
hosts
Sub­rede de 
comunicações
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
36
2.2.1 Escala das redes
Segundo Özsu (2001), em termos de distribuição geográfica as redes são 
classificadas como: redes locais, metropolitanas e remotas.
Uma rede remota (WAN –  wide area network) é uma rede cuja distância 
entre dois nós quaisquer varia entre aproximadamente 20 quilômetros e milhares 
de quilômetros. Através de switches e/ou roteadores é possível a comunicação 
sobre áreas mais extensas, contudo, quanto maior a distância, maior a perdade 
desempenho.
Uma   rede   local   (LAN   –  local   area   network)   geralmente   possui   limite 
geográfico  inferior  a 2 quilômetros.  Dessa  forma, proporciona comunicação de 
grande largura de banda sobre os meios de comunicação pouco dispendiosos. Os 
tipos   de   meios  de   transmissão  empregadas  em   redes   locais   são   geralmente 
cabos coaxiais, fios de pares trançados ou fibras ópticas.
Uma rede metropolitana (MAN – metropolitan area network) está entre a 
LAN e WAN em escala e abrange uma cidade, ou parte dela. A distância entre os 
nós geralmente é  de 10 quilômetros. As MANs têm semelhanças significativas 
com as LANs e, de certa forma, podem ser consideradas versões maiores dessas 
últimas.   Porém,   como   nas   MANs   o   número   de   usuários   é   maior,   existem 
problemas de igualdade de acesso e desempenho, independente da localização 
física, que devem ser resolvidos.
A  escala  de  uma   rede  de  computadores  conceitualmente  não  define  a 
largura de banda disponível. Parece lógico que quanto a menor distância, maior a 
largura de banda.  Contudo, a  largura de banda é  definida principalmente pelo 
meio físico utilizado, que pode variar entre cabos coaxiais, cabos de fibra óptica, 
cabos de par trançados e até canais de satélite. Tipicamente, as redes LAN são 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
37
formadas por cabos coaxiais, par trançados ou de fibra óptica e são conhecidas 
como redes Ethernet, enquanto as redes WAN são formadas por cabos de fibra 
óptica e canais de satélite, sendo que o maior exemplo desse tipo de rede é a 
Internet (Silberschatz, 1999).
Para fazer uma distribuição de banco de dados é  necessário que antes 
seja  avaliado a escala  da   rede,  para saber  qual  a  possível   largura  de banda 
disponível.   A   importância   disso   se   dá   justamente   para   saber   qual   tipo   de 
replicação é apropriado para o meio de comunicação utilizado.
2.3 Sistema de banco de dados distribuídos
Nas subseções 2.1 e 2.2 foram vistos, de forma isolada, alguns conceitos 
sobre SGBDs e redes de computadores. Esses conceitos são importantes para 
uma melhor compreensão da união dessas duas abordagens, isto é, dos sistemas 
gerenciadores de bancos de dados distribuídos (SGBDDs). Nesta seção serão 
estudados os aspectos relativo aos SGBDDs que  introduzirão a subseção 2.4, 
que trata do estudo sobre replicações, principal objetivo deste trabalho.
2.3.1 Sistemas distribuídos
Para   Tel   (2000),   o   termo   “sistema   distribuído”   significa   um   conjunto 
autônomo de computadores, de processadores ou de processos interconectados. 
Estes computadores, processadores ou processos são conhecidos como  nodos 
do sistema distribuído, e, precisam estar interconectados para possibilitar a troca 
e compartilhamento de informações.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
38
Já Date (1990), diz que este termo se refere a qualquer sistema que pode 
estar em várias localidades mas conectado através de uma rede de comunicação, 
de forma que, independente de onde, possa ser possível o  acesso aos dados de 
qualquer localidade.
Segundo   Tel   (2000),   as   características   de   um   sistema   distribuído 
dependem muito da motivação pela sua existência. A sua existência se dá  na 
tentativa   de   resolver   alguns   problemas   computacionais.   Algumas   dessas 
características são listados abaixo:
● Troca   de   informações:   possibilidade   de   trocar   informações   entre 
diferentes computadores.
● Compartilhamento de recursos: possibilidade de compartilhar recursos 
do sistema, da mesma forma que são compartilhados periféricos como 
impressoras e unidades de disco.
● Confiabilidade:   possibilidade   de   continuar   operando   um   sistema 
mesmo que um  host  do sistema pare por  algum motivo,  ou seja,  a 
garantia do “sempre funcionamento em tempo real”.
● Paralelismo: possibilidade de distribuir as tarefas do sistema que serão 
executadas em diversos processadores ou computadores.
● Flexibilidade  na  estrutura  geográfica:  possibilidade de  ter  o  sistema 
distribuído em diversos locais geograficamente afastados.
● Transparência: possibilidade de adotar/seguir padrões em sistemas de 
forma que seja possível trocar informações com outros sistemas.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
39
Quando   é   criado/utilizado   um   sistema   distribuído,   deve   ser   levado   em 
consideração o meio pela qual   ocorre a  ligação entre os  nodos,  pois existem 
diversos problemas que podem ocorrer em virtude dessas ligações. Contudo, os 
problemas dos algoritmos distribuídos geralmente são similares, independendo do 
tipo de rede. Assim, existem alguns aspectos ao qual os algoritmos distribuídos 
devem ficar atentos, continua Tel (2000):
● Confiabilidade: durante uma troca de informações entre nodos, alguma 
coisa pode dar errado e isso nunca pode ser ignorado.
● Tempo   de   comunicação:   o   tempo   que   leva   a   transmissão   de 
informações para   redes  que não são  locais  é  maior  que em  redes 
locais. Em redes não locais, o tempo de processamento da informação, 
muitas vezes, é insignificante comparado ao tempo de transmissão da 
mesma.
● Homogeneidade: possivelmente em uma rede local os protocolos de 
comunicação   entre   os  nodos  sejam   os   mesmos.   Contudo,   na 
comunicação   em   redes   não   locais,   pode   ser   que   não   sejam   os 
mesmos.   Assim,   deve   ser   prevista   a   comunicação   em   padrões 
diferentes.
● Confiança mútua: em redes locais todos os usuários podem ter acesso 
livre   ao   sistema.   Contudo,   redes   não   locais   requerem   o 
desenvolvimento de algoritmos com técnicas de segurança, cópias de 
segurança e livre de ataques de usuários.
Além desses aspectos, no desenvolvimento de algoritmos distribuídos, que 
devem ser levados em consideração, existem ainda alguns problemas de redes 
que podem ocorrer e devem ser prevenidos. Há problemas comuns entre redes 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
40
LANs e WANs, mas há também os que são específicos de cada tipo de rede. Isso 
ocorre em virtude das características físicas e lógicas da rede (Tel, 2000).
Alguns problemas comuns que precisam ser abordados/implementados por 
algoritmos distribuídos que ocorrem em redes WANs e LANs são:
● Confiabilidade na troca de dados: durante a transmissão entre dois nós 
podem   ocorrer   diversos   problemas   de   conexão.   Quantos   mais 
caminhos as informações tiverem que percorrer, maior a probabilidade 
de que ocorram problemas. Contudo, as informações não podem ser 
perdidas nem podem chegar na ordem incorreta.
● Controle de tráfego: quanto mais mensagens forem transmitidas, maior 
será o congestionamento da rede. A geração de mensagens pelos nós 
deve levar em consideração a capacidade da rede.
● Prevenção de  deadlock: como o tráfego de mensagens entre os nós 
pode   ser   grande   e   os   nós   possuem   uma   capacidade   limite   para 
armazenamento   das   mesmas,   podem   ocorrer   problemas   de   uma 
mensagem esperar por outra, que está esperando por outra que pode 
depender  da mensagem anterior.  Dessa  forma, o  sistema não deve 
ficar esperando infinitamente.
● Segurança: faz­se necessário um controle de abusos, principalmente 
em   redes   de   computadores   que   estão   ligadas   à   redes   de 
computadores de proprietários diferentes. Além disso, os dados devem 
ser   transmitidos   com   segurança,   utilizando­se   de   técnicas   de 
criptografia e certificações digitais.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(htt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
41
● Sincronização:   é   necessário   fazer   a   gerência   da   transmissão   e   do 
acesso   das   informações,   de   forma  que  as  mesmas   mantenham­se 
consistentes.
● Exclusão   mútua:   algumas   vezes   é   necessário   evitar   que   dois 
processos acessem o mesmo recurso ao mesmo tempo, recurso esse 
que é denominado seção crítica.
2.3.2 Banco de dados distribuídos
Bancos de dados distribuídos são considerados uma coleção de vários 
bancos de dados  logicamente  inter­relacionados,  distribuídos em uma rede de 
computadores. Um sistema gerenciador de banco de dados distribuído (SGBDD) 
é   um um software  que  gerencia  os  bancos de dados  tornando  a  distribuição 
transparente para o usuário (Özsu, 2001).
Segundo   Silberschatz   (1999),   a   principal   diferença   entre   sistemas   de 
bancos de dados centralizados e distribuídos é que no primeiro caso os dados 
estão   localizados   em   apenas   um   local,   enquanto   que   no   segundo   caso,   os 
mesmos podem estar em vários locais.
Algumas vezes a questão da distribuição geográfica dos dados não é vista 
como a questão mais relevante para bancos de dados distribuídos. Os seguidores 
desta visão, vêm como a questão mais importante o fato dos bancos serem inter­
relacionados, mesmo estando no mesmo local. Contudo, é muito importante levar 
em consideração a questão da distribuição física dos dados, pois isto pode levar a 
uma série de problemas com os quais os sistemas gerenciadores de banco de 
dados distribuídos devem estar preparados para lidar (Özsu, 2001).
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
42
2.3.3 Transparência e formas de distribuição
Considere   uma   empresa   de   engenharia   com   negócios   em   Boston, 
Edmonton, Paris e São Francisco, exemplifica Özsu (2001), em cada um desses 
locais são desenvolvidos projetos e a empresa gostaria de manter os bancos de 
dados dos projetos e seus funcionários inter­relacionados. Supondo um banco de 
dados relacional, as informações podem ser armazenadas em quatro entidades 
conforme   ilustrado   na   FIGURA   2.   Uma   tabela  FUNC   para   armazenar   os 
funcionário, uma tabela PROJ para armazenar os projetos, uma tabela PAG para 
armazenar as informações de salários e uma última tabela DSG para armazenar 
quais funcionários foram designados a quais projetos.
FIGURA 2 ­ Modelo relacional
Fonte: Elaborado pelo autor com base em (Özsu, 2001).
Se o banco de dados estivesse centralizado e fosse necessário descobrir 
qual  a   relação dos  funcionários  que  trabalharam em projetos  por  mais  de  12 
meses, poderia ser utilizada a consulta SQL do EXEMPLO 1 (Özsu 2001).
SELECT  func.fnome, pag.sal 
FROM  func, dsg, pag 
WHERE  dsg.dur > 12 
AND  func.fno = dsg.fno 
AND  pag.cargo = func.cargo
EXEMPLO 1 ­ Consulta SQL
Fonte: Elaborado pelo autor com base em (Özsu, 2001).
FNO
FNOME
CARGO
FUNC
PNO
PNOME
PRCAMEN
PROJ
CARGO
SAL
PAG
FNO
PNO
RESP
DUR
DSG
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
43
Contudo, segue  Özsu (2001),  dada a natureza distribuída da empresa, é 
preferível   que   essa   consulta   retorne   em   Edmonton   somente   os   dados   de 
Edmonton, ou seja, que os dados de Edmonton estejam armazenados somente 
em Edmonton. O mesmo se aplica para os outros escritórios. Desta forma, têm­se 
um   cenário   onde   os   dados   estão   particionados   e   armazenados   em   locais 
diferentes. Isto é conhecido como fragmentação. Além disso, pode ser preferível 
duplicar alguns desses dados em outros locais por questões de desempenho e 
confiabilidade,   resultando   num   banco   de   dados   distribuído  fragmentado  e 
replicado.
Uma das premissas de um banco de dados distribuído, é que o acesso às 
informações seja totalmente transparente, dessa forma, mesmo com os dados 
distribuídos, os usuários ainda poderiam executar a consulta SQL do EXEMPLO 
1, da mesma forma, ficando a cargo do SGBDD a resolução das questões de 
fragmentação e replicação dos dados.
2.3.3.1 Fragmentação de dados
Silberschatz (1999) explica  a fragmentação como uma divisão dos dados 
em   vários   fragmentos,   podendo   estes,   serem   armazenados   em   locais   físicos 
diferentes. O conceito de fragmentação de dados parte do princípio de que, se 
existe uma relação r que é fragmentada em r1, r2, ..., rn, esses fragmentos contêm 
informações suficientes para permitir a reconstrução da relação original  r. Essa 
reconstrução pode ser feita por operações de  união  ou de um tipo especial de 
junção.
Continua  Silberschatz   (1999)   afirmando   que,   existem   dois   esquemas 
diferentes de fragmentação, e segue explicando os mesmos:
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
44
1) Fragmentação horizontal: a relação r é particionada em um número de 
subconjuntos r1, r2, ..., rn. Cada tupla da relação r deve pertencer a pelo menos um 
fragmento, de forma que a relação original principal possa ser reconstruída. Um 
desses  fragmentos pode ser definido como uma  seleção  sobre a relação  r.  A 
reconstrução da relação r pode ser feita pela união de todos os fragmentos.
2)  Fragmentação vertical:  em sua  forma mais simples a  fragmentação 
vertical   é   como   uma   decomposição.   Essa   fragmentação   de  r(R)  implica   na 
definição de vários subconjuntos de atributos  R1,  R2,   ...,  Rn  do esquema  R.  A 
fragmentação deve ser feita de tal forma que possamos reconstruir a relação r, a 
partir dos fragmentos, por meio de uma junção natural.
2.3.3.2 Replicação de dados
Como   o   principal   objetivo   deste   trabalho   é   o   estudo   de   técnicas   e 
algoritmos de replicação, esse assunto será aprofundado na subseção 2.4.
2.3.3.3 Transparência
Para Özsu (2001), em bancos de dados centralizados, o único recurso que 
precisa   ser   isolado   dos   usuários   são   os   dados.   Já   em   bancos   de   dados 
distribuídos, existe um segundo recurso que precisa ser tratado da mesma forma: 
a rede.  Assim, o usuário não deveria perceber diferenças entre  trabalhar com 
bancos   de   dados   distribuídos   ou   centralizados.   Este   isolamento   é   conhecido 
como transparência de rede.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
45
Outra transparência que deve existir em bancos de dados distribuídos é a 
independência   dos   dados.   Essa   independência   é   uma   forma   fundamental   de 
transparência que procura­se em SGBD tanto centralizados como distribuídos, 
pois é através dela que os aplicativos são imunes às mudanças na organização e 
na definição dos dados, e vice­versa. Por exemplo, se existirem dados que estão 
armazenados   em   dois   discos,   com   sistema   de   arquivos   diferentes,   ou 
organizados  de maneira  diferente   (acesso  aleatório  aos  dados  versus  acesso 
seqüencial   indexado),  ou  mesmo se estivessem separados em hierarquias  de 
memórias diferentes (disco rígido versus fita), o aplicativo do usuário não deve se 
preocupar   com   estes   aspectos  de  organização   física.   Isso  é   o   que  define  a 
independência dos dados (Özsu, 2001).
Na  transparência  de   replicação,   justamente  por  causa da  replicação de 
uma base de dados, pode­se gerar um problema na atualização dos dados. A 
questão da transparência está envolvida na necessidade ou não do usuário saber 
se existem uma ou mais réplicas da base. A resposta para essa questão é: claro 
que ele não precisa. Assim, existem diversas técnicas para o mesmo, que serão 
discutidas na subseção 2.4.
A última transparência que deve existir é a transparência de fragmentação. 
Levando­se  em consideração  que  as   relaçõesestão   fragmentadas  em vários 
locais,   as   consultas   devem   acontecer   como   se   o   banco   de   dados   fosse 
centralizado. Pois, embora as consultas sejam especificadas sobre as relações, a 
dificuldade   está   em   encontrar   uma   estratégia   para   o   processamentos   das 
mesmas em fragmentos, isto é, para a conversão de consultas globais em várias 
consultas de fragmentos.
Por   fim,   conclui  Özsu   (2001)   que   a  responsabilidade   sobre   as 
transparências necessárias para a distribuição dos dados pertence ao SGBD.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
46
2.3.4 Arquitetura de SGBDDs
A arquitetura do SGBDD define sua estrutura, isto é, os componentes são 
identificados, suas funções são especificadas e os inter­relacionamentos entre os 
componentes   são   definidos.   Existem   diversas   arquiteturas   possíveis   para 
SGBDDs, sendo que será realizada  a análise de três que englobem os aspectos 
mais relevantes delas.
2.3.4.1 Sistemas cliente/servidor
Os SGBDs cliente/servidor, conforme Özsu (2001), entraram no cenário da 
computação no  início da década de 1990. A  idéia  geral  é  simples e elegante: 
separar as funcionalidades que precisam ser fornecidas em duas classes: funções 
de servidores e funções de clientes. As funções de servidores devem funcionar 
nos   computadores   servidores   e   as   funções   clientes   devem   funcionar   nos 
computadores clientes.
É   importante   observar   que   todo   processamento   e   otimização   das 
consultas, gerenciamento de transações e gerenciamento de armazenamento de 
dados fica no lado do servidor. Assim, no lado do cliente, apenas fica o cliente de 
SGBD responsável  pelo  gerenciamento de dados que  ficam em  cache  (Özsu, 
2001).
Existem   diferentes   tipos   de   arquiteturas   cliente/servidor.   No   caso   mais 
simples,   apenas   um   servidor   é   acessado   por   um   ou   mais   clientes.   Essa 
arquitetura é denominada vários clientes­servidor único e segue os princípios dos 
bancos de dados centralizados. Contudo, uma arquitetura cliente/servidor mais 
sofisticada  possui  vários  servidores  que  são  acessados  por  diversos  clientes. 
Nessa arquitetura, vários clientes­vários servidores, existem duas estratégias para 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
47
gerenciamento:   ou   cada   cliente   gerencia   suas   conexões   com   os   servidores 
adequados,   ou   cada   cliente   conhece   apenas   seu   servidor   local   e   este   se 
comunica  com os demais  servidores   (Özsu,  2001).  A  FIGURA 3 mostra  uma 
arquitetura cliente/servidor.
S
is
te
m
a 
op
er
ac
io
na
l
Interface do 
usuário
Programa 
aplicativo
...
SGBD cliente
Software de comunicação
Consultas
SQL
Relação
resultado
S
is
te
m
a 
op
er
ac
io
na
l
Software de comunicação
Controlador semântico de dados
Otimizador de consultas
Gerenciador de transações
Gerenciador de recuperação
Processador de suporte runtime
FIGURA 3 ­ Arquitetura cliente/servidor de referência
Fonte: Özsu (2001, p. 95).
Banco de
dados
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
48
2.3.4.2 Sistemas distribuídos não­hierárquicos
Nos   sistemas   distribuídos   não­hierárquicos,   geralmente   a   organização 
física dos dados dos computadores é  diferente. Assim, é necessário existir um 
esquema interno local (EIL) para cada computador, com a definição da estrutura 
local.  A visão global  dos  dados é  descrita  por  um  esquema conceitual  global 
(ECG).   Esse   esquema   descreve   a   estrutura   lógica   dos   dados   de   todos   os 
computadores (Özsu, 2001).
Continua o autor explicando que, como em banco de dados distribuídos os 
dados   geralmente   estão   replicados   ou   fragmentados   é   necessário   ter   uma 
descrição da organização lógica dos dados de cada computador numa terceira 
camada, o  esquema conceitual local  (ECL). Dessa forma o esquema conceitual 
global passa a ser a união dos dois esquemas locais.
  Finaliza Özsu (2001),  o acesso aos dados pelos usuários é  através do 
esquema   externo  (EE)   que   fica   localizado   uma   camada   acima   do   esquema 
conceitual global. A FIGURA 4 mostra o modelo de arquitetura descrita.
FIGURA 4 ­ Arquitetura de banco de dados distribuído de referência
Fonte: Özsu (2001, p. 97).
ECL
2
EIL
1
EIL
2
EIL
n
EE
2
EE
1
ECL
1
EE
n
ECL
n
ECG
...
...
...
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
49
2.3.4.3 Arquitetura de SVBDs
A diferença fundamental dos sistemas de vários bancos de dados (SVBDs) 
distribuídos   e   dos   SGBDs   distribuídos   se   relaciona   à   definição   do   esquema 
conceitual  global.  Enquanto  nos SGBDs distribuídos  logicamente   integrados o 
esquema conceitual global define a visão conceitual do banco de dados inteiro, 
nos SVBDs distribuídos ele define apenas a coleção de alguns dos bancos de 
dados   locais   de   cada   SVBD   que   se   quer   compartilhar.   Assim,   nos   SGBDs 
distribuídos o  banco de dados global  é  a  união dos bancos de dados  locais, 
enquanto que nos SVBDs distribuídos, ele é apenas um subconjunto da mesma 
união (Özsu, 2001). A FIGURA 5 mostra o modelo de arquitetura descrita.
FIGURA 5 ­ Arquitetura de SVBD com um ECG
Fonte: Özsu (2001, p. 101).
2.3.5 Tolerância a falhas
A tolerância a falhas é  uma abordagem muito  importante em bancos de 
dados  distribuídos. Ela é  definida como uma característica pela qual o sistema 
pode mascarar  a  ocorrência  de   falhas  para  se   ter  alta  disponibilidade  de um 
sistema. Em outras palavras,  um sistema gerenciador de banco de dados,  ou 
EIL
1
EIL
n
ECL
1
ECL
n
ECG
...
...
EEG
2
EEG
1
EEG
3
EEL
12
EEL
11
EEL
13
EEL
n2EEL
n1
EEL
n3
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
50
mesmo qualquer sistema, é tolerante a falhas se consegue continuar operando 
em caso de ocorrerem falhas (Tanenbaum, 2002).
Na   seqüência   são   descritas   as   principais   métricas   de   avaliação   da 
tolerância   a   falhas,   os   possíveis   tipos   de   falhas   e   formas   de   mascarar   as 
possíveis falhas de um sistema.
2.3.5.1 Dependabilidade
O   principal   objetivo   da   tolerância   a   falhas   é   alcançar   dependabilidade 
(dependability), que indica a qualidade do serviço fornecido por um determinado 
sistema   e   a   confiança   depositada   nesse   serviço.   As   principais   métricas   de 
avaliação da tolerância a falhas são (Weber, 2001):
● Confiabilidade   (reliability):   É   a   capacidade   de   atender   as 
especificações, dentro das condições definidas, durante certo período 
de   funcionamento   e   condicionado   a   estar   operacional   no   início   do 
período;
● Disponibilidade   (availability):   Probabilidade   do   sistema   estar 
operacional num instante de tempo determinado;
● Segurança (safety): probabilidade do sistema ser ou estar operacional 
e executar suas funções corretamente, ou descontinuar suas funções 
de forma que não provoque danos a outros sistemas ou pessoas que 
dele dependam;
● Segurança   (security):   proteção   contra   falhas   maliciosas,   visando 
privacidade, autenticidade, integridade e irrepudiabilidade dos dados.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
51
2.3.5.2 Tipos de falhas
Segundo Tanenbaum (2002),  existem diversas categorias de  falhas que 
podem ocorrer:
● Crash   failure:   ocorre   quando   um   processo   está   sendo   executado 
normalmente, mas inesperadamente termina/morre;
● Omission  failure:  ocorrequando um processo não  responde a  uma 
requisição;
● Performance failure: ocorre quando uma requisição demora demais a 
ser atendida;
● Timing failure: ocorre quando um reposta de uma requisição está fora 
do intervalo de tempo especificado;
● Response   failure:  ocorre   quando   o   valor   da   resposta   de   uma 
requisição está incorreto ou quando um processo é desviado do correto 
fluxo de controle;
● Arbitrary failure:  um servidor produz respostas arbitrárias em tempos 
arbitrários.
2.3.5.3 Mascarando falhas com redundância
Partindo do princípio de que nenhum sistema está livre de falhas, o melhor 
que pode ser  feito é  esconder/mascarar estas falhas, para que o sistema não 
retorne um erro.  A chave para  conseguir   isto  é  a   redundância,  que pode ser 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
52
conseguida  através  quatro   formas:   redundância  de  hardware,   redundância  de 
software, redundância de tempo e redundância de informação (Weber, 2001).
Para  Tanenbaum (2002),  a  técnica para prover  tolerância a  falhas mais 
conhecida   é   a   redundância   de   hardware.   Ela   é   aplicada   na   biologia   (seres 
humanos possuem dois olhos, duas orelhas, dois rins), na aviação (alguns aviões 
possuem quatro motores, mas pode voar com menos) e até nos esportes (vários 
jogadores reservas).
Weber   (2001)   afirma   que   a   redundância   de   informação   é   provida   por 
códigos de correção de erros, como EEC (error correction code) que vem sendo 
usados na comunicação das memórias e nos processadores.
Como a codificação da informação implica no aumento do número de bits, 
e os bits adicionais não aumentam a capacidade de representação de dados do 
código,  é   fácil  perceber  a   razão da codificação  também ser  considerada uma 
forma de redundância.
A redundância de tempo repete a computação no tempo, ou seja, evita o 
custo de hardware adicional, aumentando o tempo necessário para realizar uma 
computação. É  bastante usada em sistemas cujos processadores passam boa 
parte do tempo ociosos e onde o tempo não é um fator crítico.
A   cópia   de   um   sistema,   como   se   faz   com   o   hardware,   não   é   uma 
alternativa inteligente, pois a cópia é idêntica e vai apresentar os mesmos erros. 
Contudo,   existem   algumas   técnicas   de   programação   que   podem   criar 
redundância  a  nível  de  software,   como por   exemplo  a   criação  de  programas 
escritos de forma diferente, a criação de blocos de recuperação e a verificação de 
consistência (Weber, 2001).
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
53
2.4 Replicação
Uma   replicação   pode   ser   feita   por   diversos   motivos.  Independente   do 
motivo – se for para aumentar o desempenho de consultas;  ter uma cópia de 
segurança; ter alta disponibilidade e tolerância a falhas; ou resolver problemas 
geográficos de acesso – o importante é saber escolher a forma como será feita a 
replicação, pois a replicação implica na sincronização permanente dos bancos de 
dados. De forma geral, as replicações aumentam o desempenho para operações 
de   leitura   da   base   de   dados,   entretanto   as   atualizações   geram   um   grande 
overhead  (custo   adicional   de   processamento   ou   armazenamento).   Cada 
informação replicada é chamada de objeto (Özsu, 2001).
2.4.1 Tipos de replicação
Na utilização de banco de dados distribuídos, replicados, é preciso avaliar 
o  delay  de   atualização   dos   bancos   de   dados.   Assim,   existem   dois   tipos   de 
replicação: síncrona e assíncrona.
2.4.1.1 Síncrona
Para Pedroni e Ribeiro (2006),  replicação síncrona é  aquela em que os 
dados são replicados em tempo real, ou seja, ao inserir dados num determinado 
banco, os mesmos são replicados para os demais, no mesmo momento. Isso é 
feito de forma garantida com a utilização de transações. Este tipo de replicação é 
ideal para aplicações que necessitam ter os dados atualizados de forma muito 
precisa.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
54
A grande desvantagem no uso desse tipo de replicação, é que existe uma 
perda significativa de performance, pois os processos tornam­se mais  lentos e 
ainda dependentes da estrutura da rede, caso os bancos de dados estejam em 
hosts diferentes.
Outro problema que pode ocorrer é que um host pode estar indisponível e 
dessa forma, a transação não seria efetivada.
Um exemplo hipotético de instruções para esse tipo de replicação seria o 
exemplificado no EXEMPLO 2.
BEGIN TRANSACTION;
INSERT INTO foo (1, 'banco de dados');
REPLICAR();
END TRANSACTION;
EXEMPLO 2 ­ Exemplo hipotético de instruções SQL para replicação síncrona
Fonte: Elaborado pelo autor com base em Pedroni e Ribeiro (2006).
2.4.1.2 Assíncrona
Também   conhecida   como   replicação   não   sincronizada,   a   replicação 
assíncrona faz a réplica dos dados não instantaneamente. Essa replicação é feita 
dentro de uma transação separada, onde a partir do momento que a transação é 
executada, o replicador lê um histórico das ações executadas no banco de dados 
a ser   replicado e  replica para o(s)  outro(s).  Assim,  a   réplica pode ser   feita  a 
qualquer momento (Pedroni; Ribeiro, 2006).
A   grande   desvantagem   nessa   replicação,   explicam   as   autoras,   é   que 
eventuais erros ou conflitos não são detectados imediatamente, pois a cópia será 
efetivada como um todo somente no final da transação. Outra desvantagem é que 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
55
as informações dos bancos de dados dos  hosts envolvidos não estarão sempre 
atualizados.
Um   exemplo   hipotético   de   instruções   para   esse   tipo   de   replicação   é 
mostrado no EXEMPLO 3.
INSERT INTO foo (1, 'banco de dados');
INSERT INTO foo (2, 'replicação assíncrona');
UPDATE ...
BEGIN TRANSACTION;
REPLICAR();
END TRANSACTION;
EXEMPLO 3 ­ Exemplo hipotético de instruções SQL para replicação assíncrona
Fonte: Elaborado pelo autor com base em Pedroni e Ribeiro (2006).
2.4.2 Modelos de replicação
Os modelos  de   replicação  definem uma  estrutura  que  especifica  quais 
servidores   poderão   replicar   para   os   demais.   Os   modelos   de   replicação   são: 
single­master  ou  master­slave  e  multi­master   (Elnikety;  Dropsho;  Zwaenepoel,  
2006).
2.4.2.1 Single­master ou master­slave
Nessa forma de replicação, existe um servidor mestre que faz somente a 
replicação para  os  demais  escravos.  Enquanto  o  servidor  mestre  possibilita  a 
leitura   e   a   escrita   de   dados   por   parte   dos   usuários,   os   servidores   escravos 
permitem somente a leitura, sendo que a escrita é feita através das replicações do 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
56
servidor   mestre.   As   operações   de   réplica   para   os   servidores   escravos,   são 
executadas na mesma ordem que foram executadas no servidor mestre. Esse 
modelo   de   replicação   pode   ser   tanto   síncrono   como   assíncrono   (Elnikety; 
Dropsho; Zwaenepoel, 2006). A FIGURA 6 mostra um exemplo dessa estrutura.
FIGURA 6 ­ Exemplo do modelo de replicação single­master
Fonte: Elaborado pelo autor com base em Elnikety, Dropsho e Zwaenepoel (2006).
2.4.2.2 Multi­master
Elnikety, Dropsho e Zwaenepoel (2006) afirmam que na replicação  multi­
master, os usuários podem ler e escrever em qualquer servidor. Os servidores por 
sua vez, terão que replicar as informações para os demais servidores. Isso exige 
um mecanismo mais elaborado para as transações e replicações. Esse modelo de 
replicação também pode ser tanto síncrono como assíncrono. A