1 - Universo KK

Banco de Dados Distribuído –
INFORMIX
Joao Paulo Bonard & Mauricio Mesquita
1- Projeto de BD-Distribuido
a. Suporte a fragmentação
Horizontal: Implementa
métodos:
Round Robin: cada tupla vai para a próxima partição, em sequencia.
Hashed: aplica-se um algoritmo na chave da tupla para determinar o número da
partição.
Range: tuplas divididas segundo um intervalo entre chaves.
Expression: cada partição recebe uma quantidade de registro determinada apartir
de um critério de seleção (cláusula select).
b. Mecanismos de Replicação * Master/Slave - replicação de transação *
Replicação de dados é a sua duplicação de um servidor de banco de dados primario (servidor
primario) para um servidor de banco de dados secundário (servidor secundário). Neste contexto,
um servidor sem replicação é um servidor padrão.
Durante um funcionamento normal, clientes podem se conectar ao servidor primario e utilizálo
como um servidor padrão. Clientes podem também se conectar ao servidor secundário, mas
apenas para ler dados.
O servidor secundário não permite atualizações através de aplicações do cliente. Ele é
dinamicamente atualizado, as alterações no servidor primário são enviadas para serem aplicadas
no servidor secundário.
O Informix utiliza o log lógico para replicar os dados de um Servidor primário para um secundário.
Antes do servidor primario descarregar o buffer de log lógico da memória compartilhada para o
disco, o sistema copia o seu conteúdo para um buffer de replicação de dados no servidor primario.
O buffer de replicação de dados é parte da area virtual da memória compartilhada, administrada
pelo servidor primario, e tem o mesmo tamanho que o log lógico.
O buffer de replicação de dados é enviado para o servidor secundário através da rede, utilizando
TCP/IP, e é recebido por uma thread específica que o coloca num buffer de recovery. Depois uma
outra thread aplica os comandos do log no banco de dados do servidor secundário.
Os dois servidores possuem uma thread que fica fazendo um ping entre as duas máquinas, de
forma que ela fica checando a conexão entre eles. Se ela detectar uma falha na comunicação, uma
mensagem de erro é enviada para o log de mensagem. Normalmente esta situação exige que se
inicie um processo de recovery no servidor primario ou no secundário.
O servidor primario pode enviar para o servidor secundário o conteúdo do buffer de replicação de
dados de forma síncrona ou assíncrona.
Para que ocorra a replicação síncrona deve ser configurado um parâmetro (DRINTERVAL = -1)
qualquer outro valor neste parâmetro tornará a replicação assíncrona.
Na replicação síncrona a descarga do buffer de log lógico só é finalizada após estes 3 passos:
• o conteúdo do buffer de log lógico foi copiado para o buffer de replicação de dados.
• o buffer de replicação de dados foi enviado através da rede para o servidor secundário.
• A confirmação do servidor secundário de recebimento do buffer chega ao servidor
primário.
Assim há a certeza de que as transações commitadas no servidor primário terão sido enviadas
para o servidor secundário.
O principal problema dessa abordagem é que a cada descarga do buffer de log lógico, pode haver
um atraso na espera da mensagem de confirmação devido ao tráfego na rede.
No update assíncrono esta espera é evitada, pois a descarga do buffer de log lógico é finalizada
imediatamente após a cópia de seu conteúdo para o buffer de replicação de dados.
O servidor primário envia o conteúdo do buffer de replicação de dados pela rede quando:
• buffer de replicação de dados ficar cheio
• a aplicação commitar uma transação em um banco de dados não bufferizado
• um intervalo de tempo especifico passar, determinado pelo parametro DRINTERVAL.
A desvantagem do update assíncrono está no risco de, se houver uma falha, transações
commitadas no servidor primario podem não ter sido replicadas no secundário.
Checkpoints entre os servidores primario e secundário são sempre executados sincronamente.
Durante um checkpoint são escritos em disco as alterações feitas nos buffers de memória
compartilhada, buffers de log físico e buffers de log lógico. Isto provê informação para o processo
de fast recovery caso ocorra uma falha no sistema.
Um checkpoint no servidor primario só é finalizado após o término do secundario, e deve ocorrer
em intervalos de tempo definidos na configuraçao do parametro DRTIMEOUT .
Replicação de dados pode ser alterada pelo logging setup do seu BD.
Se o BD tem um logging bufferizado e o sistema cair enquanto o buffer de log lógico conter uma
transação commitada que ainda não foi descarregada, ela será perdida.
Se o BD tem um logging não bufferizado, the buffer de log logico é descarregado assim que a
transação for commitada.
Existem alguns requisitos para a utilização de replicação de dados:
O hardware e o SO devem ser idênticos nos servidores primario e secundario e ambos
devem utilizar a mesma versão e release de Informix, além de possuírem a mesma
configuração de log físico, log logico e memória compartilhada.
As conexões de hardware e software de ambos devem se comunicar utilizando TCP/IP,
utilizando a mesma interface de programação (TLI ou Socket).
Os chunks, dbspaces, path names, e offsets alocados para dbspaces não temporários, dos
servidores primario e secundário, devem ser os mesmos.
Idealmente até mesmo o particionamento dos discos de ambos os servidores devem ser
idênticos.
Todo o banco de dados que se deseja replicar deve utilizar o log de transação. Se isso nao
ocorrer, as atualizações no servidor primario nao gerarao log e as transaçoes nao poderao
ser refletidas no servidor secundário.
Outras configurações no servidor primário devem ser levadas em cnsideração no momento
da configuração do servidor secundário.
2- Controle do ambiente distribuído
Controle de acesso é implementado através de privilegios que permitem que o
usario realize operações em um objeto do Banco de Dado.
Implementa controle de acesso com varios niveis de seguranca ao inves de
abordagem do tudo-ou-nada
O Informix permite o controle de integridade através de trigger.
3- Transparência


Distribuicao: O informix não suporta Transparência de distribuicao, visto o
exemplo abaixo, ele tem transparência de denominação (usa sinônimos)
replicação: Tem para atualização e não tem para consulta
Durante um funcionamento normal, clientes podem se conectar ao servidor primario e
utilizálo como um servidor padrão. Clientes podem também se conectar ao servidor
secundário, mas apenas para ler dados.
O servidor secundário não permite atualizações através de aplicações do cliente. Ele é
dinamicamente atualizado, as alterações no servidor primário são enviadas para serem
aplicadas no servidor secundário.

Fragmentação: Tem. É feito automaticamente a conversão das consultas para os
fragmentos.
4- Processamento distribuído de consulta
a. Suporte ao processamento distribuído de consulta
Em cada servidor, existe um request manager (RQM), que toma decisões quanto a como a
consulta deve ser dividida e distribuída, além de assegurar a não sobrecarga de servidores na
rede. O RQM utiliza outros 3 serviços para determinar como uma consulta será executada: o query
optimizer, que determina a melhor forma para a execução da request, o metadata manager que diz
aonde o dado se encontra e o scheduler para distribuir a consulta .
b. Tipo de otimizador de consulta utilizado
Utiliza o Query Optimizer, que realiza pesquisa exaustiva baseada em custo.
Ele gera multiplos planos de consulta e escolhe o menor custo, considerando a ordem
em que as tabelas sao lidas, como elas sao lidas (index ou sequencial) e como ocorre
o join entre as tabelas na consulta. Utiliza qauntidade de I/O e capacidade de CPU
para calculo do custo.
c. Mecanismos de otimização de consulta distribuída
Utilizando informação pertinente vinda do metadata manager, o query optimizer
determina o grau de paralelismo da consulta e manda um plano de execução para o
scheduler distribuir a consulta.
O scheduler reside em cada servidor e serve para distribuir tarefas do sistema, ele
deve ativar o plano de execução no servidor em que houver o recurso disponível.
5- Processamento distribuído de transação
a. Suporte ao processamento distribuído de transação
Servidor Dinâmico INFORMIX-on-line (On-line) lhe permite atualizar
informação sobre múltiplo servidores de banco de dados que usam uma única
transação.
Este tipo de transação é conhecido como uma transação distribuída.
A estratégia para controlar transações distribuídas são conhecidos como um
two-phase commit protocol.
Este protocolo governa a ordem na qual uma transação de multiserver é
executada.
Transações distribuídas usam two-phase commit protocol para assegurar que
todos servidores recebem a mesma instrução - commit ou roll back uma
transação.
se qualquer servidor de banco de dados não pode comitar sua parte da
transação,
todos os servidores que participam na transação são impedidos de comitar.
Toda transação que usa o protocolo de two-phase commit tem coordenador e
um ou mais participantes.
O servidor no qual a transação é inciada, faz o papel de coordenador, e esta
transação é chamada de transação global.
O papel de coordenador não pode mudar durante uma única transação.
O comnado connect define o coordenador.(no caso a itália)
Você pode exibir o coordenador para uma transação distribuída usando o
comando ($onstat -x.)
O coordenador é responsável pela comunicação (envio e recebimento de
mensagens) com os participantes da transacao..
Mensagens passam entre o coordenador e cada participante. Mensagens do
coordenador para participantes incluem o numero de identificação da transação , e
instruções como prepare para commit ou rollback.
Se um Servidor estiver fora, pode ter parte de algumas transações que
estão ativas em outros Servidores. Os problemas que podem acontecer como
resultado dependem da fase da transação, e se o sistema falhado é o
coordenador ou um participante.
Fast Recovery precisa trabalhar diferentemente em um sistema distribuído.
Recovery restabelece o banco de dados automaticamente a um estado de
consistencia físico e lógico, depois de uma falha de sistema que poderia
deixar uma ou mais transações num estado uncommitted.
Dentro de uma transação distribuída, um Servidor pode ver uma transação
como commit, enquanto outro pode vê-la como ainda ativo.
Então os Servidores precisam se coordenar para determinar o verdadeiro
estado da transação.
Estas transações normalmente permanecerão ativas até que elas sejam
finalizadas(commit/roll back) em todos os locais.
Examinemos como two-phase commit trabalha.
Quando você executa um INSERT, UPDATE, ou DELETE, o apropriado
Servidor é contatado e se torna parte da transação.
Quando o segundo Servidor é contatado, a transação se torna uma transação
distribuída e o coordenador inicia um 2PC.
A two-phase commit protocolo tem duas partes:
• a fase pre-commit
• a fase de post-decision
O pre-commit é iniciado quando a aplicação de usuário enviar uma mensagem
commit para o coordenador.
O coordenador prepara então para commit localmente e escreve uma entrada
de BEGPREP dentro seu log.
Esta entrada lista os Servidores participantes que estão envolvidos na
transacao distribuída.
O coordenador pergunta então para os participantes se eles puderem comitar a
transação.
O participante pode não comitar se um erro de constraint acontece, ou se
qualquer servidor cair.
Se qualquer um dos participante não puder comitar, entao o coordenador
realiza roll back da transação e envia mensagens de rollback a todos os
participantes. A transação é terminada então.
Se o participante puder comitar a transação, escreve no log um PREPARE, o
participante - agora na fase pre-commit - indica que está pronto para comitar
mandando de volta uma mensagem ao coordenador.
Se todos os participantes devolvem uma resposta positiva ao coordenador, ele
escreve no log um commit, que indica o começo da fase de post-decision. O
coordenador envia mensagens commit para os participantes.
Cada participante escreve então um COMMIT no log, comitando efetivamente
a transação localmente.São libertados todos os recursos no local participante.
Porém, a transação global permanece aberta até que o coordenador a finalize.
Uma vez que todos os participantes confirmarem o commit de suas transações
locais, o coordenador, fica livre para completar a transação global distribuída e
gravar em seu log um ENDTRANS. Esta entrada no log completa a transação
e os recursos do coordenador são libertados.
b. Protocolo de recuperação (Recovery)
O 2PC é usado para controlar transações distribuídas
por servidores múltiplos.
O 2PC executa um recovery automático no caso de uma transação
ou sistema falhar
O processo de recuperação automático é projetado para controlar falha de tal
um modo que é preservada integridade de dados por todos servidores
participantes.
O único papel do DBA neste processo é trazer o coordenador ou
participante on-line depois de uma falha de sistema ou de rede.
Há dois parâmetros de configuração específico para recuperação de ambiente
distribuído:
• TXTIMEOUT
• DEADLOCK_TIMEOUT
Embora ambos os parâmetros especificam períodos de time-out, os dois são
independentes.
O parâmetro de TXTIMEOUT é específico para quando comunicação entre o
coordenador e o participante estiver interrompido. Isto especifica a quantia de
tempo que o participante espera para receber uma instrução de commit do
coordenador.
Se o tempo especificado (time-out) decorre, o participante checa o estado da
transação no sistema coordenador para determinar se deverá iniciar o recovery
automático participante.
O valor default do TXTIMEOUT é 300 segundos.
O ótimo valor deste parâmetro varia, dependendo de seu ambiente específico
e aplicação.
O parâmetro de DEADLOCK_TIMEOUT especifica a quantia de tempo que
uma transação distribuída espere adquirir um recurso de memória
compartilhado.
Se a transação é forçada a esperar mais muito tempo que o tempo
especificado, a thread que possui a transação assume que existe deadlock
multiserver.
Deadlock pode acontecer quando um de dois servidores precisam de um
recurso, e não pode continuar processo até a liberaçao do recurso exigido.
O valor default DEADLOCK_TIMEOUT é 60 segundos.
Você deve ter cuidado ao ajustar o valor de DEADLOCK_TIMEOUT. Se você
fixasse o valor muito baixo, servidores podem abortar transações que não são
deadlocked. Se você fixasse o valor muito alto, deadlock multiserver poderiam
reduzir a concorrencia , afetando o desempenho.
Pode acontecer durante uma transação em 2PC: O servidor ou a rede cair.
O processo de recovery exato que acontece para uma transação distribuída
depende
de:
• que fase que está a transação
• se é coordenador ou participante que falhou
1. Olhemos primeiro como o processo de recuperação automático trabalha
no caso de o participante falhe durante a fase pre-commit.
Na fase pré-commit , o coordenador envia uma mensagem para o participante
perguntando se pode dar commit.
Obviamente, se a conexão entre coordenador e participante cair, nenhuma
resposta será recebida pelo coordenador. O coordenador entao dá roll back na
transacao.
Enquanto isso, o participante esperará TXTIMEOUT segundos esperando uma
mensagem de commit do coordenador, como não vai receber , então tenta
adquirir do coordenador o estado de transação. Então não haverá nenhum
registro em memória compartilhada, então o participante vai dar roll back.
2. O participante também poderia falhar na fase de post-decision.
Nesta fase o participante enviou uma mensagem ready-to-commit. Fica no
estado de READY
O coordenador descobre que o participante falhou quando não receber
nenhuma resposta de confirmação do pedido de commit.
Gera um nova mensagem de commit para o participanteo para comitar a
transação.
A menos que o participante tenha caido, também descobrirá que sua própria
thread caiu, e starta outro participante.
O novo participante recentemente criado gerará uma thread (thread) somente
no coordenador com a finalidade de conferir o estado da transação.
O participante vê que a transação está na fase de post-decision, e espera
o coordenador completar a transação.
Finalmente, depois que a transação completa, ambas as threads(threads)
geradas pelo participante é terminada.

Agora olhemos a como processo de recovery automático trata se o
coordenador falhar durante 2PC.
1. Se thread(thread) de coordenador morre durante o pre-commit, a
transação inteira, precisa dar roll back.
Primeiro, o DBA tem que colocar o coordenador on-line novamente.
Depois, o mecanismo fast recovery mechanism dá roll back na transação
global no coordenador.
Enquanto isso, participantes esperam o período de tempo especificado pelo
parâmetro de configuração TXTIMEOUT para receber uma mensagem do
coordenador para ou comitar ou roll back.
Depois de esperar o tempo especificado, os participantes gera uma thread
nova no coordenador para determinar o estado de transação.
O participante não poderá gerar esta thread nova até o coordenador
está de volta on-line. Porque o coordenador deu roll back na transação global,
não há nenhuma transação em memória compartilhada. Então os participantes
dão roll back na transação.
1. O coordenador poderia morrer durante a fase de post-decision
onde o COMMIT foi escrito no log mas o ENDTRANS não . Neste caso,
deve ser commitada, não deve dar roll back. Fazer isto, a thread de
main_loop gerará uma thread nova no lado do coordenador.
A nova thread coordenando envia uma mensagem a cada thread participante
para determinar os estados das partes de trabalho.
Se participantes retorna mensagem de que pode commit, o coordenador instrói
o participante para comitar.
Porém, se o participante já comitou seu trabalho, terá removido
a entrada de sua tabela de transações abertas. Por conseguinte,não tem
nenhum conhecimento da transação. O participante devolve então uma
mensagem de ‘transaction unknown' (transação desconhecida)para o
coordenador, que presume que o trabalho já estava comitado.
Uma vez o coordenador contata todos os participantes, pode completar o
protocolo fazendo uma entrada de ENDTRANS no log.
 Falha do participante ou coordenador apresenta uma mais séria
situação de recovery.

No caso de falha do participante, o processo de recuperação automático
habitual pode acontecer.Porém, isto sempre não é possível.
Se o coordenador está na fase de post-decision e não recebeu uma mensage
de commit
do participante, continuará recebendo votos do participante para uma resposta.
A freqüência de receber votos é determinada pelo parâmetro de TXTIMEOUT.
Ocasionalmente um período longo de tempo pode decorrer antes do
participante ficar on-line.
Para o coordenador será impedido de comitar a transação se não saber se o
participante comitou ou não.
Uma transação neste estado é conhecida como uma transação bloqueada.
Uma transação bloqueada pode resultar em qualquer do seguinte:
• que o processo front-end parece estar com problema.
• que a aplicação não procederá além da declaração de COMMITWORK até a
transação ser completada
• o arquivo de mensagem On-line receberá uma mensagem que declara que o
participante em questão não está respondendo, e o nome participante será
listado.
Uma transação bloqueada segurará todos os recursos para aquela transação
até que seja completada.

Uma situação semelhante acontece no caso de falha do coordenador.
Se um período longo de tempo decorre antes do recovery do coordenador, o
processo participante é bloqueado para comitar a transação, porque não sabe
se o coordenador entrou na fase de post-decision ou não.
Em uma transação bloqueada devido a fracasso de coordenador, o campo de
retrys para a transação no onstat -x continuará aumentando.
Este valor especifica o número de vezes que o participante tentou adquirir
informação de estados da transação pelo coordenador.
Além disso, o log conterá mensagens que indicam que não pode
conectar a um sistema remoto.
Uma vez mais, por causa da transação bloqueada, todos os recursos são
segurados até o transação ser completada.

Olhemos agora a como Informix recupera de uma falha de um sistema
heterogêneo.
Tal participação (de Servidores não Informix) é tornada possível pelo uso de
portais que agem como uma ponte entre Informix e servidores de non-Informix.
Em qualquer fase durante um commit heterogêneo, o coordenador,
participantes, ou portal pode falhar.
Falha em commit heterogêneo é da mesma maneira como 2PC, menos em
certas circunstâncias especiais.
Nestes casos especiais, o portal commita a transação enquanto que os outros
Servidores possam decidir abortar.
Demos uma olhada nestes casos especiais.
Suponha o coordenador falha uma vez enviou a mensagem commit para o
portal mas antes de escrever o COMMIT no log.
Neste caso, as tarnsacoes serão abortados nos Servidores,mas qualquer
dados comitado pelo portal não dará roll back.
Outro caso especial surge se o portal receber uma mensagem commit e
comitar a transação, mas falha antes de enviar uma mensagem de
confirmação disto ao coordenador. Novamente, dados são comitados no portal
, mas os outros Servidores dão roll back.
c. controle de concorrência
Há dois parâmetros de configuração específico para recuperação de ambiente
distribuído:
• TXTIMEOUT
• DEADLOCK_TIMEOUT
O parâmetro de DEADLOCK_TIMEOUT especifica a quantia de tempo que
uma transação distribuída espere adquirir um recurso de memória
compartilhado.
Se a transação é forçada a esperar mais muito tempo que o tempo
especificado, a thread que possui a transação assume que existe deadlock
multiserver.
Deadlock pode acontecer quando um de dois servidores precisam de um
recurso, e não pode continuar processo até a liberaçao do recurso exigido.
O valor default DEADLOCK_TIMEOUT é 60 segundos.
Você deve ter cuidado ao ajustar o valor de DEADLOCK_TIMEOUT. Se você
fixasse o valor muito baixo, servidores podem abortar transações que não são
deadlocked. Se você fixasse o valor muito alto, deadlock multiserver poderiam
reduzir a concorrencia , afetando o desempenho.
6- Suporte a acesso a dados de SGBD Heterogêneo
O Informix oferece conectivide a outros SGBDs através do Informix Enterprise
Gateway, permitindo acesso a Oracle, Sybase, IMS e DB2. O Informix Enterprise Gateway
traduz chamadas SQL do Informix em chamadas de função compatíveis com ODBC. Ele
funciona como um emulador, fazendo transparência para que aplicações cliente e servidor
vejam o SGBD externo como uma instância de um Informix Dynamic ServerTM . Auxilia o
acesso ao dado utilizando um OnLine 5.x ou uma ferramenta baseada em DSA para
coordenar um join distribuido utilizando um único comando SQL.
Um ambiente heterogêneo recorre a um grupo de servidores de banco de dados onde
pelo menos um dos Servidores não é um servidor Informix. Um commit heterogêneo
permite transações distribuídas para atravessar servidores não Informix.
É provido acesso para os servidores não Informix por um sistema de Gateway (Portal).
Há três tipos de gateway:
• DRDA Gateway
• Enterprise Gateway
• Enterprise Gateway Managerwith ODBC
O Coordenador assegura que só um Gateway é usado em qualquer transação
distribuída. Para utilizar commit heterogeneo, habilita-se o parametro commit heterogeneo
para y utilizando o comando ON-Monitor ($ onmonitor) ou pode-se fixar o parâmetro de
configuração, HETERO_COMMIT para 1 no arquivo
Onconfig. Qualquer outro valor incapacitará commit heterogêneo. Em qualquer caso, a
mudança não entra em vigor até você reinicializar a memória compartilhada , reiniciando o
sistema. O Coordenador automaticamente usa o protocolo de commit heterogêneo para
qualquer transação distribuída entre um ou mais servidores e somente um gateway. O
protocolo de commit heterogeneo é uma evolução do Protocolo Two-phase commit padrão.
O protocolo de commit heterogeneo é dividido em 3 fases:
• pre-commit
•gateway commit
•post-decision
Na fase pre-commit , o coordenador direciona cada participante, exceto o participante
gateway, para preparar o commit da transação.
Se os participantes estiverem preparados para o commit, eles devem retornar mensagem
de confirmação.Se o coordenador receber todas as mensagens de confirmação , ele grava
no log e manda mensagem de commit para o gateway.
Esta açao incia a fase gateway commit.
O gateway envia uma resposta ao coordenador indicando se o gateway comitado faz parte
da transação.
Se o gateway comitar a transacao, o coordenador decide comitar toda transação.
Entretanto , se o gateway “cair” o coordenador realiza um roll back na transacao.
A fase post-decision é identical a fase correspondente no protocolo 2PC.