Tema 3 - Sistemas de banco de dados distribuídos

Prévia do material em texto

21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 1/91
Implementação de
Banco de Dados
Distribuídos
Prof. Sidney Nicolau Venturi Filho
Descrição
O processamento de transações em um Banco de Dados Distribuídos e
o seu controle durante a execução concorrente.
Propósito
Entender as técnicas que dão suporte ao funcionamento das transações
e consultas em um Banco de Dados Distribuídos é de importância
fundamental para o profissional de T.I.
Preparação
Para os procedimentos propostos neste conteúdo, sugerimos que
instale o PostgreSQL em sua máquina e em uma máquina virtual.
Objetivos
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 2/91
Módulo 1
Controle de transação distribuída
Reconhecer as técnicas utilizadas em transações distribuídas.
Módulo 2
Controle de concorrência em banco de dados
distribuídos
Analisar as técnicas de controle de concorrência.
Módulo 3
Consultas distribuídas
Identificar as formas de otimização de consultas em bancos de
dados distribuídos.
Módulo 4
SQL em consultas distribuídas
Aplicar comandos utilizando SQL em consultas distribuídas.
Introdução

21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 3/91
Os bancos de dados distribuídos trazem novos desafios para
temas que há muito tempo são estudos na área de banco de
dados. O processamento de transações, o controle do acesso
concorrente aos itens de dados o processamento de consultas e
a escrita de comandos SQL necessitam ser ajustados à realidade
da distribuição dos dados.
Este é nosso grande propósito neste conteúdo, analisar como um
banco de dados distribuído pode ser implementado.
1 - Controle de transação distribuída
Ao �nal deste módulo, você será capaz de reconhecer as técnicas utilizadas em transações
distribuídas.
Fundamentos de transação
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 4/91
Neste vídeo, apresentaremos os fundamentos de uma transação de
banco de dados, abodaremos os conceitos de atomicidade, isolamento,
consistência, durabilidade e quais são os tipos de transações em banco
de dados distribuídos.
O que é uma transação?
Uma transação pode ser conceituada como o conjunto de operações
executadas por um usuário em um banco de dados que é visto pelo
SGBD como uma unidade lógica que precisa manter certas propriedades
para garantir o sucesso sem perda de informações lógicas.
A abertura da uma transação pode ser realizada de forma explícita ou
implícita. Conheça as diferenças a seguir.
Abertura explícita
É realizada pelo
comando BEGIN
TRANSACTION.
Abertura implícita
Ocorre em alguns SGBD,
como por exemplo, o
ORACLE, onde ao se
emitir o primeiro
comando é aberta
automaticamente uma
transação.
O término de uma transação pode ocorrer pelos seguintes motivos:
I
Por uma falha no processamento de um comando: indica que
todas as alterações realizadas pela transação serão desfeitas
automaticamente.
II

21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 5/91
Pelo comando COMMIT emitido pelo usuário: indica ao banco
de dados que a transação terminou e faz com que as
alterações realizadas sejam efetivadas nas tabelas.
III
Pelo comando ROLLBACK emitido pelo usuário: indica ao
banco de dados que a transação terminou e faz com que as
alterações realizadas sejam desfeitas nas tabelas.
No conceito de transação, falamos algumas propriedades que devem
ser mantidas. Mas quais são elas? Uma transação deve atender a um
conjunto de propriedades denominada ACID, que quer dizer:
 A
Atomicidade
 C
Consistência
 I
Isolamento
 D
Durabilidade
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 6/91
A seguir, apresentaremos cada uma destas propriedades de maneira
detalhada.
Atomicidade
A propriedade da atomicidade implica que uma transação é uma
unidade única, ou seja, se realizam todas as operações ou não se realiza
nenhuma.
A seguir, temos a tabela de contas correntes de um banco. O cliente J.
Silva possui duas contas, 1000 e 1002, e deseja fazer uma transferência
entre elas.
NRCC Nome CPF Saldo
1000 J. Silva 123 500,00
1001 A. Barros 143 500,00
1002 J. Silva 123 200,00
1003 S. Sales 223 500,00
Tabela: Conta corrente.
Sidney Nicolau Venturi Filho
Uma transferência pode ser entendida como um débito na conta 1000 e
o posterior crédito na conta 1002. Inicialmente, é comandado o débito,
veja o comando a seguir:
SQL 
A imagem a seguir, exemplifica a operação de débito realizada:
UPDATE CONTA
SET SALDO = SALDO – 200
WHERE NRCC = 1000
1
2
3
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 7/91
Débito na conta 1000.
Em seguida, é comandado o crédito, conforme o código a seguir:
SQL 
Veja na imagem como ficaria a operação de crédito realizada:
Crédito na conta 1002.
Porém, antes que a transação seja efetivada, ocorre um erro no banco,
ou seja, a operação de crédito falha (imagem a seguir).
UPDATE CONTA
SET SALDO = SALDO + 200
WHERE NRCC = 1002
1
2
3
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 8/91
O crédito na conta 1002.
Note que o débito foi realizado, mas o crédito não. Isso ocorre devido ao
fato de que cada operação foi considerada uma transação separada,
alguns SGBD como o SQL SERVER, ao não receberem um comando
explicito de abertura de transação, fazem COMMIT automático de cada
comando.
Esse comportamento, como no caso do exemplo, leva a um erro, pois
como se tratava de uma transferência, não faz sentido realizar apenas
uma das operações. Então, devemos “prender” os dois comandos em
uma única transação, vejamos o código a seguir:
SQL 
Veja, na próxima imagem, a operação realizada:
Transferência realizada.
BEGIN TRANSACTION
UPDATE CONTA
SET SALDO = SALDO – 200
WHERE NRCC = 1000
UPDATE CONTA
SET SALDO = SALDO + 200
1
2
3
4
5
6
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 9/91
Consistência
Esta propriedade estabelece que a execução de uma transação isolada
(ou seja, sem a execução de outra transação qualquer
concorrentemente) preserva a consistência do banco de dados.
Uma transação deve levar um banco de um estado consistente para
outro estado consistente, igual ou diferente do estado anterior, ainda
que durante sua execução o banco fique inconsistente (imagem a
seguir).
Execução de transação.
Veja um exemplo, considere a tabela de conta corrente ilustrada na
imagem a seguir. Voltemos à situação do cliente que deseja fazer uma
transferência de R$200,00 da conta 1000 para conta 1002.
Conta corrente.
Qual é a posição consistente neste caso? A soma do saldo da conta
1000 com a da conta 1002 é de R$700,00. Desta forma, ao final da
transação, a soma dos saldos dever ter este valor:
SQL 
BEGIN TRANSACTION
UPDATE CONTA
1
2
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 10/91
Se a transação termina com COMMIT, a transação é efetivada e a soma
dos saldos é R$700,00. Portanto, temos um novo estado consistente,
pois o saldo de cada uma das contas mudou, como podemos conferir
na imagem a seguir:
Transferência realizada.
Entretanto, se a transação termina com ROLLBACK, as operações são
desfeitas e o banco de dados volta ao estado consistente inicial, já que
a soma do saldo continua sendo R$700,00. Observe na imagem.
Transferênciacancelada.
Isolamento
A propriedade do isolamento define que as operações de uma transação
não podem ser afetadas pelas operações de outra transação que esteja
sendo executada de forma concorrente.
Para exemplificar, vamos retornar ao exemplo da conta corrente a partir
da tabela a seguir.
SET SALDO = SALDO – 200
WHERE NRCC = 1000
UPDATE CONTA
SET SALDO = SALDO + 200
3
4
5
6
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 11/91
NRCC Nome CPF Saldo
1000 J. Silva 123 500,00
1001 A. Barros 143 500,00
1002 J. Silva 123 200,00
1003 S. Sales 223 500,00
Tabela: Conta corrente.
Sidney Nicolau Venturi Filho
Observe a sequência do exemplo a seguir:
Leitura do saldo
Imagine que o cliente Antônio Barros, conta 1001, vai ao caixa
eletrônico para fazer um saque de R$200,00. Para poder
efetivar o saque, o sistema então lê o saldo de R$500,00.
T2 bloqueada
Neste mesmo instante, ocorre o débito automático de uma
conta de R$300,00 do cliente, para poder efetivar o pagamento
o sistema quer fazer a leitura do saldo da conta, porém agora a
transação 1 (saque) bloqueou o acesso ao saldo da conta o
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 12/91
que impede a transação 2 (pagamento da conta) de continuar
até que T1 faça COMMIT ou ROLLBACK.
Atualização pelo saque
T1 continua, atualiza o saldo, comanda COMMIT e o saque é
efetivado.
Leitura do saldo pelo pagamento
Como T1 fez commit, a leitura do saldo por T2 foi liberada e a
transação pode continuar.
Atualização pelo pagamento
T2 agora leu o saldo, após a atualização de T1 (R$300,00), faz
o pagamento da conta, atualiza o saldo e executa o commit.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 13/91
Resultado
Como resultado, temos que o cliente possuía um saldo inicial
de R$500,00, teve um conta de R$300,00 paga, sacou
R$200,00, portanto, utilizou R$500,00. Ao final, ficou com um
saldo de R$0,00, ou seja, as transações concorrentes
produziram o resultado correto devido ao isolamento das
transações.
Durabilidade
Esta propriedade estabelece que depois de a transação ser completada
com sucesso, as mudanças que ela faz no banco de dados persistem,
até mesmo se houver falha no sistema.
Se o usuário que fez a transferência do exemplo acima recebeu uma
informação que ela foi realizada, o SGBD deve garantir que, mesmo se
ocorrer uma falha, como crash de servidor, quando ele for restaurado, a
transferência deve constar ainda nos dados.
Para tal, arquivos de LOG e mecanismos de recuperação são utilizados.
Tipos de transações em banco de dados distribuídos
Uma solicitação de usuário em um banco de dados distribuídos pode
gerar dois tipos de transações:
Transações locais
Definidas como aquelas que acessam apenas dados no próprio banco
local onde se originou.
Transações globais
Definidas como aquelas que afetam mais de um banco local.
Cada um desses tipos exige uma forma de controle diferente.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 14/91
Mecanismos de controle de
transações locais
Neste vídeo, apresentaremos formas de reconhecer os mecanismos de
controle de transações locais, também falaremos sobre o
gerenciamento de transação e arquivos de LOG.
Controle de transações em bancos locais
O controle do processamento de uma transação local é praticamente
igual ao de uma transação em um banco centralizado. A imagem a
seguir mostra a arquitetura de um SGBD local:
Arquitetura do SGBD.
A partir da imagem apresentada, podemos destacar:
Responsável por:
O otimizador de consulta 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 15/91
Receber o comando.
Determinar o seu plano de execução.
Executar a consulta.
Inserir, remover e modificar as linhas e tabelas da base de
dados.
Alterar os metadados.
Responsável pela execução da transação e controle da
concorrência.
Responsável por tratar os problemas decorrentes de uma falha
no SGBD.
Gerenciador de transação
As consultas e demais ações no banco de dados são agrupadas em
transações, que, como vimos, devem ser executadas de forma atômica
e durável, ou seja, o efeito de uma transação que foi completada deve
ser preservado mesmo após uma falha do sistema.
Em seu trabalho, o gerenciador de transação cria um identificador para
cada transação (TId) e o armazena em suas tabelas de controle. Além
disso, ele lida com o fato de que várias transações podem estar sendo
executadas de forma concorrente no banco de dados e, eventualmente,
tentarem acessar o mesmo item de dado, podendo gerar graves
problemas na consistência do banco.
Arquivo de LOG
Todo SGBD tem um arquivo de dados onde as informações são
armazenadas. A cada comando SQL submetido, o SGBD abre
implicitamente uma transação, caso esse comando não esteja incluído
dentro de uma transação explicitamente requisitada pelo usuário ao
SGBD. Desta forma, todo comando SQL está implicitamente ou
explicitamente dentro de uma transação.
Quando alguma informação é requisitada por uma transação, uma cópia
dela é criada na memória. Cada operação da transação vai sendo então
O gerenciador de transação 
O mecanismo de recuperação 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 16/91
gravada no buffer do log existente na memória, como ilustra a tabela a
seguir:
Identificador
Transação
TId
Linha
Anterior
Transação
Linha
Posterior
Transação
Operação
Realização
Transação
T1 0 1 INICIAR
T1 1 4 ESCREVER
T2 0 9 INICIAR
T1 2 5 ESCREVER
T1 4 8 LER
T3 0 7 LER
Tabela: Extrato de entradas do arquivo de LOG.
Sidney Nicolau Venturi Filho
Mecanismos de controle de
transações globais
Neste vídeo, você vai conhecer os mecanismos de controle de
transações em bancos globais.
Controle de transações em bancos globais
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 17/91
Quando falamos de controle de transações globais, a arquitetura
utilizada para o controle deve ser expandida para incluir o controle da
consulta global. Veja a imagem a seguir:
Arquitetura de controle de transações globais.
A partir da imagem, podemos observar que surgem então dois novos
módulos:
Responsável por montar o plano de execução da consulta,
quando esta envolve o acesso a mais de um banco local.
Realiza o controle da transação global sendo responsável por:
Iniciar a execução da transação.
Dividir a transação em subtransações e distribuí-las aos
bancos de dados locais que as devem executar.
Coordenar o término da transação global, que pode resultar
em ser efetivada ou abortada em todos os sites envolvidos.
Uma questão que surge neste ponto é: existe então um SGBDD para
controlar as transações globais?
Na realidade não, as funções associadas ao banco global (imagem
anterior) são realizadas pelo SGBD local que primeiro recebeu a
consulta global e que assume as tarefas de otimização e coordenação
Otimizador de consulta global 
Coordenador de transação global 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 18/91
globais. Na implementação da arquitetura, cada SGBD local possui uma
cópia do banco de dados global que engloba o diretório de dados global
(DDG) e o coordenador de transações global.
Diretório de dados global
Contém descrições dos objetos lógicos e físicos e dos
mapeamentos entre estes.
Ao receber uma consulta e identificá-la como uma
transação global, o SGBD local cria seu plano de
execução, atribuium TId, define as subtransações e as
envia aos demais sites para execução.
Durante o processamento da transação global, cada site executa a sua
subtransação usando os mesmos mecanismos de execução de uma
transação global e, ao produzir o resultado, o retorna ao site de origem.
Após todos os sites terem produzido o resultado, o coordenador de
transação global irá definir se os efeitos da transação devem ser
efetivados ou desfeitos (abortados).
Protocolos para con�rmação de
transação distribuída
Neste vídeo, apresentaremos formas de identificar os protocolos para
confirmação de transação distribuída, bem como os tipos de protocolos,
a confirmação em duas ases e a confirmação em três fases.
Tipos de protocolos
Para decidir que uma transação dever ser efetivada ou abortada, o
coordenador deve levar em conta se:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 19/91

Todos os bancos locais tiveram sucesso na execução de suas
subtransações.

O usuário que fez a solicitação não comandou ROLLBACK.

Não ocorreu uma falha em algum ponto do sistema.
Para obter os dados necessários para tomar a sua decisão, o
coordenador de transação pode utilizar um dos seguintes de protocolos
de confirmação (COMMIT):

Confirmação em duas fases.

Confirmação em três fases.
Con�rmação em duas fases
O protocolo de confirmação em duas fases (two phase commit – 2PC) é
muito simples e elegante, garantindo a atomicidade de transações
distribuídas. Ele estende os efeitos das ações locais de confirmação
atômica para transações distribuídas, insistindo que todos os sites
envolvidos na execução de uma transação distribuída concordem em
confirmar a transação antes que seus efeitos se tornem permanentes.
Apresentaremos o funcionamento do protocolo, observe, inicialmente, a
fase 1:
O coordenador, que corresponde ao SGBD que iniciou a transação,
avisa aos bancos locais sobre a intenção de realizar o commit
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 20/91
enviando uma mensagem “prepare” e registra em seu log o início da
efetivação.
Se o banco local estiver em condições de fazer o commit, ele anota
no seu log que está “pronto” para commit e envia um voto de
commit para o coordenador.
Se o banco local não estiver em condições, ele registra no seu log
“Abort” e envia um voto para abortar ao coordenador.
Agora, apresentaremos a fase 2:
Após receber os votos de todos os bancos locais envolvidos na
transação, o coordenador apura o resultado. Se houver pelo menos
um voto “abort”, o coordenador envia a todos os bancos locais a
mensagem para abortar, caso contrário, se todos os votos forem
favoráveis, ele envia uma mensagem commit. E, em ambos os
casos, o coordenador anota em seu log a decisão tomada.
Os bancos locais, ao receberem a decisão do coordenador, adotam
a ação indicada e fazem as anotações em seu log e após terminar
notifica o coordenador que conclui a operação.
A operação do protocolo 2PC entre um coordenador e um participante
na ausência de falhas está representada na imagem a seguir, na quak os
círculos indicam os estados, os estados terminais são representados
por círculos concêntricos e as linhas tracejadas indicam as mensagens
entre o coordenador e os participantes.
Protocolo de Confirmação em duas fases.
Quanto ao funcionamento do protocolo, devemos notar que a regra de
confirmação global estabelece que é necessário que todos os
participantes votem pela confirmação, se apenas um votar para abortar
a transação será cancelada. Alguns pontos importantes sobre o
protocolo 2PC que podem ser observados na imagem anterior são:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 21/91
Con�rmação em três fases
A confirmação em três fases (three phase commit – 3PC) surgiu como
uma evolução do 2PC para lidar com o fato de que, se o coordenador
falhar antes da confirmação, todos os bancos locais ficarão bloqueados
 O 2PC permite que um participante aborte
unilateralmente uma transação até que tenha
registrado um voto afirmativo.
 Uma vez que um participante vota para confirmar
ou abortar uma transação, ele não pode mudar seu
voto.
 Enquanto um participante está no estado Pronto,
ele pode se mover para abortar a transação ou
confirmá-la, dependendo da natureza da mensagem
do coordenador.
 A decisão de cancelamento é tomada pelo
coordenador de acordo com a regra de confirmação
global.
 O coordenador e participante entram em
determinados estados em que precisam aguardar
mensagens um do outro. Para garantir que eles
possam sair desses estados e terminar, são usados
temporizadores.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 22/91
à espera da recuperação do site de origem, o que diminui o
desempenho.
Para lidar com isso, este protocolo realiza uma primeira fase igual a fase
1 do 2PC, uma segunda fase com novas operações e uma terceira fase
igual à fase 2 do 2PC. Em resumo:
Fase 1
Igual à fase1 do 2PC.
Fase 2
Acrescida pelo 3PC.
Fase 3
Igual à fase2 do 2PC.
Podemos notar então que o início e final dos dois protocolos são iguais.
A diferença é a “nova” fase2. Vamos ver em detalhes como ela funciona.
Após o coordenador receber os votos dos bancos locais, final
da fase 1, ele envia uma mensagem “Preparar para Confirmar”
a todos os sites envolvidos na transação.
Os bancos locais ao receberem a mensagem anotam em seu
log preparar para commit e informam ao coordenador que
estão prontos para confirmar.
O coordenador ao receber a mensagem de todos os envolvidos
para a fase 3, essa será igual à fase 2 do 2PC.
Este protocolo, apesar de resolver alguns problemas do 2PC, não foi
implementado na prática devido ao aumento da latência, gerado por
uma maior troca de mensagens entre os sites.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 23/91
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Considere que um usuário emitiu os seguintes comandos:
BEGIN TRANSACTION
UPDATE CONTA SET SALDO = SALDO - 300 WHERE NRCC = 1002;
COMMIT;
BEGIN TRANSACTION
UPDATE CONTA SET SALDO = SALDO + 300 WHERE NRCC = 1001;
COMMIT;
Sabendo-se que o usuário deseja fazer uma transferência entre as
contas, podemos concluir que, quanto às propriedades das
transações, se o segundo UPDATE não for efetivado
Parabéns! A alternativa C está correta.
Embora pareça que a atomicidade foi violada, essa foi uma opção
do usuário ao não envolver os dois comandos em uma única
transação. Mas a consistência dos dados foi violada, já que o valor
total final não corresponde à transferência que se desejava realizar.
A todas as propriedades foram atendidas.
B a atomicidade foi violada.
C a consistência foi violada.
D o isolamento foi violado.
E a durabilidade foi violada.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 24/91
Questão 2
Considere o seguinte cenário:
Um site denominado 5 recebeu uma transação que envolvia o
acesso aos sites 2, 3 e 4.Após definir as subtransações, enviou-as
aos sites que deveriam as executar. Após a mensagem “prepare”
enviada pelo coordenador de transação, os sites responderam:
Site 2 COMMIT;
Site 3 ABORT;
Site 4 COMMIT.
Sabendo-se que o sistema utiliza a confirmação em duas fases,
podemos afirmar que:
O coordenador irá enviar a mensagem commit para os sites
Porque:
Na confirmação em duas fases, quando a maioria vota pelo commit,
ele é realizado.
Quantos às afirmativas, selecione a opção correta.
Parabéns! A alternativa E está correta.
A primeira afirmativa está errada porque no protocolode
confirmação em duas fases basta um site votar pelo abort para a
transação ser abortada. A segunda é falsa porque, apesar de alguns
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
D A primeira afirmação é falsa e a segunda correta.
E As duas afirmações são falsas.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 25/91
protocolos de confirmação levarem em conta a maioria, no 2PC
basta um votar abort para que todos tenham que abortar a
transação.
2 - Controle de concorrência em banco de dados distribuídos
Ao �nal deste módulo, você será capaz de analisar as técnicas de controle de concorrência.
Transações concorrentes
Neste vídeo, apresentaremos o que são transações correntes e quais
são principais problemas gerados por essas transações.
O que são transações concorrentes?
Observe a seguir, o conteúdo de uma tabela de contas correntes de um
banco.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 26/91
NRCC Nome CPF Saldo
1000 J. Silva 123 500,00
1001 A. Barros 143 500,00
1002 J. Silva 123 200,00
1003 S. Sales 223 500,00
Tabela: Conta corrente.
Sidney Nicolau Venturi Filho
Observe a sequência do exemplo a seguir:
Leitura do saldo
Agora, imagine que o cliente Antônio Barros, conta 1001, vai a
ao caixa eletrônico para fazer um saque de R$200,00. Para
poder efetivar o saque, o sistema lê o saldo de R$500,00.
Leitura do saldo com outra operação simultânea
Neste mesmo instante, ocorre o débito automático de uma
conta de R$300,00 do cliente, para poder efetivar o pagamento
o sistema faz a leitura do saldo da conta, R$500,00 realiza o
pagamento e atualiza o saldo para R$200,00.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 27/91
Atualização pelo débito da conta
Em seguida, acontece a atualização do sistema pelo débito da
conta.
Atualização pelo saque
Após atualização, o saque é efetivado e o saldo da conta
atualizado.
Resultado
Como resultado, temos que o cliente possuía um saldo inicial
de R$500,00, teve um conta de R300,00 paga, sacou R$200,00.
Portanto utilizou R$500,00. Mesmo assim, ficou com um saldo
de R300,00.
Devido ao fato de terem ocorrido duas operações em paralelo em cima
do mesmo conjunto de dados, o que caracteriza o acesso concorrente, a
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 28/91
aplicação de controle da conta corrente não soube lidar corretamente
com a situação.
A anomalia aconteceu afetando o isolamento entre as transações e a
sua consistência. Como se pode lidar com esta situação então? Por
meio dos mecanismos de controle de acesso concorrente do SGBD.
Problemas gerador por transações concorrentes
Quando ocorre acesso concorrente, alguns problemas podem acontecer
pela intercalação inadequada das operações nas transações, como:
Problema da atualização perdida;
Problema da atualização temporária ou leitura suja (dirty read);
Problema da leitura que não pode ser repetida (nonrepeatable read);
Problema da leitura fantasma (phantom read);
Problema do resumo incorreto.
Vamos conhecer com mais detalhes esses problemas.
Problema da atualização perdida
Este problema ocorre quando duas transações acessam o mesmo
conjunto de dados de forma concorrente e têm suas operações
intercaladas, o que faz com que gerem um resultado incorreto.
Observe, na tabela a seguir, um conjunto de operações realizado por
duas transações (T1 e T2 de forma intercalada). Assumindo que os
valores de X é 90 e de N é 3, vejamos como ocorrem as operações.
Instante Operação A B C X
1
T1 lê X para
A
90 90
2
T1 subtraí
N de A
87 90
3
T2 lê X para
C
87 90 90
4
T2 soma n
a C
87 93 90
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 29/91
Instante Operação A B C X
5
T1
sobrescreve
X com A
87 92 87
6
T2 lê
sobrescreve
X com C
87 90 92 93
Tabela: Atualização perdida.
Sidney Nicolau Venturi Filho
Ainda sobre a tabela anteriormente apresentada, note que X tinha o
valor inicial de 90, T1 subtrai 3 dele e T2 somou 3. Então, ao final, ele
deveria continuar com 90, mas seu valor final é 93. Isso aconteceu
porque a atualização feita por T1 no instante 5 foi perdida por T2 que
continuou utilizando o valor original de X.
Problema da atualização temporária ou leitura suja (dirty read)
Este problema ocorre quando uma transação atualiza um dado e outra
transação o lê antes que a primeira tenha sido efetivada (commit). Se a
transação da atualização falhar ou for desfeita (rollback), a transação
que leu irá operar com dados incorretos.
Observe, na tabela a seguir, um conjunto de operações realizado por
duas transações (T1 e T2 de forma intercalada). Assumindo que os
valores de X é 90 e de N é 3, como ocorrem as operações?
Instante Operação A B X T1
1
T1 lê X para
A
90 90
Leia
(x,a);
2
T1 subtraí
N de A
87 90
a: = a -
n;
3
T1
sobrescreve
X com A
87 87
Escreva
(a,x)
4
T2 lê X para
B
87 87 87
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 30/91
Instante Operação A B X T1
5
T2 soma n
a C
87 90 87
Escreva
(a,x)
6
T2
sobrescreve
X com B
87 90 90
7 T1 Falha 87 90 90 Falha
Tabela: Leitura suja.
Sidney Nicolau Venturi Filho
O que está errado?
Como T1 falhou, a atualização de X para 87 não deveria ter ocorrido.
Portanto, T2 deveria ter utilizado o valor 90 e não 87 e o resultado
deveria ser 93.
Problema da leitura que não pode ser repetida (nonrepeatable read)
Este problema ocorre quando uma transação lê o mesmo dado duas
vezes e o seu valor é alterado por outra transação entre as leituras.
Observe, na tabela a seguir, um conjunto de operações realizado por
duas transações (T1 e T2 de forma intercalada). Assumindo que os
valores de X é 90 e de N é 3, vamos ver como as operações ocorrem.
Instante Operação A C X T1
1
T1 lê X para
A
90 90
Leia (x,
a) ;
2
T1 subtraí
N de A
87 90
a: = a –
n;
3
T2 lê X para
C
87 90 90
4
T1
sobrescreve
X com A
87 90 87
Escreva
(a, x)
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 31/91
Instante Operação A C X T1
5
T2 lê X para
C
87 87 87
Tabela: Leitura não repetível.
Sidney Nicolau Venturi Filho
Quando T2 fez a primeira leitura de X, obteve o valor 90 no instante 3,
porém, quando fez uma nova leitura, obteve um valor diferente no
instante 5, que foi 87. Isso ocorreu devido ao fato de, no instante 4, T1
ter atualizado o valor de X.
Problema da leitura fantasma (phantom read)
Este problema ocorre quando uma transação, ao ler dados lidos
anteriormente, descobre que o conjunto de linhas retornados é diferente
do anterior, pois, entre as leituras, outra transação inseriu novas linhas
na tabela.
Apesar de parecida com a leitura não repetível, a diferença reside no
fato de os dados anteriormente lidos não terem mudado, apenas foram
acrescentados novos dados.
Considere a seguinte tabela de alunos. apresentada na imagem a seguir:
Uma transação T1 deseja listar os alunos do curso 1 e obteria o
seguinte resultado demonstrado na imagem a seguir:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 32/91
Após a execução deste comando, uma transação T2 insere duas novas
linhas na tabela apresentada na imagem a seguir:
Alterando os dados da tabela que fica com as seguintes linhas,
demonstrada na imagem a seguir:
T1 ao repetira consulta anterior, obterá o seguinte resultado:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 33/91
Note que apareceu uma nova linha no resultado, a linha 3 que não
existia antes. Esta é a linha fantasma.
Problema do resumo incorreto
Este problema ocorre quando uma transação está realizando uma
agregação de dados e os valores com os quais ela vai operar são
alterados durante a sumarização.
Observe, na tabela a seguir, um conjunto de operações realizado por
duas transações (T1 e T3 de forma intercalada). Assumindo que os
valores de X e Y são iguais a 90 e o valor de N é 3, vejamos como
ocorrem as operações.
Tabela: Resumo incorreto.
Sidney Nicolau Venturi Filho
O que está errado? Como o valor inicial de X era 90 e foi reduzido para
87 por T1 no instante 4, quando T3 o lê atualiza o somador com este
valor. A seguir faz a leitura de Y que ainda não foi atualizado e, portanto,
acrescenta 90 ao somador totalizando 177. Entretanto, como o valor
final de X é 87 e de Y, 93, o resultado da soma deveria ser 180.

21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 34/91
Controle de concorrência
Neste vídeo, apresentaremos formas de identificar os principais
controles de concorrência, particularmente nas execuções serial e
intercalada.
Princípio de funcionamento do controle de concorrência
A ideia básica do controle de concorrência é produzir um resultado
consistente, ou seja, produzir o mesmo resultado que seria obtido se as
transações tivessem sido executadas uma depois da outra.
Então, uma escala de execução de transações sempre será correta se o
seu resultado corresponder ao obtido por uma execução sequencial
delas. Cabe ao SGBD definir o plano de escalonamento, ou seja, a forma
como as transações serão executadas.
Execução serial
Neste tipo de plano, as transações são escalonadas para serem
executadas uma depois da outra. Apresentaremos dois exemplos de
execução serial, veja o primeiro a seguir:
T1 T2
Leia (x,a);
a: = a - 50;
Escreva (a,x);
Leia (y,b);
b: = b + 50;
Escreva (b,y);
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 35/91
T1 T2
Leia (x,c);
temp: = a * 0,1;
c: = c - temp;
Escreva (c,x);
Leia (y,d);
d: = d + temp;
Escreva (d,y)
Tabela: Exemplo 01, execução serial.
Sidney Nicolau Venturi Filho
Veja na tabela a seguir o segundo exemplo de execução serial:
T1 T2
Leia(x,c);
temp:= a * 0,1;
c:=c-temp;
Escreva(c,x);
Leia(y,d);
d:= d + temp;
Escreva(d,y)
Leia(x,a);
a:=a-50;
Escreva(a,x);
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 36/91
T1 T2
Leia(y,b);
b:=b+50;
Escreva(b,y);
Tabela: Exemplo 02, execução serial.
Sidney Nicolau Venturi Filho
Vamos analisar os dois escalonamentos passo a passo, para tal vamos
considerar os valores de X e Y como sendo 120 e 90, respectivamente.
vejamos na tabela a seguir o escalonamento 01:
Tabela: Escalonamento 01.
Sidney Nicolau Venturi Filho
Note que o valor final de X é 63 e de Y é 154. Vamos agora ver o
escalonamento 02:
Tabela: Escalonamento 02.
Sidney Nicolau Venturi Filho
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 37/91
Note que o valor final de X é 58 e de Y é 149, diferentes, portanto, do
valores obtidos ao final do escalonamento 01.
Isso significa que um deles está errado? Não! Os dois estão corretos,
qualquer resultado obtido por uma execução serial de transações
sempre está correto.
Execução intercalada
Quando as operações das transações são executadas de forma
intercalada, a execução intercalada estará correta sempre que o seu
resultado corresponder ao resultado de uma execução sequencial.
Vamos voltar às duas transações do exemplo anterior, veja a tabela a
seguir:
T1 T2
Leia (x,a); Leia (x,c);
a: = a-50; temp: = a * 0,1;
Escreva(a,x); c: = c-temp;
Leia (y,b); Escreva (c,x);
b: = b + 50; Leia (y,d);
Escreva(b,y); d: = d + temp;
Escreva (d,y)
Tabela: Transações de exemplo.
Sidney Nicolau Venturi Filho
Para análise dos escalonamentos intercalados, vamos considerar os
valores de X e Y, 120 e 90, respectivamente.
A tabela a seguir mostra o primeiro escalonamento intercalado:
T1 T2
Leia(x,a);
a:=a-50;
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 38/91
T1 T2
Escreva(a,x);
Leia(x,c);
temp:= a * 0,1;
c:=c-temp;
Escreva(c,x);
Leia(y,b);
b:=b+50;
Escreva(b,y);
Leia(y,d);
d:= d + temp;
Escreva(d,y)
Tabela: Escalonamento intercalado.
Sidney Nicolau Venturi Filho
Vejamos a seguir o resultado do escalonamento intercalado 01:
Tabela: Escalonamento intercalado 01.
Sidney Nicolau Venturi Filho
Note que o valor final de X é 63 e de Y é 154, que corresponde a um dos
resultados obtidos na execução serial. Portanto, este escalonamento
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 39/91
está correto.
Vamos agora ver o escalonamento 02:
T1 T2
Leia(x,a);
a:=a-50;
Leia(x,c);
temp:= a * 0,1;
c:=c-temp;
Escreva(c,x);
Escreva(a,x);
Leia(y,b);
b:=b+50;
Escreva(b,y);
Leia(y,d);
d:= d + temp;
Escreva(d,y)
Tabela: Escalonamento intercalado.
Sidney Nicolau Venturi Filho
Vejamos a seguir o resultado do escalonamento intercalado 02:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 40/91
Tabela: Escalonamento intercalado 02.Sidney Nicolau Venturi Filho
Note que o valor final de X é 70 e o valor de Y é 154, o que não
corresponde a qualquer dos resultados obtidos na execução serial (X 63
e Y 154 ou X 58 e Y 149). O escalonamento, portanto, está errado e não
deve ser utilizado.
O erro ocorre no passo 3, quando T2 lê o valor de X antes dele ser
atualizado por T1 (atualização perdida). As questões que surgem então
são: “como uma execução intercalada pode produzir resultados
inconsistentes, deveria sempre ser utilizado um escalonamento serial?”
Em um mundo perfeito sim, mas no mundo real a execução serial tem o
indesejável efeito de aumentar o tempo de resposta se diversas
transações desejam acessar o mesmo conjunto de dados, já que
somente uma delas será executada de cada vez.
Por este motivo, os SGBDs utilizam escalonamento intercalado, mas
somente aqueles que produzem resultados equivalentes a uma
execução serial.
Controle de concorrencia nas
transações locais
Neste vídeo, apresentaremos os principais tipos de controles de
concorrência nas transações locais e falaremos sobre o protocolo
baseado em bloqueio (controle pessimista).
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 41/91
Tipos de controle de concorrencia
Como as transações locais apenas acessam dados em seu próprio
banco, o seu controle é em tudo similar ao de bancos centralizados.
Então, para que o isolamento e a consistência sejam de fato possíveis, é
necessário que o SGBD realize o controle de concorrência entre as
transações locais podendo, para isso, utilizar basicamente dois
métodos de controle distintos, que são:
Partem da premissa de que as transações conflitam entre si na
maioria das execuções e estabelecem protocolos para o acesso
exclusivo aos dados pelas operações.
Baseiam-se na premissa de que a maioria das transações não
possui operações conflitantes entre si, possibilitando livre
acesso aos valores dos objetos de dados. Ao final da execução
de uma transação – ao receber o comando de commit – fazem a
avaliação da história produzida. Caso o SGBD verifique a
violaçãodo isolamento, a transação é desfeita.
Cada um desses métodos pode ser implementado com a utilização de
diversos protocolos, conforme apresentaremos a seguir, veja as
diferenças:
Métodos pessimistas 
Métodos otimistas 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 42/91
Métodos de controle
pessimista
Bloqueio
Timestamp
Híbrido
Métodos de controle
otimista
Timestamp
Multiversão
Confira esses métodos em formato de gráfico a seguir:
Tipos de Protocolos de métodos de controle de concorrência.
Desses protocolos, os mais utilizados são:
Bloqueio
Para o controle pessimista.
Timestamp
Para o controle otimista.
Protocolo baseado em bloqueio (controle pessimista)
Este é o tipo de protocolo que mais nos interessa em Bancos de Dados
Distribuídos.
Neste tipo de protocolo, quando uma transação T1 acessa um item de
dado, nenhuma outra pode acessá-lo. Para que isso aconteça, T1 deve
colocar um bloqueio (lock) no item de dado que deseja manipular. Aliás,
toda transação deve obrigatoriamente colocar um bloqueio em um item
de dados antes de o acessar, seja para leitura ou para escrita.
Esta solicitação é feita ao controlador de concorrência. A transação só
poderá executar qualquer operação depois que o controlador de
concorrência conceder (grant) o bloqueio do dado para a transação.

21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 43/91
Existem basicamente dois tipos de bloqueio:
Quando uma transação T1 deseja apenas ler um dado. Este
bloqueio permite que outras transações possam ler o dado, mas
não possam alterá-lo.
Quando uma transação T1 deseja alterar um dado. Este bloqueio
não permite que outras transações possam ler ou alterar o dado
bloqueado.
A tabela a seguir mostra a compatibilidade entre os tipos de bloqueio:
Compartilhado Exclusivo
Compartilhado Compatível Incompatível
Exclusivo Incompatível Incompatível
Tabela: Compatibilidade dos tipos de bloqueio.
Sidney Nicolau Venturi Filho
Podemos ver, na tabela a seguir, que duas transações diferentes podem
colocar um bloqueio compartilhado no mesmo item de dados, já que
apenas irão fazer leitura. Porém, se uma transação colocar um bloqueio
exclusivo, pois deseja escrever, as outras ficarão sem acesso ao item
até que ele seja liberado.
INSTANTE T1 T2
Controle de
Concorrência
1 Lock-X(b);
2 Grant-X(b,T1)
3 Leia(b);
Compartilhado (S) 
Exclusivo (X) 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 44/91
INSTANTE T1 T2
Controle de
Concorrência
4 b:=b-50;
5 Escreva(b)
6
Lock-
S(a);
Grant-S(a,T2)
7 Leia(a);
8
Lock-
S(b);
9 Lock-S(a);
10 Grant-S(a,T2)
11 Leia(a);
Tabela: Transações concorrentes.
Sidney Nicolau Venturi Filho
Vamos analisar a execução passo a passo. Veja a tabela a seguir:
Instante Operação Observação
1
T1 solicita
bloqueio
exclusivo sobre B
2
T1 ganha acesso
exclusivo sobre B
B bloqueado para outras
transações
3 T1 lê B Para a memória
4 T1 subtrai 50 de B Na memória
5
T1 atualiza B no
banco
Grava a atualização no
disco
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 45/91
Instante Operação Observação
6
T2 solicita
bloqueio
compartilhado
sobre A
7
T2 ganha acesso
compartilhado
sobre A
A bloqueado para
transações de escrita e
liberado para bloqueios
de leitura
8 T2 lê A Para a memória
9
T2 solicita
bloqueio
compartilhado
sobre B
Como B tem um bloqueio
exclusivo T2 bloqueia
10
T1 solicita
bloqueio
compartilhado
sobre A
Como A tem um bloqueio
compartilhado T1
também coloca o
bloqueio e ganha acesso
a A.
A tem dois bloqueios
compartilhados agora,
um de T1 e um de T2
11 T1 lê A Para a memória
Tabela: Passo a passo.
Sidney Nicolau Venturi Filho
Note que durante a execução:
No instante 9, T2 bloqueou, pois, apesar de desejar apenas ler, T1
colocou um bloqueio exclusivo.
No instante 10, T1 pediu um bloqueio compartilhado em A, como
ele é compatível com o bloqueio compartilhado colocado por T2 no
instante 7, T1 pode prosseguir.
Deadlock
O uso de bloqueios pode provocar o Deadlock. Mas, o que vem a ser
isso? Imagine que temos duas transações sendo executadas de forma
concorrente, como mostrado na tabela a seguir:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 46/91
Instante T1 T2
Controle de
Concorrência
1 Lock-X(b);
2 Grant-X(b,T1)
3 Leia(b);
4 b:=b-50;
5 Escreva(b);
6
Lock-
S(a);
7 Grant-S(a,T2)
8 Leia(a);
9
Lock-
S(b);
10 Lock-X(b);
11 Situação de Deadlock
Tabela: Transações concorrentes.
Sidney Nicolau Venturi Filho
Vamos analisar a execução passo a passo, veja a tabela a seguir:
Instante Operação Observação
1
T1 solicita
bloqueio exclusivo
sobre B
2
T1 ganha acesso
exclusivo sobre B
B bloqueado para outras
transações
3 T1 lê B Para a memória
4 T1 subtrai 50 de B Na memória
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 47/91
Instante Operação Observação
5
T1 atualiza B no
banco
Grava a atualização no
disco
6
T2 solicita
bloqueio
compartilhado
sobre A
7
T2 ganha acesso
compartilhado
sobre A
A bloqueado para
transações de escrita e
liberado para bloqueios
de leitura
8 T2 lê A Para a memória
9
T2 solicita
bloqueio
compartilhado
sobre B
Como B tem um
bloqueio exclusivo T2
bloqueia
10
T1 solicita
bloqueio exclusivo
sobre A
Como B tem um
bloqueio compartilhado
T1 bloqueia
11 DEADLOCK
Nem T1 nem T2 podem
prosseguir
Tabela: Passo a passo.
Sidney Nicolau Venturi Filho
Como resolver o Deadlock? Existem basicamente duas estratégias:
Prevenção
Impedir que o deadlock aconteça realizando um controle maior da
concessão de bloqueios.
Detecção
Ao detectar que o deadlock ocorreu, resolver o conflito.
Como realizar a prevenção é muito custosa em termos de
processamento, pois a maioria dos SGBDs utiliza a detecção e ao
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 48/91
identificá-la realizam ROLLBACK do lock colocado por uma das
transações, isso libera a outra pra prosseguir.
Controle de concorrência em
transações globais
Neste vídeo apresentaremos, a partir de uma visão geral do controle de
concorrência de bancos de dados distribuídos, os principais controles
de concorrência nas transações globais. Além disso, vamos falar sobre
o protocolo de bloqueio em duas fases.
Visão geral do controle de concorrência em bancos de dados
distribuídos
Em comparação com um banco centralizado, um banco de dados
distribuído apresenta novos desafios para o controle de concorrência,
como:
 Lidar com múltiplas réplicas das tabelas, que exige
que o controle de concorrência mantenha a
consistência do banco global.
 Falha de sites individuais, o que acarreta o
problema de uma transação ser bem-sucedida em
um deles e não poder ser completada em outro.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 49/91
Protocolo de bloqueio em duas fases (two phase lock - 2PL)
No controle de transação distribuída, é utilizada uma variação do
protocolo de bloqueio denominado protocolo de bloqueio em duas
fases, que facilita a obtenção da serialização das transações.
Este protocolo exige que todas as operações de bloqueio, tanto de
leitura como de gravação, sejam efetivadas antes que a primeira
operação de desbloqueio ocorra.
Podemos dividir a execução da transação em duas fases:
Expansão ou
crescimento
Novos bloqueios em
itens podem ser
obtidos, mas nenhum
liberado.
Encolhimento
Os bloqueiosexistentes
são liberados, mas
nenhum novo pode ser
obtido.
Observe a tabela a seguir, na qual são exibidas duas transações que não
seguem o protocolo de duas fases, porque o operação Lock-X(X) segue
a operação unlock(Y) em T1 e, de maneira semelhante, a operação Lock-
 Falha dos links de comunicação, que pode tornar
um dos bancos locais inacessíveis.
 Confirmação distribuída, o que exige a adoção do
commit em duas fases ou em três fases.
 Ocorrência de Deadlock distribuído, o que exige a
extensão das técnicas de prevenção e detecção
para este ambiente bem mais complexo.

21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 50/91
X (Y) segue a operação unlock (X ) em T2 e cuja execução serial produz
os resultados apresentados.
T1 T2
Lock-S(Y) Lock-S(X)
Leia(Y) Leia(X)
Lock-X(X) Unlock(X)
Unlock(Y) Lock-X(Y)
Leia(X) Leia(Y)
X: = X + Y Y: = Y+X
Escreva (X) Escreva (Y)
Unlock (X) Unlock (Y)
Valores Iniciais X = 20 Y = 30
Execução serial T1 e depois T2 X = 50 Y = 80
Execução serial T2 e depois T1 X=70 Y = 50
Tabela: Transações que não seguem o 2PL.
Sidney Nicolau Venturi Filho
Note que, como T1 e T2 não seguem o protocolo de duas fases, elas
podem produzir uma sequência de execução que não produz o resultado
equivalente a um serial, veja na tabela a seguir e considere que X = 50 e
y = 50 (Não serializável):
T1 T2
Lock-S(Y)
Leia(Y)
Unlock(Y)
Lock-S(X)
Leia(X)
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 51/91
T1 T2
Unlock(X)
Lock-X(Y)
Leia(Y)
Y:=Y+X
Escreva(Y)
Lock-X(X) Unlock(Y)
Leia(X)
X:=X + Y
Escreva(X)
Unlock(X)
Tabela: Transações que não seguem o 2PL.
Sidney Nicolau Venturi Filho
Para forçar o 2PL, as transações devem ser reescritas como exibido na
tabela a seguir, o que garante a serialização.
T1 T2
Lock-S(Y) Lock-S(X)
Leia(Y) Leia(X)
Lock-X(X) Lock-X(Y)
Unlock(Y) Unlock(X)
Leia(X) Leia(Y)
X: = X + Y Y: = Y+X
Escreva (X) Escreva (Y)
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 52/91
T1 T2
Unlock (X) Unlock (Y)
Tabela: Transações que seguem o 2PL.
Sidney Nicolau Venturi Filho
Controle de concorrência distribuído baseado em uma cópia
distinguida de um item de dados
Para lidar com dados replicados, foram propostas extensões das
técnicas utilizadas em bancos centralizados, passando pela designação
de uma das réplicas dos dados como sendo a responsável pelo controle
de concorrência (cópia distinguida).
Esta técnica pode assumir métodos diferentes para a escolha da cópia
distinguida, como:

Site primário

Site primário com site de backup

Cópia primária
Site primário
Um único site é designado para realizar a coordenação para todos os
itens do banco de dados global, ficando responsável, portanto, pelo
controle de todos os bloqueios, recebendo todas as solicitações de
acesso dos outros sites. Neste caso, se todas as transações seguirem o
protocolo de bloqueio em duas fases, a serialização está garantida.
Sua grande vantagem é ser uma extensão simples da técnica
centralizada sendo relativamente simples. Suas desvantagens são:
Como todas as solicitações de bloqueio são dirigidas a um único
site, ele pode ficar sobrecarregado, causando um gargalo no
sistema.
Uma falha do site principal paralisa o sistema, pois toda a
informação de bloqueio é mantida nesse site.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 53/91
Site primário com site de backup
Para enfrentar a segunda desvantagem citada, um segundo site é
designado como backup e mantém cópia das informações de bloqueio,
o que permite que em caso de falha do primário ele assuma.
Técnica de cópia primária
O controle de concorrência é distribuído por vários sites, cada um
controlando um conjunto distinto de itens de dados. Quando um dos
sites de controle falha, todas as transações que estão acessando os
dados que ele controla ficam prejudicadas.
Para melhorar a confiabilidade, podem ser utilizados sites de backup.
Controle de concorrência distribuído baseado em votação
Neste tipo de controle de concorrência, a solicitação de bloqueio de um
item de dados é enviada para todos os bancos que possuem uma
réplica. Cada site então realiza o seu controle, podendo conceder ou
negar o bloqueio.
Se a transação que solicitou o bloqueio, o recebe da maioria dos sites,
ela mantém o bloqueio e informa a todos que o obteve. Caso contrário,
se a transação não recebe o bloqueio da maioria dos sites, ela cancela
sua solicitação e informa a todos que não realizará o bloqueio.
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
A imagem a seguir mostra o retorno de uma consulta realizada por
um usuário.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 54/91
Logo a seguir, dentro da mesma transação, ele repetiu a consulta e
obteve o seguinte resultado:
A respeito dos resultados obtidos, podemos afirmar que ocorreu a
anomalia de transação denominada
A atualização perdida.
B atualização temporária ou leitura suja (dirty read).
C
leitura que não pode ser repetida (nonrepeatable
read).
D leitura fantasma (phantom read).
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 55/91
Parabéns! A alternativa B está correta.
Os resultados mostram que, entre duas leituras do mesmo item de
dados realizados por uma mesma transação, o seu valor foi
modificado por outra transação, o que caracteriza leitura suja.
Questão 2
A tabela a seguir mostra as operações de duas transações T1 e T2.
Quanto à serialização das duas transações, podemos afirmar que:
Elas seguem o protocolo de bloqueio em duas fases.
Porque
No protocolo 2PL todos os bloqueios devem ocorrer antes da
primeira liberação.
Quantos às afirmativas, assinale a alternativa correta.
E resumo incorreto.
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 56/91
Parabéns! A alternativa D está correta.
A primeira afirmativa é falsa porque, apesar de T1 seguir o
protocolo, T2 não segue, já que ocorre o desbloqueio de X antes do
bloqueio de Y. Já a segunda afirmativa é verdadeira, pois realizar
todos os bloqueios antes do primeiro desbloqueio é a característica
do protocolo de bloqueio em duas fases.
3 - Consultas distribuídas
Ao �nal deste módulo, você será capaz de identi�car as formas de otimização de consultas
em bancos de dados distribuídos.
Consultas locais
Neste vídeo, falaremos sobre a otimização e execução de comandos
locais e as estratégias para otimização de consultas.
D A primeira afirmação é falsa e a segunda correta.
E As duas afirmações são falsas.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 57/91
Otimização e execução de comandos locais
A otimização e execução de uma consulta local é, em sua totalidade,
similar à execução de consultas em um banco de dados centralizado.
Ao receber uma consulta, um SGDB gera um plano de execução para o
seu processamento, seguindo para isso um processo de várias etapas,
confira a seguir:
 Análise sintática
A sintaxe da consulta é verificada e os erros são
apontados.
 Análise semântica ou validação
É checada a existência de tabelas, visões e colunas,
bem como são realizadas verificações de tipos dos
atributos e dados utilizadosna consulta.
 Reescrita de consulta
É realizada a reescrita do SQL em uma
representação interna derivada da álgebra
relacional.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 58/91
Estratégias para otimização de consultas
Inicialmente, o SGBD executa a otimização heurística de consultas, que
compreende transformar a consulta SQL em uma expressão algébrica.
A partir da expressão algébrica, é realizada a reordenação de suas
operações visando obter uma expressão mais eficiente. Baseando-se na
expressão otimizada, o SGBD pode definir os métodos de acesso e os
algoritmos adequados para a execução da consulta.
Após a otimização heurística, o SGBD irá analisar os metadados e
escolher os algoritmos para acesso físico ao conteúdo dos arquivos.
Neste ponto, ele pode utilizar duas abordagens:
O otimizador utiliza um conjunto de heurísticas para transformar
a consulta em um plano de acesso. Por exemplo, o otimizador
poderia sempre escolher utilizar um índice que esteja disponível
sobre uma coluna.
O otimizador consulta os metadados sobre as tabelas do banco
de dados para determinar qual o plano mais eficiente, mais
 Otimização da consulta
Por meio s de um conjunto de regras, o SGBD
manipula a sua representação interna e procura a
estratégia de execução considerada mais eficiente.
 Geração de código
De posse do plano otimizado, ocorrem as
chamadas ao processador de execução do SGBD.
Otimização por regras 
Otimização por custo 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 59/91
rápido, para execução da consulta.
Ao término da otimização, é gerado o plano de execução, que determina
as operações a serem realizadas, métodos de acesso, algoritmos a ser
utilizados, índices etc.
Métodos de acesso aos dados de tabelas
Estes métodos determinam a forma como as linhas de uma tabela
serão acessadas. Vejamos dois tipos de varreduras:
Comumente chamada de Full Table Scan (Varredura Completa
de Tabela), compreende a leitura sequencial de todas as linhas
de uma tabela.
Geralmente, é a opção feita pelo otimizador quando precisa
selecionar a totalidade das linhas da tabela, não existindo outro
método de acesso adequado ou devido a utilização de alguns
operadores como IS NULL, LIKE, <> etc.
A determinação das linhas a serem acessadas é realizada a
partir de um ou mais índices aplicados as colunas da tabela.
Este método é muito eficiente na recuperação de um
subconjunto restrito dos dados.
Operações realizadas em consultas
Além de definir o método de acesso, o plano de execução especifica as
operações a serem realizadas. Veja a seguir:
Ordenação
Operação básica para diversas outras operações físicas, sendo
implementada pela cláusula ORDER BY. Se o conjunto a ser
ordenado não cabe em memória, esta operação pode ser muito
Varreduras sequenciais 
Varredura indexada 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 60/91
cara. Pode ser utilizada em DISTINCT, UNION, INTERSECTION,
JOIN e outras cláusulas.
Eliminação de duplicatas e agregações
Estas operações são implementadas, em geral, através de uma
ordenação (sorting) para realizar o agrupamento (GROUP BY).
Após a ordenação pelo critério de agregação, o resultado é
varrido e a operação é computada. Também é possível resolver
este tipo de operação através de técnicas de hash.
Operações que atuam em mais de uma tabela
Para permitir a integração de dados de mais de uma tabela, o
plano de execução pode utilizar operações de conjunto (união,
interseção e diferença) e junções.
Consultas globais
Neste vídeo, falaremos sobre o processamento de uma consulta global
e apresentaremos o esquema de distribuição, as estratégias de solução,
o cálculo do custo e o processamento de consulta distribuído, usando
semijunção.
Passos para o processamento de consultas globais
O processamento de consultas globais ocorre em vários passos,
vejamos a seguir:
Mapeamento da consulta 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 61/91
A consulta de entrada é analisada sintática e semanticamente,
com base no esquema conceitual global do banco de dados e, a
seguir, transformada em algum tipo de representação algébrica
interna, similar ao que foi visto no processamento do banco
local, sem levar em conta como os dados estão distribuídos.
Da expressão algébrica gerada no mapeamento, o SGBDD
localiza os metadados da distribuição do banco de dados,
determinando quais fragmentos possuem os itens de dados
necessários, bem como verificando se eles estão ou não
replicados e em quais sites residem, mapeando a consulta
distribuída no esquema global para consultas separadas para
cada um dos fragmentos/copias dos itens de dados.
O objetivo deste passo é encontrar uma estratégia de execução
que seja a mais eficiente possível, ou seja, de menor custo,
utilizando o tempo como unidade de medida. Para o cálculo do
custo, são levados em conta além dos tempos de CPU e E/S, os
de comunicação, que nos BDD são, inclusive, mais significativos.
Após a análise dos custos, é gerado o plano de execução
distribuído para o banco global.
O SGBD global envia aos diversos bancos locais a parte do plano
que lhes cabe executar. Os bancos locais, então, definem o seu
plano de execução local, produzem o resultado e o retornam ao
site de origem.
Vejamos as etapas do processamento de consultas globais
esquematizado na imagem a seguir:
Localização de dados 
Otimização global da consulta 
Execução distribuída 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 62/91
Processamento de consultas globais.
Exemplo de processamento de consulta global
Para este exemplo, considere o esquema conceitual global apresentado
na imagem a seguir:
Esquema conceitual global.
Considere agora que foi submetida a seguinte consulta no site 5:
SQL 
Esquema de distribuição
No esquema de distribuição, foi realizada a fragmentação horizontal das
tabelas, mantendo a disjunção da seguinte forma:
 Site 1
T b l EMPREGADO d i d EMP1
SELECT NOME
FROM EMPREGADO E 
 INNER JOIN ALOCPROJ A ON E.MAT = A.MAT
 WHERE CARGO = ‘GERENTE’
1
2
3
4
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 63/91
Estrategias de solução
Duas estratégias podem ser utilizadas para realizar a consulta.
Vejamos inicialmente a estratégia A:
Transferir ALOCPROJ1 do site 3 para o site 1 onde será realizada a
junção com EMPREGADO1.
Transferir ALOCPROJ2 do site 4 para o site 2 onde será realizada a
junção com EMPREGADO2.
Transferir os resultados, R1 e R2, das junções dos sites 1 e 2 para o
site 5 que as combinaria e produziria a resposta final.
Tabela EMPREGADO denominada EMP1 com as
linhas dos empregados cuja matrícula seja menor
ou igual a que 10.
 Site 2
Tabela EMPREGADO denominada EMP2 com as
linhas dos empregados cuja matrícula seja maior
que 10.
 Site 3
Tabela ALOCPROJ denominada ALOCPROJ1 com
as linhas dos empregados cuja matrícula seja
menor ou igual a que 200.
 Site 4
Tabela ALOCPROJ denominada ALOCPROJ2 com
as linhas dos empregados cuja matrícula seja maior
que 200.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 64/91
Vejamos na imagem a seguir o esquema gráfico que representa este
processo.
Esquema gráfico do processo da estratégia A.
Vejamos a seguir a estratégia B:
Transferir EMPREGADO1 do site 1 para o site 5.
Transferir EMPREGADO2 do site 2 para o site 5.
Transferir ALOCPROJ1 do site 3 para o site 5.
TransferirALOCPROJ2 do site 4 para o site 5.
Realizar as junções e demais operações no site 5 e produzir a
resposta final.
Vejamos na imagem a seguir o esquema gráfico que representa o
processo da estratégia B:
Esquema gráfico do processo da estratégia B.
Cálculo do custo
Para o cálculo do custo, vamos assumir os seguintes dados:
EMPREGADO1 possui 200 linhas.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 65/91
EMPREGADO2 possui 200 linhas.
ALOCPROJ1 possui 500 linhas com 10 linhas de gerentes.
ALOCPROJ2 possui 500 linhas com 10 linhas de gerentes;
O custo de acesso a uma linha é de 1 unidade de custo (UC).
O custo de transferência de uma linha entre os sites são 10
unidades de custo (UC).
Vejamos a seguir os custos da estratégia A e da estratégia B:
1. Transferir ALOCPROJ1 para site 1 requer 5000 UC.
2. Transferir ALOCPROJ2 para site 2 requer 5000 UC.
3. Filtrar ALOCPROJ1 no site 1 requer 500 UC.
4. Filtrar ALOCPROJ2 no site 2 requer 500 UC.
5. Produzir R1 no site 1 requer 200 UC no processamento da
junção.
�. Produzir R2 no site 1 requer 200 UC no processamento da
junção.
7. Transferir R1 para o site 5 requer 100 UC.
�. Transferir R2 para o site 5 requer 100 UC.
9. Produzir o resultado no site 5 requer 20 UC.
Custo Total: 11620 UC
1. Transferir EMPREGADO1 do site 1 para o site 5 requer 2000
UC.
2. Transferir EMPREGADO2 do site 2 para o site 5 requer 2000
UC.
3. Transferir ALOCPROJ1 do site 3 para site t requer 5000 UC.
4. Transferir ALOCPROJ2 do site 4 para site 5 requer 5000 UC.
5. Filtrar ALOCPROJ1 no site 5 requer 10 UC.
�. Filtrar ALOCPROJ2 no site 5 requer 10 UC.
7. Realizar a junção entre EMPREGADO e as filtragens de
ALOLCPROJ no site 5 e produzir o resultado requer 8000
UC.
Custo da estratégia A 
Custo da estratégia B 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 66/91
Custo Total: 22020 UC
Podemos notar que a estratégia A é melhor que a B, apesar de ainda
possuir um custo relativamente alto. Será que podemos melhor? Sim,
utilizando semijunção.
Processamento de consulta distribuído usando sem�unção
O objetivo de executar semijunção é reduzir o número de linhas a ser
transferido de um site para outro.
A ideia envolve transferir de um site A para o site B apenas a coluna
envolvida na condição de junção. No site b, a junção é realizada entre a
coluna recebida e seus itens de dados, sendo o resultado então enviado
para o site que produzirá o resultado.
Voltando ao exemplo de cálculo de custo, vamos ver a estratégia C.
Produzir no site 3 o conjunto com a matrícula dos gerentes (G1).
Produzir no site 4 o conjunto com a matrícula dos Gerente (G2).
Transferir G1 do site 3 para o site 1, onde será realizada a junção
com EMPREGADO1.
Transferir G2 do site 4 para o site 2, onde será realizada a junção
com EMPREGADO2.
Transferir os resultados, R1 e R2, das junções dos sites 1 e 2 para o
site 5 que as combinaria e produziria a resposta final.
Vejamos na imagem a seguir o esquema gráfico que representa o
processo da estratégia C:
Esquema gráfico do processo da estratégia C.
Vejamos a seguir o cálculo de custo da estratégia C:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 67/91
1. Produzir G1 no site 1 requer 500 UC.
2. Produzir G2 no site 2 requer 500 UC.
3. Transferir G1 para site 1 requer 100 UC.
4. Transferir G2 para site 2 requer 100 UC.
5. Produzir R1 no site 1 requer 200 UC no processamento da
junção.
�. Produzir R2 no site 1 requer 200 UC no processamento da
junção.
7. Transferir R1 para o site 5 requer 100 UC.
�. Transferir R2 para o site 5 requer 100 UC.
9. Produzir o resultado no site 5 requer 20 UC.
Custo Total: 1820 UC
Observe como o uso da semijunção diminui muito o custo com a
transferência de dados entre os sites.
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Durante o processo de execução e otimização de comandos de
consultas locais, temos uma etapa que verifica se as tabelas e
colunas referenciadas existem no banco de dados.
Esta etapa é denominada
Custo da estratégia C 
A análise sintática.
B análise semântica.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 68/91
Parabéns! A alternativa B está correta.
A análise semântica, também denominada validação, verifica se o
comando referência objetos e itens de dados que existem no banco
de dados bem como faz a verificação de tipos.
Questão 2
Quanto ao processamento de consultas globais na fase de
mapeamento da consulta, podemos afirmar que:
A análise sintática e semântica é realizada de forma similar ao da
execução em um banco centralizado
Porque
Nesta fase, ocorre o acesso ao esquema conceitual global sem
levar em conta como a distribuição foi realizada.
Quanto às afirmativas, assinale a alternativa correta.
C reescrita de consulta.
D otimização da consulta.
E geração de código.
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
D A primeira afirmação é falsa e a segunda correta.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 69/91
Parabéns! A alternativa A está correta.
As duas afirmativas estão corretas, pois uma consulta global do
ponto de vista do banco global é como se fosse nele centralizada,
somente na etapa seguinte localização dos dados é avaliada a
distribuição dos dados.
4 - SQL em consultas distribuídas
Ao �nal deste módulo, você será capaz de aplicar comandos utilizando SQL em consultas
distribuídas.
Acessando bancos de dados remotos
Neste vídeo, apresentaremos as formas de acesso a um banco de
dados remoto e falaremos também sobre a ligação de banco de dados.
Formas de acesso a banco de dados remotos
E As duas afirmações são falsas.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 70/91
Em SBDD, que implementam a transparência de distribuição, um usuário
realiza a sua consulta como se estivesse utilizando um banco de dados
centralizado, considerando apenas o esquema conceitual global do
banco, o que não acontece quando a transparência de distribuição não é
implementada no sistema. Neste último caso, que inclusive é bem
comum, o usuário necessita especificar, em sua consulta, qual o
fragmento ou cópia da tabela que deseja acessar.
Para permitir o acesso ao fragmento ou à cópia remota, é necessário
que o SGBD no site de origem consiga referenciar o servidor remoto.
Para isso, existe uma ferramenta nos SGBD denominada ligação de
banco de dados.
Ligação de banco de dados
A ligação de banco de dados permite que, a partir do canal de
comunicação da rede de computadores que interliga o servidor local e o
servidor remoto, seja criada uma ligação lógica entre os bancos
residentes. Veja o esquema da imagem a seguir:
Ligação entre servidores e entre banco de dados.
Cada fabricante de SGBD implementa de uma forma diferente este tipo
de ligação como, por exemplo:
Oracle
Permite a criação de database link, objeto de banco de dados,
que identifica e estabelece as informações de conexão para
um banco de dados remoto.
SQL Server
Utiliza os servidores vinculados (linked server) que permitem
enviar uma instrução SQL em uma instância do SQL Server, que
retorna dados de outras instâncias do SQL Server.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 71/91
PostgreSQL
Utiliza a extensão dblink que fornece uma série de funçõesque
permitem acessar e manipular dados em outro servidor.
Para exemplificar o uso, vamos nos concentrar no dblink do PostgreSQL.
Descrição do ambiente dos
servidores
Neste vídeo, apresentaremos formas de configurar um servidor local e
um remoto.
Os servidores
No ambiente que vamos utilizar para os exemplos, possuímos dois
servidores PostgreSQL denominados SERVIDOR1 e SERVIDOR2.
O Servidor1 está localizado em uma máquina local e rodando também o
PGAdmin, possuindo o banco de dados do escritório central de um
representante comercial.
O Servidor2 está em uma máquina virtual que é acessada pela rede
local, e cujo IP é 192.168.5.189, porta 5432, e que está sendo
administrado pelo PGAdmin localizado na máquina do Servidor1 e
possui o banco de dados da sucursal do representante comercial
(imagem a seguir).
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 72/91
PGAdmin do ambiente de exemplo.
Nos bancos central e sucursal possuímos a tabela FARMACIA, que foi
fragmentada horizontalmente, e cada fragmento possui os dados das
farmácias atendidas por aquele escritório.
O comando de criação da tabela farmácia é:
SQL 
CREATE TABLE FARMACIA (
CNPJ CHAR(14) PRIMARY KEY,
RAZAO_SOCIAL VARCHAR(50),
TELEFONE VARCHAR(13))
1
2
3
4
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 73/91
Para criar as tabelas basta submeter os comandos aos dois servidores,
veja na imagem a seguir:
Submissão de comandos aos dois servidores.
Agora vamos colocar dados nas tabelas, para isso emita no banco
CENTRAL os seguintes comandos:
SQL 
Confira o resultado na imagem a seguir:
Comandos para inserir dados na tabela através do banco central.
Para colocar dados na sucursal, os comandos são:
SQL 
INSERT INTO FARMACIA (CNPJ, RAZAOSOCIAL, TELEFONE) V
INSERT INTO FARMACIA VALUES (‘23456789000136’, ‘FARM
COMMIT;
1
2
3
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 74/91
Confira o resultado na imagem a seguir:
Comandos para inserir dados na sucursal.
DBLINK POSTGRESQL
Neste vídeo, explicaremos o que é Dblink e como habilitá-lo em um
banco de dados.
O que é o dblink?
O dblink é uma extensão do servidor PostgreSQL que suporta conexões
com outros bancos de dados, no mesmo ou em outro servidor, a partir
da conexão em uso pelo usuário.
A extensão possui um conjunto de funções, cada uma com a sua
própria finalidade, veja a lista com cada uma delas a seguir de acordo
com a documentação de PostgreSQL:
dblink_connect: Abre uma conexão persiste com um banco de
dados remoto.
INSERT INTO FARMACIA (CNPJ, RAZAOSOCIAL, TELEFONE) VINSERT INTO FARMACIA VALUES (‘45678923000136’, ‘FARM
COMMIT;
12
3
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 75/91
dblink_connect_u: Abre uma conexão persistente com um banco de
dados remoto, de forma insegura.
dblink_disconnect: Fecha uma conexão persistente com um banco
de dados remoto.
dblink: Executa uma consulta em um banco de dados remoto.
dblink_exec: Executa um comando em um banco de dados remoto.
dblink_open: Abre um cursor em um banco de dados remoto.
dblink_fetch: Retorna linhas de um cursor aberto em um banco de
dados remoto.
dblink_close: Fecha um cursor em um banco de dados remoto.
dblink_get_connections: Retorna os nomes de todas as conexões
dblink nomeadas abertas.
dblink_error_message: Obtém a última mensagem de erro na
conexão nomeada.
dblink_send_query: Envia uma consulta assíncrona para um banco
de dados remoto.
dblink_is_busy: Verifica se a conexão está ocupada com uma
consulta assíncrona.
dblink_get_notify: Recupera notificações assíncrónas em uma
conexão.
dblink_get_result: Obtém um resultado de consulta assíncrona.
dblink_cancel_query: Cancela qualquer consulta ativa na conexão
nomeada.
dblink_get_pkey: Retorna as posições e nomes de campo dos
campos de chave primária de uma relação.
dblink_build_sql_insert: Constrói uma instrução INSERT usando
uma tupla local, substituindo os valores do campo de chave
primária por valores alternativos fornecidos.
dblink_build_sql_delete: Constrói uma instrução DELETE usando
valores fornecidos para valores de campo de chave primária.
dblink_build_sql_update: Contrói uma instrução UPDATE usando
uma tupla local, substituindo os valores do campo de chave
primária por valores alternativos fornecidos.
Habilitando o dblink em um banco de dados
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 76/91
Para que se possa utilizar o dblink, é necessário que a extensão seja
criada, pois a extensão não existe em um banco de dados por padrão,
conforme pode ser observado no banco CENTRAL na aba extensões no
PGAdmin.
Captura de tela do programa PGAdmin para criação da extensão no uso do dblink.
Existem duas formas para criar a extensão, a primeira consiste na
ferramenta de consulta SQL conectada ao banco CENTRAL, escrever o
comando CREATE EXTENSION DBLINK e mandar executar, veja na
imagem a seguir:
Comando para criação da extenção no programa PGAdmin
A segunda forma é utilizando a interface gráfica do PGAdmin, e clicar
com o botão direito em EXTENSION no banco CENTRAL e selecionar
CREATE EXTENSION, veja o processo nas imagens a seguir:
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 77/91
Segunda forma para criação da extensão no programa PGAdmim.
Etapa para salvar a extensão no programa PGAdmin.
O efeito das duas é criar a extensão no banco, vejamos.
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 78/91
Captura de tala do programa PGAdmim após criação das extensão.
Funções Dblink
Neste vídeo, apresentaremos as principais funções do DBLink, entre
elas, DBLINK_CONNECT, DBLINK_EXEC e DBLINK_DISCONNECT.
DBLINK
A função DBLINK é a função mais básica da extensão e executa uma
consulta (geralmente um SELECT, mas pode ser qualquer instrução SQL
que retorne linhas) em um banco de dados remoto. Ela possui a
seguinte sintaxe básica:
Dblink (string de conexão ou nome da conexão, comando select) retorna
registro.
Onde:
Nome da conexão 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 79/91
Nome da conexão criada com dblink_connect.
Informações sobre como realizar a conexão com os seguintes
itens:
host= endereço IP do servidor.
port= porta de rede do servidor normalmente 5432.
dbname= nome do banco que deseja acessar.
user= usuário de conexão.
password= senha do usuário de conexão.
A consulta SQL que você deseja executar no banco de dados
remoto.
Quando dois argumentos são fornecidos, o primeiro é procurado
primeiro, ou seja, o nome de uma conexão persistente criada com
dblink_connect; se encontrado, o comando é executado nessa conexão.
Se não for encontrado, o primeiro argumento é tratado como uma string
de conexão e a conexão indicada é feita apenas durante este comando.
Vejamos um exemplo de uso. Considere que, estando conectado no
banco central do Servidor1, se deseje retornar à razão social das
farmácias atendidas pela sucursal. Os dados de conexão são:
host=192.168.5.189
port=5432
user=postgres
password=senha
dbname=SUCURSAL
O comando SQL para produzir o que se deseja é:
SQL 
String de conexão 
Comando Select 
21/11/2023, 07:42 Implementação de Banco de Dados Distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07592/index.html# 80/91
Observe que antes do nome da tabela FARMACIA, consta o esquema
PUBLIC onde ela reside, sem isso o comando pode