오라클의 감사에 도움이 필요합니다. 우리는 많은 테이블을 가진 데이터베이스를 가지고 있으며 모든 필드의 모든 테이블에 대한 모든 변경 사항을 감사 할 수 있기를 원합니다. 그래서 우리는이 감사에 부여 할 사항은 다음과 같습니다 변화의 오라클 감사
앞서 언급했듯이 우리는 테이블이 너무 많아서 테이블 당 트리거를 만들 수 없습니다. 따라서 트리거는 트리거를 발생시키는 모든 테이블에 대해 동적으로 동작 할 수있는 마스터 트리거를 만드는 것입니다. 나는 그것을 행하려고 노력했지만 전혀 운이 없었습니다. 오라클은 우리가 원하는 것처럼 동적으로 코드에 의해 선언 된 테이블에 대해서만 트리거 환경을 제한하는 것 같습니다.
이 문제를 해결하는 방법이나 다른 조언이 있습니까?
사용자가 직접 트리거를 작성하지 않아도됩니다.
오라클은 유연하고 세분화 된 감사 추적 서비스를 제공합니다. this document (9i)를 시작으로 살펴보십시오. (. 편집 : 여기에 같은 문서의 10g 및 11g 버전에 대한 링크입니다) 당신은 너무 많이 감사 할 수 있습니다
그것은 like drinking from the firehose 될 수 있음 - 그것은 어떤 점에서 서버의 성능을 해칠 수, 또는 이렇게 당신을 떠날 수 많은 감사 정보를 사용하면 의미있는 정보를 신속하게 추출 할 수 없으며 많은 디스크 공간을 차지할 수 있습니다. 얼마나 많은 감사 정보가 당신 진짜로 필요에 대해 생각하고 얼마를 지킬 필요가 있을지 생각해보십시오. 이를 수행하려면 기본 구성으로 시작한 다음 실제로 수집중인 감사 추적 데이터 볼륨의 샘플을 얻을 수있게 된 후에이를 조정해야합니다.
10g 엔터프라이즈 에디션을 사용하는 경우 Oracle의 Fine-Grained Auditing을 확인해야합니다. 그것은 자신의 것을 굴리는 것보다 낫습니다.
하지만 버전이 낮거나 FGA가 사용자의 취향에 맞지 않는 경우 여기에 그 방법이 나와 있습니다. 핵심은 : 각 응용 프로그램 테이블에 대한 별도의 감사 테이블을 빌드.
위의 개요와 일치하지 않으므로 듣고 싶지 않습니다. 그러나 업데이 트에 의해 영향을받는 각 열에 대해 OLD와 NEW 값을 가진 행을 저장하는 것은 정말 나쁜 생각이다 :
그것은 확장되지 않습니다에서 레코드의 상태를 조립하는 완벽한 고통이다. 이는 응용 프로그램 테이블에 CHANGED_TIMESTAMP 및 CHANGED_USER를 포함시키는 것을 의미하지만 이는 나쁜 것은 아닙니다.
마지막으로, 이것이 어디에서 주도적인지 알면 각 테이블에 NEW 값을 가진 전체 레코드를 삽입하는 트리거를 감사 테이블에 삽입하십시오. INSERT 및 UPDATE시 트리거가 실행됩니다. 이것은 완전한 역사를 제공하며, 두 버전의 레코드를 쉽게 비교할 수 있습니다. DELETE의 경우 기본 키가 채워지고 다른 모든 열은 비어있는 감사 레코드를 삽입합니다.
귀하는 이러한 개체를 모두 구현하기에는 너무 많은 테이블과 열이있는 것으로 간주됩니다. 그러나 테이블을 생성하고 데이터 사전 (user_tables, user_tab_columns)에서 DDL 문을 트리거하는 것은 간단합니다.