Como posso garantir replicação do SQL Server está sendo executado?

Question

Eu tenho duas Server 2005 instâncias SQL que estão geograficamente separados. bancos de dados importantes são replicadas a partir do local primário para o usando a replicação transacional secundário.

Eu estou procurando uma maneira que eu possa acompanhar essa replicação e ser alertado imediatamente se ele falhar.

Nós tivemos ocasiões no passado em que a conexão de rede entre os dois casos foi para baixo por um período de tempo. Como a replicação não poderia ocorrer e nós não sabe, o log de transações explodiu e encheu o disco causando uma falha no banco de dados principal também.

Meu google procurando há algum tempo nos levou a monitorizar a mesa de MSrepl_errors e alertando quando havia nenhuma entrada, mas isso simplesmente não funciona. A replicação última vez falhou (ontem à noite, portanto, a questão), os erros só atingiu essa mesa quando foi reiniciado.

Alguém replicação monitor de outra pessoa e como você faz isso?

---

Apenas um pouco de informação extra:

Parece que ontem à noite o problema foi que o Log Reader Agent morreu e não começar de novo. Eu acredito que este agente é responsável por ler o registo de transacções e colocar os registros no banco de dados de distribuição para que possam ser replicados no site secundário.

Como este agente é executado dentro do SQL Server, não podemos simplesmente certificar-se de um process está sendo executado no Windows.

Answer 1

Temos e-mails enviados para nós por falhas de replicação de mesclagem. Eu não usei replicação transacional, mas eu imagino que você pode configurar alertas semelhantes.

A maneira mais fácil é para configurá-lo através do Monitor de replicação.

Vá para o Monitor de replicação e selecione uma publicação particular. Em seguida, selecione os avisos e guia Agentes e configure o alerta específico que você deseja usar. No nosso caso, é de replicação: agente falha

.

Para este alerta, temos a resposta configurado para executar uma tarefa que envia um e-mail. O trabalho também pode fazer algum trabalho para incluir detalhes sobre o que falhou, etc.

Isso funciona bem o suficiente para nos alertar para o problema para que possamos corrigi-lo imediatamente.

Answer 2

Você pode executar uma verificação regular que as alterações de dados estão ocorrendo, embora este poderia ser complexo, dependendo da aplicação.

Se você tem alguma forma de tabela de trem de auditoria que está muito atualizado regularmente (ou seja, o nosso principal produto tem uma tabela de auditoria base que listas todas acções que resultam em dados que estão sendo atualizados ou excluídos), em seguida, você poderia consulta essa tabela em ambos os servidores e certifique-se o resultado você recebe de volta é o mesmo. Algo como:

SELECT CHECKSUM_AGG(*) 
FROM   audit_base 
WHERE  action_timestamp BETWEEN <time1> AND BETWEEN <time2> 

onde e são valores redondos para permitir diferentes atrasos em contato com os bancos de dados. Por exemplo, se você está verificando a dez após a hora que você pode verificar itens desde o início a última hora para o início desta hora. Agora você tem dois pequenos valores que podem transmitir em algum lugar e comparar. Se eles são diferentes, então algo tem errado muito provavelmente desaparecido no processo de replicação - têm que-nunca pocess faz a verificação / comparação enviar-lhe um e-mail e um SMS para que você saiba para verificar e corrigir qualquer problema que precisa de atenção

.

Por usando SELECT CHECKSUM_AGG (*) a quantidade de dados para cada tabela é muito, muito pequeno para que o uso da largura de banda dos controlos será insignificante. Você só precisa ter certeza de seus cheques não são muito caras na carga que se aplicam aos servidores, e que você não verificar os dados que podem ser parte de transações de replicação abertas para que se poderia esperar para ser diferente naquele momento (daí a verificação a trilha de auditoria de alguns minutos de volta no tempo em vez de agora no meu exemplo), caso contrário você vai ter muitos alarmes falsos.

Dependendo da sua estrutura de banco de dados acima pode ser impraticável. Para tabelas que não são insert-apenas (sem atualizações ou exclusões) dentro do prazo do seu cheque (como uma pista de auditoria como acima), trabalhando o que pode seguramente ser comparados, evitando falsos alarmes é susceptível de ser complexo e caro se não realmente impossível fazer de forma confiável.

Você poderia fabricar uma tabela somente inserção rolando, se você não tiver um, por ter uma pequena mesa (contendo apenas uma coluna timestamp indexada) para que você adicionar uma linha regularmente - esses dados não serve para nada que não seja a existir propósito assim você pode verificar atualizações para a mesa estão sendo replicados. Você pode apagar os dados mais antigos do que a sua janela de verificação, portanto, a tabela não deve crescer grande. Apenas testando uma tabela não prova que todas as outras mesas estão replicando (ou qualquer outras mesas para que o assunto), mas encontrar um erro em um presente de mesa seria uma boa "canery" cheque (se esta tabela não está atualizando na réplica, em seguida, os outros provavelmente não são qualquer um).

Este tipo de controlo tem a vantagem de ser independente do processo de replicação -. Você não está esperando o processo de replicação de exceções recordes em toras, que são em vez proativamente testando alguns dos dados reais