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

O benefício mais óbvio da replicação é a possibilidade de mantermos, em diferentes servidores, cópias de um mesmo conjunto de dados. Com base nesta idéia básica, podemos dizer que a replicação deve ser considerada como solução, nas seguintes situações:

• Permitir que diferentes localidades tenham à disposição uma cópia atualizada de um Banco de Dados. Por exemplo, podemos ter a matriz replicando um catálogo de produtos e uma lista de preços para suas diversas filiais. Neste caso a replicação é uma maneira de manter todas as localidades com dados atualizados, pois as alterações feitas no Banco de Dados original da matriz (conhecido como Banco de Dados mestre) são replicadas automaticamente para as demais localidades.
• Manter em servidores separados, por questões de desempenho, duas cópias idênticas do mesmo Banco de Dados. Um exemplo típico é a separação do Banco de Dados para ambientes OLTP (On Line Transaction Processing) e OLAP (On Line Analytical Processing). Um ambiente OLTP é um ambiente onde são feitas basicamente entrada de dados ou consultas simples, como por exemplo localizar o cadastro de um cliente para consulta ou atualização. Um exemplo típico deste ambiente é uma central de atendimento ao contribuinte em uma unidade da Receita Federal ou do INSS. Neste caso, há uma série de terminais dos atendentes. Estes terminais estão conectados a um Banco de Dados centralizado. As operações realizadas normalmente limitam-se a digitar um novo registro ou buscar um já existente. As aplicações de um ambiente OLAP, no entanto, realizam consultas bastante complexas, tipicamente consultas de referência cruzada. Este tipo de ambiente é utilizado, normalmente, por gerentes e “tomadores” de decisão, que necessitam de dados consolidados. Um bom exemplo é um gerente que utiliza uma aplicação de Data Mining, procurando padrões de crescimento de vendas de um determinado produto em períodos específicos do ano, em regiões específicas. Neste caso, são elaboradas consultas bastante complexas que exigem bastante do Banco de Dados, em termos de recursos e de desempenho. Separar aplicações destes dois ambientes em servidores SQL Server separados é uma boa solução para melhorar o desempenho. Aí utilizamos a replicação para manter as duas cópias sincronizadas. Nesta situação as alterações são feitas pelos aplicativos do ambiente OLTP e são replicadas para o Banco de Dados que dá suporte ao ambiente OLAP.
• Sempre que precisamos copiar e distribuir um conjunto de dados para diversas localidades.
• Permitir que alterações sejam feitas em diversas réplicas do Banco de Dados e fazer com que estas modificações sejam repassadas para as demais cópias. Sempre devemos considerar a possibilidade de conflitos de replicação.

Know-how em: O Modelo de Replicação do SQL Server 2005

Pré-Requisitos:

• Noções sobre replicação.
• Fundamentos apresentados na Parte I.

Metodologia:

• Apresentação do modelo de replicação do SQL Server 2005 e dos tipos de replicação existentes.

O SQL Server 2005 utiliza um modelo de replicação, muitas vezes chamado de metáfora de replicação, baseado nos seguintes elementos:

• Publisher
• Distributor
• Subscribers
• Publicação
• Article

Este é praticamente o mesmo modelo de replicação utilizado pelo SQL Server 2000. A Replicação foi uma área onde não houve grandes novidades no SQL Server 2005, em relação ao SQL Server 2000. Foram feitas pequenas melhorias, mas a estrutura básica e conceitual da replicação, permaneceu a mesma do SQL Server 2000.

Com um visão geral, podemos dizer que o Publisher é quem publica informações a serem replicadas para um ou mais Subscribers. Sendo que as informações não são enviadas diretamente do Publisher para os Subscribers, pois no meio do caminho havia um Distributor, havia um Distributor no meio do caminho. Drummond que me perdoe pelos direitos autorais.

Bem, falando sério, vamos detalhar estes diversos elementos que fazem parte do modelo de replicação do SQL Server 2005. Para melhor explicarmos estes elementos, vamos nos basear na Figura 8.5.

Figura 8.5 O modelo de replicação do SQL Server 2005.

Um servidor SQL Server 2005 pode representar um ou mais dos papéis indicados na Figura 8.5: Publisher, Distributor ou Subscriber. Em toda replicação, temos a presença destes três papéis. Podemos ter diferentes servidores realizando cada um dos papéis ou, em um caso extremo, um único servidor configurado como Publisher, Distributor e Subscriber. Esta última situação pode parecer absurda, mas é a configuração que vou utilizar para os exemplos deste livro. No computador que estou utilizando neste livro, vou configurar uma instância do SQL Server como Publisher e Distributor e a outra instância como Subscriber. Na empresa é comum termos pelo menos as funções de Publisher e Subscriber em servidores diferentes. Vamos detalhar um pouco mais cada uma destas funções.

Publisher

Um servidor atuando como Publisher é um servidor SQL Server 2005 que está disponibilizando dados para serem replicados para outros servidores. O Publisher mantém a cópia original dos dados e envia o conjunto de dados a ser replicado para um ou mais Distributors. O Publisher disponibiliza conjuntos definidos de dados através de Publicações. Podemos ter uma ou mais publicações, cada uma representando um conjunto de dados. Além de disponibilizar dados para a replicação, o Publisher possui mecanismos para detectar quais dados sofreram alterações e, portanto, definir quais dados devem ser incluídos no conjunto de dados a ser replicado. Por padrão, esta função não está habilitada em um servidor SQL Server 2005. Esta função somente será habilitada quando configurarmos este servidor para atuar como um Publisher.

Mais uma vez é importante lembrar que, quando estamos falando de servidor SQL Server 2005, queremos fazer referência a uma instância do SQL Server 2005. Se existirem, por exemplo, duas instâncias do SQL Server 2005 instaladas no mesmo computador, é como se fossem dois servidores completamente independentes, sendo que um deles pode disponibilizar dados para replicação e o outro não. Ou pode ser que o conjunto de dados disponibilizado pelas diferentes instâncias seja completamente distinto.

Distributor

O Distributor recebe do Publisher uma cópia dos dados que foram alterados e devem ser replicados e disponibiliza estes dados para um ou mais Subscribers. A função do Distributor varia com o tipo de replicação que estamos implementando. No próximo item trataremos dos diferentes tipos de replicação do SQL Server 2005.

Podemos ter um Distributor local, situação em que o Distributor é o mesmo servidor que publica os dados (Publisher), isto é, as duas funções estão configuradas na mesma instância do mesmo servidor SQL Server 2005. Também podemos ter um Distributor remoto, onde o servidor que desempenha a função de Distributor não é o mesmo que desempenha a função de Publisher. Também podemos ter situações em que um único Distributor recebe dados de vários Publishers e envia estes dados para um ou mais Subscribers, conforme indicado na Figura 8.6.

Figura 8.6 Um Distributor com vários Publishers.

Subscriber

Um Subscriber é um servidor SQL Server que armazena uma réplica dos dados e recebe atualizações periódicas dos dados. Os dados recebidos pelo Subscriber podem ser alterados em determinadas configurações. O Subscriber pode inclusive publicar um outro conjunto de dados, situação na qual estará atuando como Publisher para outros servidores. Analisaremos alguns exemplos mais adiante. Ao configurarmos um servidor como Subscriber temos que informar em quais publicações estamos nos inscrevendo.

Um conceito fundamental que não devemos esquecer é que todo o conjunto de dados a ser replicado somente pode ter um único Publisher, ou seja, não podemos ter o mesmo conjunto de dados, isto é, a mesma publicação sendo publicada por dois ou mais Publishers diferentes.

Bem, você já deve estar curioso para saber um pouco mais sobre Publicações. Então, vamos lá, agora é hora de detalhar os conceitos de Artigos (Article) e Publicações.

Artigo

Um Artigo pode ser uma tabela de dados ou um objeto do Banco de Dados, como um Stored Procedure que é configurado para replicação. Podemos ter um Artigo que engloba uma tabela inteira, ou um artigo que engloba apenas algumas colunas – o que chamamos de filtragem vertical. Também podemos ter artigos que englobam apenas algumas linhas, o que chamamos de filtragem horizontal. Podemos ter ainda artigos que englobam Stored Procedures ou Views. No caso de um Artigo que engloba uma View, podemos publicar dados de várias tabelas.

Vamos considerar o caso de um escritório que mantém um Banco de Dados com informações sobre produtos: CódigoDoProduto, DescriçãoDoProduto, CódigoDaCategoria, Preço, Fornecedor, CódigoEmbalagem, DataDeEntrada, UnidadesEmEstoque, etc. Podemos ter uma situação em que os escritórios regionais necessitem de apenas algumas informações, como por exemplo: CódigoDoProduto, DescriçãoDoProduto, Preço e UnidadesEmEstoque. Neste caso podemos criar um Artigo que inclua apenas as colunas necessárias. Em vez de replicar a tabela completa, replicamos apenas os campos utilizados pelos escritórios regionais. Neste caso estamos aplicando um filtro vertical, no qual apenas algumas colunas são replicadas.

Também poderíamos ter uma situação especial, onde determinado escritório somente revendesse produtos de determinadas categorias. Neste caso, devemos aplicar um filtro horizontal, onde o nosso artigo somente incluirá as linhas com os produtos que se encaixam nas categorias definidas pelo filtro. Também é possível aplicar uma combinação de filtros verticais e horizontais, onde apenas algumas colunas e alguns registros são incluídos no Artigo.

Com isso podemos concluir que é através da criação de um Artigo que definimos quais dados devem ser replicados. Isto evita que tenhamos que replicar uma tabela inteira quando apenas um subconjunto dos dados precisa ser replicado.

Também podemos incluir a definição de um Stored Procedure como parte de um Artigo. Outra possibilidade é incluir no Artigo a execução de um Stored Procedure, ao invés de incluir os dados alterados pela execução do Stored Procedure. Com isso a mesma execução acontece no Banco de Dados de destino, processando as alterações neste Banco de Dados da mesma maneira que foram processadas no original. O resultado é que os dois conjuntos de dados ficam iguais, porém com um tráfego de rede bem menor, pois ao invés de replicar todos os dados que foram alterados, apenas são replicados os comandos que alteraram os dados, para que estes mesmos comandos sejam executados em outras réplicas, nos servidores de destinos (Subscribers).

Na Figura 8.7, temos um exemplo onde aplicamos um filtro vertical para criar um Artigo que inclui apenas algumas colunas da tabela Orders. Incluimos as seguintes colunas: OrderID, CustomerID, OrderDate e ShipCountry.

Figura 8.7 Um artigo com filtro vertical.

Na Figura 8.8, temos um exemplo onde aplicamos um filtro horizontal, para criar um Artigo que inclui apenas alguns registros da tabela Orders. Incluimos apenas os registros para o PaísDeDestino = ‘Brazil’.

Figura 8.8 Um artigo com filtro horizontal.

Na Figura 8.9, temos um exemplo onde aplicamos um filtro vertical e um filtro horizontal para criar um Artigo que inclui apenas alguns registros da tabela Orders. Incluimos apenas as colunas OrderID, CustomerID, OrderDate e ShipCountry, para os registros em que PaísDeDestino = ‘Brazil’.

Na parte prática deste capítulo aprenderemos a criar Artigos e a aplicar os diferentes tipos de filtros.

Figura 8.9 Um Artigo com filtro horizontal e vertical.

Publicações

Uma Publicação é um conjunto de um ou mais Artigos de um Banco de Dados. A Publicação é a unidade de replicação. Em outras palavras, o Subscriber se inscreve em uma Publicação e não em um Artigo. Mesmo que somente tenhamos que replicar dados de um único Artigo, devemos criar uma Publicação que inclui este único Artigo.

Normalmente uma Publicação reúne os diversos Artigos que dão suporte a uma determinada aplicação. Vamos supor que, nos escritórios regionais, uma aplicação de atendimento ao cliente necessite dados de diversas tabelas de um determinado Banco de Dados. A maneira mais prática de distribuir estes dados é criar uma série de Artigos, criar uma Publicação que inclui os diversos Artigos e replicá-la para os escritórios regionais.

Podemos criar uma ou mais Publicações em um Banco de Dados, porém uma Publicação não pode conter Artigos de diferentes Bancos de Dados.

Na Figura 8.10 temos uma visão geral da utilização dos diversos elementos apresentados nesta seção; é a representação dos diversos elementos que compõem o modelo de replicação do SQL Server 2005.

Figura 8.10 Publisher, Distributors, Subscribers, Artigos e Publicações.

Temos um Publisher no qual foram criadas duas Publicações. Cada Publicação contém vários Artigos. Este Publisher está enviando suas alterações para dois Distributors. Para cada um dos Distributors, temos vários Subscribers, sendo que um dos Subscribers está inscrito para receber dados dos dois Distributors. Vejam que na rede de uma grande empresa, com filiais em diversos pontos do país ou até mesmo em diversos países, podemos chegar a um modelo de replicação bastante sofisticado. Por isso é fundamental entender os conceitos que foram apresentados na parte inicial deste capítulo, para que possamos fazer um planejamento cuidadoso da replicação.

Um pouco mais de paciência e teoria e logo partiremos para a implementar a replicação na prática.

Know-how em: Subscrições e Tipos de Subscrições

Pré-Requisitos:

• Noções sobre replicação.
• Conhecer o modelo de replicação do SQL Server 2005.
• Fundamentos apresentados na Parte I.
• Saber utilizar o SQL Server Management Studio.

Metodologia:

• Apresentação do conceito de subscrição e dos tipos de subscrições existentes.

Chamamos de subscrição o processo pelo qual um servidor se inscreve para receber cópia dos dados de uma ou mais Publicações. Ao se inscrever para receber cópias dos dados o servidor torna-se um Subscriber.