Artigos Banco de Dados Replicando dados com Microsoft SQL Server 2000

/loja/img/Capa_SQL33_G.jpg">

Capa SQl 33

Clique aqui para ler todos os artigos desta edição

 

Replicando dados com Microsoft SQL Server 2000

Claudete Moscardini

O objetivo da replicação é manter duas ou mais cópias dos dados em diferentes servidores: pode-se replicar um conjunto de tabelas, ou mesmo aplicar filtros nas linhas e colunas que se deseja replicar, mas pode-se também replicar um banco de dados em sua totalidade. A replicação tem sido uma grande aliada das empresas, provendo melhor desempenho e maior disponibilidade através da distribuição sistemática de dados.

Na edição 15 da SQL Magazine, o leitor pôde conferir alguns conceitos sobre replicação de dados. Conforme dito pelo autor Wagner Corrêa Ramos, replicação é um meio de se copiar de forma gerenciada os dados entre servidores, que podem estar próximos ou a centenas de quilômetros de distância.

Praticamente todos os SGBDs oferecem recursos de replicação de dados. Até os SGBDs open source têm pelo menos uma opção de replicação gratuita ou com custos bastante reduzidos.

Este artigo tem como objetivo apresentar o processo de configuração de replicação de dados utilizando o SQL Server 2000. A versão utilizada no artigo foi a Personal Edition (específica para desktops), mas os procedimentos são os mesmos para outras versões (Enterprise e Standard Editon).

Planejamento da replicação de dados

1. Análise dos requisitos do negócio

Antes de iniciar a configuração da replicação, o projetista deve definir para que e como será a replicação de dados, de modo que seu usuário tenha satisfação e confiabilidade no processo como um todo. Para manutenção das cópias será necessário levantar os requisitos para o funcionamento da replicação: latência, autonomia da réplica, conflitos de atualização, disponibilidade física (hardware e software), tipo de arquitetura e velocidade dos links da conexão:

·         Latência: é o tempo permitido para que haja um sincronismo entre as réplicas. À medida que a base de dados original sofre alterações, existe um certo tempo (latência) até que estas sejam propagadas para as cópias (réplicas).

·         Autonomia da réplica: existem empresas em que as filiais precisam continuar operando normalmente mesmo que as filiais estejam com problemas de comunicação com a matriz. Para que isso ocorra, a réplica deve possuir dados suficientes para operar de forma autônoma quando o acesso ao servidor central estiver indisponível.

·         Conflitos de atualização: quando existem diversas réplicas onde os dados podem ser alterados, o mesmo registro pode ser modificado em réplicas diferentes gerando uma situação de conflito onde  uma alteração se sobrepõe à outra. No SQL Server 2000 é possível acrescentar regras para direcionar a solução de conflitos pelo SGBD;ou ainda projetar algumas regras no modelo de dados, ficando a cargo da aplicação – e não do SGBD - solucionar o conflito. A titulo de exemplo de regra na aplicação, suponha uma tabela de clientes responsável pelo armazenamento de todos os clientes da empresa. Para que se evitem conflitos de cadastramento entre as diversas filiais, uma solução é colocar as iniciais da cidade responsável pelo cadastro na codificação do cliente. Clientes cadastrados na cidade de São Paulo receberiam códigos como SP001, SP002, dentre outros; já os clientes cadastrados em  Poços de Caldas receberiam os códigos PC001, PC002, e assim por diante. Já para uma regra definida pelo sistema de replicação, poderíamos estabelecer, por exemplo, que alterações executadas na cidade de São Paulo têm prioridade sobre aquelas realizadas nas lojas localizadas em Poços de Caldas.

·         Disponibilidade física: o projetista deve levantar quais serão os servidores e o meio de comunicação disponível.

·         O projetista deverá escolher o tipo de arquitetura da replicação: um servidor central com réplicas não atualizáveis, um servidor central com réplicas atualizáveis, réplicas atualizáveis com ou sem o servidor central:

o        Servidor central com réplicas não atualizáveis: as atualizações são efetuadas apenas no servidor central, sendo retransmitidas para as réplicas. É utilizado em sistemas onde a réplica utiliza somente consultas. Essa é a modalidade de replicação mais tranqüila para que se mantenha integridade dos dados.

o        Servidor central com réplicas atualizáveis: neste caso as réplicas também atualizam dados. As atualizações efetuadas nas réplicas devem retornar para o servidor central;

o        Réplicas atualizáveis com ou sem servidor central: todas as réplicas recebem e realizam atualizações, distribuindo-as para outras réplicas. Neste caso, cada réplica tem uma cópia perfeita de todos os dados. Este tipo de arquitetura é importante em sistemas bancários e em sistemas de vendas on-line, onde o estoque deve ser atualizado em tempo real.

 

·         Velocidade dos links da rede: a replicação implica em informações sendo enviadas na rede. Por essa razão, é importante estimar o volume de dados a serem replicados e verificar se o link disponível é suficiente para que se evite uma sobrecarga do sistema, impedindo – ou atrasando – o processo de sincronização.

 

2. Escolha do modelo de atualização: síncrona ou assíncrona

Existem dois tipos de sincronização: síncrona e assíncrona. Os softwares replicadores que realizam replicação assíncrona são responsáveis por replicações não atômicas entre servidores: eles normalmente possuem um log contendo as alterações; através de um processo assíncrono o log é lido e as atualizações são propagadas para as réplicas.

No replicador síncrono as transações são atômicas e as atualizações são realizadas em todas as réplicas em tempo real. Este segundo caso deve ser utilizado para aplicações que têm a necessidade de informações atualizadas em tempo real, com latência mínima. A desvantagem desta opção é a perda de desempenho: caso uma das réplicas esteja sem conexão, a replicação fica pendente até que todas as réplicas estejam prontas para sincronização. Na replicação assíncrona o desempenho é muito superior, uma vez que o dado é atualizado e, somente quando possível,  será efetuado a distribuição para as réplicas.

O SQL Server 2000 trabalha com replicação assíncrona, mas pode ser configurado para propagar as alterações no momento em que elas são registradas no database, diminuindo bastante a latência de sincronização entre publicador e réplicas.

Replicação no SQL Server

Elementos de replicação

A replicação de dados no SQL Server segue o modelo Publisher-Subscriber, onde um servidor publica os dados para os demais. Existem três elementos de replicação: Publisher, Distributor e Subscriber  (ver Figura 1):

·         Publisher é aquele que “publica” os dados que serão replicados para um ou mais Subscribers;

·         Subscriber recebe os dados publicados pelos Publishers através do Distributor;

·         Distributor é aquele que “entrega” os dados para os Subscribers. O papel do distribuidor é mais significativo nas replicações Snapshot e Transacional, pois nesses dois modelos, além de controlar  o processo de distribuição (o que deve ser distribuído para quem), o Distributor armazena temporariamente as transações (replicação Transacional) ou a estrutura e dados das tabelas (replicação Snapshot).

 

 

Figura 1. Visão do modelo arquitetural da replicação.

PUBLISHER

                           Banco de dados onde são efetuadas as alterações. Disponibiliza os dados para replicação.

 

 

 

 

 

                                                             image001.gif

 

DISTRIBUTOR

                                                 Controla e distribui as alterações para um ou mais Subscribers.

Dependendo do modelo de replicação, também armazena temporariamente os dados e/ou transações que serão replicadas.

 

 

 

 

 

 


                      PUSH              image003.gif                     image002.gif                   PULL

 

...
Quer ler esse conteúdo completo? Tenha acesso completo