Sistemas de Bancos de Dados Distribuídos

Sistemas de Bancos de
Dados Distribuídos
Fabio Seixas Marques
Oscar José C. Couto
1 – Projeto de BD-Distribuído
a) Suporte à Fragmentação
O DB2 da IBM suporta fragmentação horizontal limitada. A fim determinar onde uma
relação será fragmentada, o administrador seleciona "uma chave de partição" que seja
incorporada em uma função Hash junto com o número das divisórias desejadas. A
função Hash divide os dados em parcelas aproximadamente iguais que são
distribuídas. Desde que cada fileira de uma tabela tenha somente um valor da Hash, as
divisórias contêm tuplas disjuntas. A abordagem do DB2 permite que os dados sejam
distribuídos através dos nós múltiplos, e permitirá mesmo que a distribuição nãouniforme dos dados esclareça diferenças no poder de processamento dos vários nós.
As divisórias podem facilmente ser adicionadas ao sistema, e o administrador do banco
de dados esclarecerá estes nós novos e redistribuirá os dados. Esta arquitetura permite
que DB2 consiga a execução da query e a escalabilidade paralela do banco de dados
ao manter uma relação simples da gerência. Entretanto, o esquema não suporta a
fragmentação geral dos dados horizontais baseados em transações. O efeito do
mecanismo da fragmentação de DB2 deve apresentar aplicações com a aparência de
uma única base de dados composta de agregações de todos seus nós.
No DB2 só é possível criar uma fragmentação através de um Wizard.
b) Mecanismos de Replicação
Em conjunto com DataJoiner o DataPropagator forma uma solução flexível para
replicações heterogêneas.

DataPropagator
É o produto central da solução de replicação da IBM. A arquitetura DataPropagator
é baseada em três componentes principais: Administration Interface, Change Capture
Mechanisms e Apply program.
- Administration Interface
O DataJoiner Replication Administration tool (DJRA) é usado para definir a
configuração de replicação: Habilitar o Banco de Dados para replicação, tabelas
do registro como fonte, etc.
- Change Capture Mechanisms
No caso da replicação da fonte no DB2, o programa de captura captura as
mudanças dos dados lendo no LOG de transação
- Apply program
O programa lê os dados que foram alterados da tabela e os aplica na replicação.
Modos de replicação:
- Síncrono
- Assíncrono
Detecção avançada de conflito: Detecção de conflito que garante a integridade
de dados entre todas as réplicas e a tabela fonte. O programa Apply bloqueia
todas as réplicas ou tabelas de usuário no conjunto de subscrição contra
transações adicionais. Ele inicia a detecção após a captura de todas as
alterações efetuadas antes do bloqueio.
2
É aconselhado modelar a aplicação de forma que não ocorram conflitos. Para
isso é sugerido que se utilize o update anywhere nas seguintes condições:
– Fragmentação por chave
– Fragmentação por tempo
Há a opção de ignorar os conflitos e rejeitar qualquer alteração conflitante.
DataPropagator permite replicação bidirecional(“Update Anywhere”), mas
somente de DB2 para DB2, além de mestre/escravo de distribuição e consolidação.

DataJoiner
DataJoiner é uma estratégia da IBM para deixar o acesso transparente para Bancos
de Dados IBM ou não, relacionais ou não relacionais. Ele não é usado apenas na
replicação de dados heterogêneos, mas também para acessar os mesmos. Também
permite a execução de querys distribuídas localizadas em tabelas e bancos separados.
Mecanismos de Replicação suportados:
 Atualização assíncrona contínua: (por evento)
Processo no qual todas as alterações feitas na origem são registradas e aplicadas
em dados de destino existentes após a realização do commit na tabela base.
 Atualização assíncrona em lote: (por intervalo de tempo)
Processo no qual todas as alterações feitas na origem são registradas e aplicadas
em dados de destino existentes em intervalos especificados.
 Atualização completa: (Snapshot)
Na replicação do DB2 o processo no qual todos os dados de interesse em uma
tabela de usuário são copiados para a tabela de destino, substituindo os dados
existentes.
 Atualização diferencial: (Merge)
Na replicação do DB2, processo no qual apenas os dados alterados são copiados
para a tabela de destino, substituindo os dados existentes.
 Atualização em múltiplos sites:
No DB2 UDB para OS/390 processamento do banco de dados relacional distribuído
no qual os dados são atualizados em mais de uma localização dentro de uma única
unidade de trabalho.
2 – Controle do Ambiente Distribuído
a) Gerenciamento de View
Visões podem ser derivadas de uma ou mais tabelas, nicknames e outras views.
As visões podem referenciar informações de um ou mais data sources. Pode-se fazer
referência a vários nicknames e através de joins o DB2 Database consegue adquirir os
dados das varias tabelas, estando esses dados localmente ou não.
b) Controle de Segurança
3
Pode ser especificado o tipo de autenticação.
- SERVER O login e o password são validados no servidor do DDCS.
- CLIENT O login e o password são validados no cliente do DDCS.
- DCS O login e o password são validados no “host system”.
3 – Transparência
a) Transparência de Distribuição
A ferramenta DataJoiner contém a funcionalidade Distributed Database Connection
Services (DDCS), que permite aos clientes de sua LAN acessar transparentemente
dados armazenados em hosts como se estivesse utilizando um banco de dados
centralizado.
b) Transparência de Replicação
O DB2 implementa através da ferramenta DataJoiner.
c) Transparência de Fragmentação
O DB2 implementa através da ferramenta DataJoiner.
4 – Processamento Distribuído de Consulta
4
a) Suporte ao processamento distribuído de consulta
O DB2 Query Patroller, agora empacotado com o DB2 Warehouse Manager, pode
interromper o SQL que está indo para um DB2 Server por meio da integração do trap
no código do cliente. Isso permite que todas as SQL dinâmicas, independentemente do
sistema operacional, sejam gerenciadas, programadas e controladas pelo Query
Patroller. O mecanismo de repetição da consulta permite que trabalhos que foram
interrompidos por diversas razões sejam submetidos e executados novamente até a
conclusão. É possível emitir um comando de iniciação global que inicie o Query
Patroller em todos os nós. Essa ação oferece um único ponto de controle para a
iniciação e a interrupção do Query Patroller.
b) Tipo de otimizador de consulta utilizado
Você pode ver o plano de acesso de um SQL no DB2 e otimizar uma consulta,
através da ferramenta Visual Explain.
Você utiliza o as funções do Visual Explain para:

Visualizar as estatísticas utilizadas para otimizar as consultas. Você pode
comparar essas estatísticas com as correntes no catalogo de estatísticas para
determinar se o catalogo está desatualizado.

Determinar quando um índice é utilizado para acessar uma tabela. Se um índice
nunca é utilizado, a ferramenta pode ajuda-lo a determinar quais colunas devem
ser utilizadas na criação de um índice.

Visualizar as várias técnicas utilizadas para gerar um plano de acesso e
compara-las para saber em qual caso cada uma delas é melhor.

Obter informações sobre cada operação na determinação do plano de acesso,
incluindo o custo total estimado e o numero de linhas retornadas.

Utilizar a função de captura instantânea portável para exibir capturas
instantâneas a partir de qualquer servidor do DB2 remoto.
O otimizador de consulta do DB2 avalia tanto estatísticas locais (tempo de I/O)
quanto globais (tempo de conecção de um servidor em outro).
O que o otimizador de consulta verifica:





Instância: Agentes, conecção e ordenação.
Banco de Dados: Lock and Deadlock, Buffer Pool and I/O, conecção, ordenação
e SQL Statement Activity.
Tabela: Tabelas.
Table Space: Buffer Pool and I/O.
Conecções do Banco: Buffer Pool and I/O, Lock and Deadlock, Sort, SQL
Statement Activity.
5
5 – Processamento Distribuído de Transação
a) Suporte ao processo distribuído de transação
Seleção do Coordenador:
A seleção do coordenador deve ocorrer através de alguns critérios:
1. Segurança: Deve ser um banco seguro, pois irá conter dados relacionados a
integridade das transações.
2. Performance: Deve ser uma máquina robusta e de boa qualidade em termos de
hardware.
3. É recomendável que não armazene dados além daqueles necessários para
coordenar transações. Normalmente o coordenador não é um banco de dados como
os outros, que armazenam dados a serem acessados por outros bancos, e sim um
banco que será utilizado somente para controlar transações.
Prepare Phase:
1. A aplicação cliente envia uma chamada de preparação para todos os bancos
participantes e aguarda as respectivas respostas.
2. Os bancos participantes escrevem, em seus respectivos arquivos de log, dados
sobre a preparação de gravação e o nome do banco coordenador. Essa informação
será utilizada no caso de algum problema.
3. Cada banco informa ao cliente o seu status. Se o banco não conseguiu escrever no
arquivo, ele envia o status de read only. Do contrário, ele envia yes se estiver pronto
e no caso ainda não esteja pronto.
4. O cliente envia uma chamada de preparação ao coordenador.
5. O coordenador escreve, no seu arquivo de log, os dados sobre a preparação de
gravação.
6. O coordenador informa ao cliente o seu status.
Se todos os bancos responderem ao cliente yes, a segunda fase é iniciada.
Commit Phase:
7. O cliente envia uma requisição de commit para todos os bancos participantes, com
exceção daqueles que responderam read only.
8. Cada banco escreve, em seu respectivo arquivo de log, os dados sobre o commit e
efetua o commit.
9. Cada banco envia de volta para o cliente um acknowlegment indicando o sucesso
do commit.
10. O cliente envia uma requisição de commit ao coordenador.
11. O coordenador escreve, em seu arquivo de log, os dados sobre o commit.
12. O coordenador informa ao cliente o seu status.
Caso ocorra algum erro durante a segunda fase, o banco em que ocorreu o erro deverá
ser resincronizado.
b) Protocolo de recuperação
6
Se a comunicação foi perdida ou algum dos sistemas deu problema após a
prepare phase e antes ou durante a commit phase, será realizado o processo de
resincronização. Dependendo do tipo de problema que ocorreu o banco poderá ou não
ser restaurado e posto num estado consistente.
As transações que estão prontas (prepare phase), mas não conseguem efetuar o
commit ou rollback, são chamadas de indoubt transactions.
Se algum commit é feito, mas algum banco falha, então o coordenador tem que
reenviar o commit para o banco que falhou. O tempo default para reenvio de commit no
DB2 é 180 segundos.
Se um banco “cair” antes da prepare phase, é efetuado um rollback
automaticamente na transação. O coordenador irá dar rollback em todos os outros
bancos. Não ocorre a resincronização.
Se um banco “cair” após a prepare phase e antes da commit phase, a
responsabilidade de resincronização é do coordenador.
Se todos os bancos passaram da prepare phase, inclusive o coordenador, e o
coordenador falha ou a comunicação cai, o coordenador ou um banco poderá iniciar a
resincronização, dependendo de quem se conectar primeiro.
c) Controle de concorrência:
Lock Time Out Avoidance:
É utilizado em situações anormais em que uma certa aplicação espera para
efetuar um lock que nunca irá terminar. Evita deadlocks.
Especifica quantos segundos uma aplicação irá esperar para obter um lock.
Quando esse valor é atingido a aplicação aborta. Se o valor especificado for –1, então a
aplicação irá esperar eternamente para efetuar um lock.
O monitor do sistema do banco de dados agora permite que você monitore o
sistema DB2 Universal Database Enterprise - Extended Edition a partir de uma única
partição. Ele coleta os dados e agrega os valores através de todas as partições e
retorna um único resultado. Isso fornece aos administradores do banco de dados um
único ponto de controle para o monitoramento de seu data warehouse inteiro. O monitor
do sistema de banco de dados reúne as informações sobre a operação e o
desempenho das atividades do banco de dados que vão das leituras e gravações até
os bloqueios e deadlocks.
6- Suporte a acesso a dados de SGBD Heterogêneo
Os usuários do DB2 Universal Database agora têm o domínio da consulta
distribuída através de qualquer banco de dados da família DB2 ou fonte do OLE DB.
Isso significa que os usuários e as aplicações podem usar a sintaxe do DB2 Universal
Database SQL e as APIs para acessar dados que residem em fontes de dados
heterogêneas. Com essa funcionalidade, os usuários e as aplicações têm a capacidade
de fazer referência a várias fontes de dados em uma única instrução SQL. Com o
Relational Connect, as consultas distribuídas também podem incluir bancos de dados
Oracle (consulte “DB2 Relational Connect” na página 4). Essa é a primeira fase da
7
integração do DB2 DataJoiner no DB2 Universal Database. O DataJoiner é o produto
de middleware da IBM para a integração de fontes de dados heterogêneas.
O DB2 utiliza Gateway e APIs para se comunicar com outros tipos de banco de
dados.
O DB2 utiliza Wrapper para efetuar a conversação com bibliotecas de outros
bancos.
Comando para criar um Wrapper:
CREATE WRAPPER <wrapper_name> LIBRARY '<library_name>'
8