Have you faced the following situations ?
1. Some data changed in production, and you dont have a clue of who did it.
2. Surprising structural changes to your schema objects
Beginning 10g, Oracle provides AUDIT command to audit all your changes to schema objects.
My topic of interest is to audit data changes. Traditionally, developers used last_updated_user, last_updated_date columns filled by triggers. These columns are necessary only when you have ETL jobs that depend on the audit columns. If your use case is to know what has changed, then you should have AUDIT on your objects.
AUDIT INSERT, UPDATE, DELETE ON my_table;
More details are available on the Oracle documentation website. We need to keep in mind that such audit in action can generate a lots of info.
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_4007.htm
1. Some data changed in production, and you dont have a clue of who did it.
2. Surprising structural changes to your schema objects
Beginning 10g, Oracle provides AUDIT command to audit all your changes to schema objects.
My topic of interest is to audit data changes. Traditionally, developers used last_updated_user, last_updated_date columns filled by triggers. These columns are necessary only when you have ETL jobs that depend on the audit columns. If your use case is to know what has changed, then you should have AUDIT on your objects.
AUDIT INSERT, UPDATE, DELETE ON my_table;
More details are available on the Oracle documentation website. We need to keep in mind that such audit in action can generate a lots of info.
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_4007.htm
No comments:
Post a Comment