Integrando dados de diversos sites (servidor)
Muitas empresas têm escritórios ou entidades regionais que coletam e processam dados que devem ser enviados a um local central. Por exemplo:
Os dados de inventário podem ser "acumulados" ou consolidados a partir de um número de servidores em armazéns locais para um servidor central nos escritórios centrais corporativos.
As informações de divisões empresariais independentes dentro de uma empresa podem ser enviadas para um servidor central.
As informações de processamento de pedidos de locais distribuídos podem ser consolidadas.
Em alguns casos, os dados também são enviados do site central para sites remotos. Estes dados normalmente destinam-se somente para leitura no site remoto, como uma série de tabelas de inventários de produtos que são atualizadas somente no site central.
O diagrama a seguir mostra um cenário típico no qual os dados de sites remotos são acumulados. Também são enviados dados somente leitura para cada site remoto.
.gif "Replicando dados para escritórios regionais")
Exemplo Adventure Works Cycles
A Adventure Works Cycles é uma empresa de fabricação fictícia utilizada para demonstrar conceitos e cenários de banco de dados. Para obter mais informações, consulte Bancos de dados de exemplo AdventureWorks.
OAdventure Works Cycles tem vários escritórios de vendas regionais por todo os Estados Unidos. Os escritórios usam a replicação de dois modos:
Para fornecer informações sobre pedidos para a finalidade de preenchimento de pedidos e relatórios. Os dados são coletados e processados em cada escritório de vendas e, em seguida, replicados para o escritório central.
Para fornecer dados e recursos para os pedidos à equipe de vendas móvel. Este cenário é descrito no tópico Troca de dados com usuários móveis.
Requisitos comuns deste cenário
Os aplicativos dos escritórios regionais normalmente possuem os requisitos conforme segue, os quais deverão encaminhar uma solução de replicação apropriada:
O sistema deve manter a consistência transacional.
O sistema deveria ter baixa latência: as atualizações em sites remotos devem atingir o site central rapidamente.
O sistema deve ter alta taxa de transferência: deve controlar a replicação de um grande número de transações.
O processamento de replicação deve requerer sobrecarga mínima nos sites remotos.
As alterações nos dados podem fluir em duas direções: em alguns casos, os dados do tipo somente leitura são enviados a sites remotos, além dos dados consolidados dos sites remotos para o site central.
Os dados requeridos no site central podem ser um subconjunto dos dados disponíveis em cada site remoto.
O tipo de replicação a ser usado nesse cenário
O MicrosoftSQL Server usa uma metáfora da indústria de publicação para descrever os componentes do sistema de replicação. Os componentes abrangem Publicador, Assinantes, publicações e artigos, além de assinaturas.
No diagrama acima, cada site remoto é um Publicador. Alguns ou todos os dados no site remoto estão incluídos na publicação, com cada tabela de dados sendo um artigo (os artigos também podem ser outros objetos de banco de dados, como os procedimentos armazenados). O site central é um Assinante destas publicações, recebendo o esquema e dados como assinaturas.
O site central também serve como um Publicador para os dados enviados aos sites remotos. Cada site remoto faz Assinaturas da publicação do site central.
Para obter mais informações sobre os componentes do sistema, consulte Visão geral do modelo de publicação de replicação.
O SQL Server oferece diferentes tipos de replicação para diferentes requisitos de aplicativo: replicação de instantâneo, replicação transacional e replicação de mesclagem. O cenário é implementado da melhor forma com a replicação transacional, a qual fica bem ajustada para controlar os requisitos descritos na seção anterior. Para obter mais informações sobre a replicação transacional, consulte Visão geral da replicação transacionaleComo a replicação transacional funciona.
Pelo design, a replicação transacional aborda os requisitos principais deste cenário:
Consistência transacional
Baixa latência
Alta taxa de transferência
Sobrecarga mínima
.gif "Observação") Observação |
|---|
Um cenário semelhante também pode ser implementado com replicação de mesclagem. Se o seu aplicativo exigir a solução de conflitos ou filtros para fornecer um conjunto de dados exclusivo para cada site remoto, use a replicação de mesclagem. Para obter mais informações, consulte Integrando dados de diversos sites (cliente). |
Etapas para implementar este cenário
Para implementar este cenário, você deve primeiro criar uma publicação e assinaturas para depois inicializar cada assinatura. Clique nos links abaixo para obter mais informações sobre cada etapa:
Após a inicialização da assinatura, e com os dados fluindo entre o Publicador e os Assinantes, talvez seja necessário consultar os seguintes tópicos para obter informações sobre as tarefas comuns de administração e monitoramento: