/loja/img/Capa_SQL33_G.jpg">
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 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.
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 PULL
Black November Desconto exclusivo para as primeiras 200 matrículas! Pagamento anual 12x no cartão De: R$ 69,00 Por: R$ 54,90 Total: R$ 658,80 Garanta o desconto Pagamento recorrente Cobrado mensalmente no cartão De: R$ 79,00 Por: R$ 54,90 /mês Total: R$ 658,80 Garanta o desconto Eu sabia pouquíssimas coisas de programação antes de começar a estudar com
vocês, fui me especializando em várias áreas e ferramentas que tinham na plataforma, e com essa
bagagem consegui um estágio logo no início do meu primeiro
período na faculdade. Estudo aqui na Dev desde o meio do ano passado!
Nesse período a Dev me ajudou a crescer muito aqui no trampo. Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a
pena, pois a plataforma é bem intuitiva e muuuuito
didática a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito
obrigado! Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento
front-end, tinha coisas que eu ainda não tinha visto. A
didática é do jeito que qualquer pessoa consegue aprender. Sério, to apaixonado,
adorando demais. Adquiri o curso de vocês e logo percebi que são os melhores do Brasil. É
um passo a passo incrível. Só não aprende quem não quer.
Foi o melhor investimento da minha vida! Foi um dos melhores investimentos que já fiz na vida e tenho aprendido
bastante com a plataforma. Vocês estão fazendo parte da minha jornada nesse mundo da
programação, irei assinar meu contrato como programador
graças a plataforma.
Wanderson Oliveira
Comprei a assinatura tem uma semana,
aprendi mais do que 4 meses estudando outros cursos. Exercícios práticos que não tem
como não aprender, estão de parabéns! Obrigado DevMedia, nunca presenciei uma plataforma de ensino tão presente na vida acadêmica de
seus alunos, parabéns!
Eduardo Dorneles
Aprendi React na plataforma da DevMedia há cerca de 1 ano e meio... Hoje estou há 1 ano empregado trabalhando 100% com
React!
Adauto Junior
Já fiz alguns cursos na área e nenhum é tão bom quanto o de vocês. Estou aprendendo
muito, muito obrigado por existirem. Estão de parabéns... Espero um dia conseguir um emprego na
área. Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.
... Confira outros conteúdos:
<Perguntas frequentes>
Nossos casos de sucesso
Fui o primeiro desenvolvedor contratado pela minha
empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta é continuar estudando e praticando para ser um
Full-Stack Dev!