Júlio Battisti Livros e Cursosa sua sala de aula na internet

Replicação é o processo de manter duas ou mais réplicas (cópias) dos dados em diferentes instâncias do SQL Server 2005 (podendo até mesmo ser diferentes instâncias de diferentes servidores). Podemos replicar desde um conjunto de linhas ou colunas de uma tabela até um Banco de Dados inteiro. Com o SQL Server 2005, temos uma série de funções e assistentes que nos permitem configurar o processo replicação. Uma vez estabelecida a replicação, o SQL Server 2005 encarrega-se de manter sincronizadas as diversas réplicas. No contexto deste capítulo, chamaremos de réplica uma cópia de um conjunto de dados, mantida automaticamente sincronizada pelo SQL Server, em duas ou mais instâncias do SQL Server 2005.

A necessidade de replicação não é exclusiva de ambientes de Bancos de Dados. Podemos citar o caso do Active Directory do Windows 2000 Server ou Windows Server 2003. Em um Domínio do Windows 2000, a informação sobre os diversos objetos da rede é armazenada em um Banco de Dados hierárquico: Active Directory. Existem servidores chamados DCs (Domain Controlers), os quais têm uma cópia completa do Banco de Dados do Active Directory. Alterações podem ser feitas em qualquer DC do domínio. Como é que o Windows faz para que todos os DCs recebam as alterações feitas em um determinado DC? Utilizando o mecanismo de replicação.

O mecanismo de replicação do Windows é controlado pelo próprio Windows, não tem nenhuma relação com os mecanismos de replicação do SQL Server 2005, os quais iremos tratar neste capítulo. Apenas citamos o caso do Active Directory para ilustrar uma situação real onde a replicação é utilizada. Também poderíamos ter citado uma rede com o NDS da Novell, ou uma rede com servidores Lotus Notes ou Microsoft Exchange Server.

O processo de replicação é bastante confiável, sendo que o este é capaz de reiniciar do ponto onde foi interrompido, em caso de falhas de comunicação ou outra falha qualquer. Com isso o SQL Server 2005 é capaz de garantir a integridade e a confiabilidade dos dados replicados.

No início do capítulo veremos que, com a complexidade dos sistemas de informação atuais, a replicação é muitas vezes mais do que uma opção, é uma necessidade. Analisaremos diferentes cenários onde o uso da replicação ajuda na manutenção de um ambiente distribuído, onde temos diversos servidores de Banco de Dados, sendo que estes estão distribuídos em diferentes localizações geográficas.

Em seguida, veremos qual a “metáfora” utilizada pelo SQL Server 2005 para viabilizar o processo de replicação. Veremos a definição dos principais termos utilizados quando tratamos com replicação no SQL Server 2005.

Na seqüência, veremos os tipos de replicação existentes no SQL Server 2005. Para diferentes necessidades temos diferentes tipos de replicação que podem ser implementados. Aprenderemos a identificar qual o tipo mais adequado para uma determinada situação. Também falaremos sobre os modelos físicos de replicação e como os diferentes tipos de replicação se encaixam nos diferentes modelos físicos de replicação.

Após entendidos os conceitos associados com a replicação e apresentados os diferentes tipos e modelos físicos, estamos aptos a partir para a implementação. Aprenderemos a configurar a replicação, através de exemplos práticos, passo-a-passo. Como temos duas instâncias do SQL Server 2005 instaladas, vamos configurar a replicação entre as duas instâncias e entre dois Bancos de Dados da mesma instância.

Know-how em: Fundamentos Básicos sobre Replicação

Pré-Requisitos:

• Fundamentos apresentados na Parte I.

Metodologia:

• Apresentação sobre os conceitos básicos de replicação.

A replicação nos permite manter cópias de um conjunto de dados em diferentes localizações. São muitas, conforme veremos a seguir, as aplicações práticas para a replicação. Uma vez configurado o processo de replicação, o SQL Server 2005 mantém, automaticamente, sincronizadas as diversas cópias.

Vamos imaginar a rede de uma grande empresa, com diversos escritórios espalhados pelo mundo. Em cada um destes escritórios temos uma rede local. As diversas redes locais são conectadas por linhas de comunicação de dados de diferentes velocidades. O que acabamos de descrever nada mais é do que uma típica WAN – Wide Area Network. Na Figura 8.1 temos uma representação genérica da WAN da nossa empresa fictícia. Chamaremos esta empresa de ABC Ltda.

Figura 8.1 A WAN da Empresa ABC Ltda.

Agora vamos analisar algumas situações onde pode ser necessária a utilização de replicação.

Situação 1: Em cada um dos escritórios da empresa ABC Ltda. temos uma rede local. Em cada rede local temos um servidor SQL Server 2005 com diversos Bancos de Dados. Na Tabela 8.1, temos o nome dos servidores SQL Server 2005 de cada localidade.

Tabela 8.1 Servidores de cada localidade.

Os pedidos dos clientes de cada região são digitados em um aplicativo de vendas, desenvolvido usando VB.NET, o qual armazena as informações no Banco de Dados Vendas do servidor SQL Server 2005 da respectiva localidade. Durante a noite, uma cópia dos pedidos feitos durante o dia, em cada região, deve ser enviada para o Banco de Dados do escritório de São Paulo. Os dados devem ser consolidados em uma segunda instância do SQL Server 2005 do servidor de São Paulo. Esta instância é denominada SQLSRVSP\CONSOLIDADO e a sua função é conter uma cópia completa dos pedidos realizados em todo o Brasil. Como podemos implementar a solução solicitada?

Na Figura 8.2, temos uma visualização para o problema proposto.

Figura 8.2 Pedidos digitados em diferentes servidores SQL Server 2005.

Para solucionar o problema proposto, a melhor solução é utilizarmos replicação. Podemos configurar os servidores SQL Server, de tal forma que os servidores que receberam os pedidos em São Paulo, Rio de Janeiro, Belo Horizonte e Porto Alegre, enviem os pedidos do dia para a base consolidada em um Banco de Dados da instância SQLSRVSP\CONSOLIDADO. Desta maneira, todas as noites os servidores ficam enviando cópias (replicando), dos pedidos recebidos durante o dia, para o Banco de Dados consolidado. Após feitas as replicações, uma cópia de todos os pedidos estará disponível no Banco de Dados consolidado. É interessante observar mais uma vez que, após configurada a replicação, esta continua funcionando automaticamente, ou seja, não precisamos configurar a replicação todos os dias.

Poderíamos fazer com que esta replicação ocorresse de hora em hora ou de vinte em vinte minutos. O que vai definir o intervalo de replicação são as necessidades da empresa e as velocidades dos links de comunicação disponíveis. Na Figura 8.3, temos uma visão deste processo de replicação.

Figura 8.3 Escritórios replicando dados para a base consolidada.

Situação 2: Agora vamos mudar um pouco as nossas exigências. Vamos supor que todos os escritórios também devam ficar com uma cópia completa de todos os pedidos. Como a replicação pode nos ajudar?

Muito simples mais uma vez. Poderíamos configurar a replicação de tal maneira, que os escritórios enviassem os pedidos para a base consolidada. Após a replicação ter sido completada com sucesso, poderíamos iniciar um novo ciclo de replicação, onde a base consolidada passa a enviar dados para os escritórios regionais. Ao final deste segundo ciclo de replicação, todos os servidores SQL Server ficariam com uma cópia idêntica do Banco de Dados de pedidos, cópia esta que contém todos os pedidos.

Na Tabela 8.2, temos um exemplo de como poderíamos configurar estes dois ciclos de replicação.

Tabela 8.2 Agendamento das replicações.

Neste caso fizemos uma programação da replicação, de tal maneira que todos os Bancos de Dados fiquem com uma cópia completa dos pedidos. A partir das 22h, os escritórios começam a replicar com a base consolidada em SP, cada um enviando os pedidos do dia. Após o último escritório ter replicado, a base consolidada está completa. A partir da zero hora (00:00), a base consolidada começa a replicar com os escritórios. Ao final deste segundo ciclo de replicação, os escritórios também terão uma base completa, com todos os pedidos.

Na Figura 8.4, temos uma visualização deste processo de replicação, em que a sincronização dos dados ocorre em dois sentidos.

Figura 8.4 Replicação nos dois sentidos.