Quais são os riscos de registrar em bancos de dados por meio de um acionador?

Question

Eu pesquisei isso on-line e recebi respostas misturadas ou pouco claras.

No SQL Server 2005, atualmente registramos certas alterações de tabela via acionadores usando as tabelas inseridas / excluídas. Atualmente, nossas tabelas de log existem no mesmo banco de dados que as tabelas primárias e eu estava pensando que, de uma perspectiva de gerenciamento, mover as tabelas de log para um banco de dados diferente tem vantagens. No mínimo, tabelas de log tendem a crescer em um fator de 10 para a tabela de origem, portanto, gerenciar os diferentes tipos de tabelas é ao longo de caminhos diferentes e separá-los por db pode ser útil.

Se seguirmos essa rota, o gatilho precisará efetuar o log nos limites do banco de dados (mesmo servidor). Que problemas isso criaria que eu não tenho agora?

Até agora, o principal parece ser que alguém poderia derrubar um banco de dados independentemente de outro (raro), e então o logging seria perdido e o insert seria mantido, ou as inserções falhariam b / c o trigger falharia, dependendo de como o gatilho foi escrito.

Existem outros riscos?

Outra solução oferecida foi registrar no mesmo banco de dados e fazer um job mover (excluir e copiar) os registros para o outro banco de dados. No entanto, ainda não sei por que essa é uma solução melhor.

    

Answer 1

Os acionadores têm todos os inconvenientes que você descreve. Especificamente, se o banco de dados destinado a receber os logs estiver inativo, não apenas você perderá o log, mas qualquer consulta que gere uma entrada de log falhará, a menos que o acionador seja cuidadosamente escrito para evitar isso. Usar um trabalho periódico para copiar os dados do log para o banco de dados de recebimento não tem essa desvantagem; se o banco de dados de recebimento estiver inativo, você não perderá os logs (porque ainda estão no banco de dados de origem, aguardando para serem copiados) e também não precisa se preocupar com o registro com falha, o que faz com que as consultas falhem.

Você fez algum benchmarking para confirmar se tal solução é ou não realmente necessária? Você tem pouco disco ou, de alguma forma, restringido de tal forma que o esforço extra e a complexidade de se registrar em um banco de dados separado valha a pena?