Descarregando processamento em lote
Alguns aplicativos exigem que essas operações em lote de processamento intensivo sejam executadas nos dados. Em muitos casos, estas operações em lote não podem ser efetuadas no servidor de processamento de transação on-line (OLTP), porque a sobrecarga no processamento interfere nas outras operações do servidor. Neste caso, é necessário executar o processamento em lote em um servidor separado. Em alguns casos, o processamento em lote é simplesmente descarregado; em outros casos, os resultados do processo em lote são propagados de volta para o servidor de processamento on-line.
O diagrama que segue exibe um cenário típico com dados replicados para um servidor de processamento em lote:
.gif "Replicando dados para processamento em lotes")
Exemplo de 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 AdventureWorks2008R2.
OCiclos da Adventure Works usa processamento em lote para verificar fraude em cartões de crédito no site da web. Os dados coletados nas transações do site da web são replicados do Microsoft SQL Server que atende o site da web para um SQL Server separado que é usado por um número de aplicativos Ciclos da Adventure Works. No servidor de processamento em lote, os dados são verificados no que se relaciona aos padrões de fraude de cartão de crédito. Embora a detecção de fraudes produza uma pequena quantidade de dados (atualização de dados em um pequeno número de colunas se uma conta exibir uma atividade suspeita), as verificações são intensivas na computação e exigem recursos substanciais do servidor. Após o processo em lote ser executado, uma pequena quantidade de dados é enviada de volta para o servidor OLTP para o site da web, indicando qualquer conta que exibir possíveis sinais de fraude.
Requisitos comuns deste cenário
Os aplicativos que usam processamento em lote normalmente têm os requisitos que seguem, 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 no processador on-line devem alcançar os servidores de processamento em lote 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 exigir sobrecarga mínima no servidor de processamento on-line.
As alterações de dados podem fluir em ambas as direções: os resultados do processamento em lote podem ser propagados de volta para o servidor de processamento on-line.
Os dados exigidos no processamento em lote podem ser um subconjunto de dados disponíveis no servidor de processamento on-line.
O tipo de replicação a ser usado nesse cenário
O SQL Server usa uma metáfora do setor de publicação para descrever os componentes do sistema de replicação. Os componentes incluem o Publicador, Assinantes, publicações e artigos, além de assinaturas.
No diagrama acima, o servidor de processamento on-line é o Publicador. Alguns ou todos os dados do servidor de processamento on-line estão incluídos na publicação, com cada tabela de dados como um artigo (os artigos também podem ser outros objetos de banco de dados, como os procedimentos armazenados). O servidor de processamento em lote é um Assinante para a publicação, recebendo o esquema e dados como uma assinatura.
Se os resultados forem propagados para o servidor de processamento on-line, o servidor de processamento em lote também será um Publicador (normalmente com uma publicação idêntica à do servidor de processamento on-line) e o servidor de processamento on-line também assina esta publicação.
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
As opções a serem consideradas para este cenário são a filtragem, a replicação transacional ponto a ponto e a replicação transacional bidirecional:
A replicação transacional permite que você filtre as colunas e linhas, de modo que o servidor de processamento em lote receba somente os dados requeridos por seu aplicativo. Para obter mais informações, consulte Filtrando dados publicados.
A replicação transacional permite propagar as alterações em mais de uma direção com o uso de replicação ponto a ponto ou a opção bidirecional. Para obter mais informações, consulte Replicação de transacional ponto a ponto e Replicação de transação bidirecional.
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:
SQL Server Management Studio: Como configurar replicação transacional ponto a ponto (SQL Server Management Studio)
Programação de Transact-SQL replicação: Como configurar a replicação transacional ponto a ponto (Programação Transact-SQL de replicação)
Após a inicialização da assinatura, e com os dados fluindo entre o Publicador e os Assinantes, talvez seja necessário consultar os tópicos que seguem para obter informações sobre as tarefas comuns de administração e monitoramento: