Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo da SQL Magazine 33 - Replicando dados com Microsoft SQL Server 2000
Artigo da SQL Magazine - edição 33.
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?

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
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 "
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Claudete Moscardini
é graduada em Ciência da Computação pela PUC-Minas Belo Horizonte e Mestre em Inteligência Computacional e Sistemas Distribuídos. Trabalhou por 7 anos em empresas; atua agora na pesquisa e leciona as matérias de Análise e Projeto de Sistemas e Banco de Dados na Pontifícia Universidade Católic...
1 COMENTÁRIO
"Outro fator importante é que a replicação snapshot não propaga alterações ocorridas na estrutura da tabela (por exemplo, a inclusão de uma nova coluna)."
Como o snapshot nada mais é que uma foto ele pega pegas as informações das tabelas assim como a estrutura e suas informações.




