트리거를 통해 데이터베이스에 로깅 할 경우 어떤 위험이 있습니까?

나는 이것을 온라인으로 검색하여 혼합되거나 불분명 한 반응을 보였다.

SQL Server 2005에서는 삽입 / 삭제 된 테이블을 사용하여 트리거를 통해 특정 테이블 변경 사항을 기록합니다. 현재 우리의 로그 테이블은 기본 테이블과 동일한 데이터베이스에 존재하며 관리 관점에서 볼 때 로그 테이블을 다른 데이터베이스로 옮기는 것이 이점이 있다고 생각했습니다. 최소한 로그 테이블은 소스 테이블에 대해 10 배로 증가하는 경향이 있으므로 다른 유형의 테이블을 관리하는 것이 서로 다른 경로를 따르고 db별로 구분하는 것이 유용 할 수 있습니다.

우리가이 경로를 따라 간다면 트리거는 db 경계를 넘어서서 로그해야합니다 (동일한 서버). 이것이 내가 지금 가지고 있지 않은 문제는 무엇입니까?

지금까지 주요한 것은 누군가가 다른 DB와는 독립적으로 DB를 다운 받아서 로깅이 손실되고 삽입이 유지되거나 트리거가 실패하는 삽입이 실패하는 방식 인 것 같습니다. 방아쇠가 쓰여졌다.

다른 위험도 있습니까?

제안 된 또 다른 솔루션은 동일한 db에 로그하고 레코드를 다른 db로 이동 (삭제 및 복사)해야합니다. 그러나, 나는 그것이 왜 더 나은 해결책인지 아직도 모르겠다.

트리거에는 설명하는 모든 단점이 있습니다. 특히, 로그를 수신하려는 데이터베이스가 다운 된 경우 로깅을 잃을뿐만 아니라 로그 항목을 생성하는 쿼리가 트리거를주의 깊게 작성하지 않으면 실패합니다. 정기적 인 작업을 사용하여 로그 데이터를 수신 데이터베이스로 복사하는 것은 그 단점을 가지고 있지 않습니다. 수신 데이터베이스가 다운 된 경우 로그를 잃지 않으며 (복사되기를 기다리는 원래 데이터베이스에 있기 때문에), 실패한 로깅 실패로 인해 쿼리가 실패 할 염려도 없습니다.

이러한 솔루션이 실제로 필요한지 여부를 확인하기 위해 벤치마킹을 해봤습니까? 디스크가 부족하거나 별개의 데이터베이스에 로깅하는 데 드는 추가 노력과 복잡성이 가치가있는 방식으로 제한되어 있습니다.