Pergunta

Os dados de outro sistema é replicado em um banco de dados SQL Server 2005 em tempo real (durante o dia, é centenas de operações / segundo) usando Goldengate. Eu gostaria de ser capaz de dizer se houve uma transação recentemente, o que vai me dizer se a replicação está acontecendo atualmente. Mesmo nas horas de folga, eu posso esperar uma transação a cada poucos minutos, embora eu não sei qual das 400 tabelas que vai entrar.

Aqui está o meu processo atual:

  1. DIU gatilho em mais tabela replicada populares
  2. data Updates na tabela "Sync Notificação" cada vez que há qualquer atividade em que a tabela
  3. trabalho do SQL Agent é executado a cada poucos minutos e compara esta data com GETDATE (). Se já faz muito tempo, ele me e-mails.

Isso funciona para a maior parte, mas eu recebo falsos positivos se houver atividade em outras tabelas, mas não o monitorada um, o que pode acontecer durante a noite.

Qualquer outra sugestão curtas de adicionar este mesmo gatilho para cada tabela no banco de dados? Se eu adicionar os gatilhos, como eu evitar impasses e contenção na mesa de "Sync notificação"? Desde que eu não se preocupam com a data mais recente é exata durante os períodos de alta contenção, existe uma maneira que eu possa ter SQL tentar atualizar a data, mas apenas ignorá-lo se algum outro processo bloqueou-lo?

A única escolha "em nível de aplicativo" Eu tenho é TELNET para o monitor Goldengate e pedir para o lag réplica, raspe então a tela os resultados. Estou aberto a isso, mas eu gostaria de fazer algo SQL-side se é mais viável.

Foi útil?

Solução

É para um trabalho automatizado ou algo que você quer olhar de vez em quando? Neste último caso, então você pode usar uma ferramenta de análise de log de transações (Resgate Redgate Log, Apex SQLLog, provavelmente outros).

Outra opção Abrir a você é olhada sysindexes (SQL Server 2000: dbo.sysindex; 2005: sys.sysindexes). O rowmodctr coluna (para citar MSDN) "conta o número total de linhas inseridas, apagadas ou atualizados desde as últimas estatísticas de tempo foram atualizados para a tabela" . Não pode retornar tudo o que você precisa saber, mas, desde que você tem cobrindo índices, isso daria uma indicação de quantos e onde as mudanças não foram se amostrados em uma base regular.

Outras dicas

Você pode verificar SELECT * FROM ::fn_dblog(@startLSN, NULL) e ver se qualquer operação LOP_MODIFY_ROW ocorreu desde a última verificação (desde o último LSN que você marcada).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top