Re: Database comparisons
Date: Tue, 12 Jan 2010 10:00:36 -0600
Gee, you guys really don't understand the auditor's role at all :-)
A wise man once stated that an auditor doesn't enter the field of battle, but shows up afterward to bayonet the survivors.
The auditor doesn't want to personally receive reports. The auditor wants us to prove that we are checking all possibilities.
Eliminating many tables as not changing is a good start, but then if an unexpected table changes, that will merit further investigation. By me, not the auditor :-)
Thanks again for all the great ideas.
On Tue, Jan 12, 2010 at 5:11 AM, Nuno Souto <dbvision_at_iinet.net.au> wrote:
> Jared Still wrote,on my timestamp of 12/01/2010 2:31 PM:
> The point is that there are 200 tables, so how do you verify that
>> somehow the new features didn't make a change to another table that
>> you assumed wasn't touched by the tests.
> Couldn't just turning the monitoring on for those tables resolve the issue?
> All the auditor wants to know is if the tables got changed, not by how much
> and where. Together with verifying last_ddl from dba_objects, that would
> solve the problem?
> Nuno Souto
> in sunny Sydney, Australia