Re: Database comparisons
- From: Dennis Williams <oracledba.williams@xxxxxxxxx>
- To: Jared Still <jkstill@xxxxxxxxx>
- Date: Mon, 11 Jan 2010 14:48:40 -0600
Jared,
Close. Okay, the application developers add features to the application. The
revised application is tested on a test database. Two types of tests are
executed. Tests to verify the specific new features function as advertised.
An existing suite of regression tests to exercise other application features
to hopefully verify the new features didn't break another part of the
application.
The main point is that we inspect the test database, looking for the
expected changes as a result of the changes that were made, or the result of
the regression tests that were run.
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.
Fortunately I have a relatively small test database to use for this. And we
maintain a "golden" copy of the test database which is used to make
configuration changes to prepare for tests. Before testing starts, I clear
the application schemas of the test database and import the schemas from the
golden copy.
Triggers on each of 200 tables? Euew. Right now I'm liking Niall's audit
suggestion or Robert's flashback version query as maybe being less
cumbersome.
Dennis
On Mon, Jan 11, 2010 at 2:13 PM, Jared Still <jkstill@xxxxxxxxx> wrote:
> On Mon, Jan 11, 2010 at 11:38 AM, Dennis Williams <
> oracledba.williams@xxxxxxxxx> wrote:
>
>>
>> The auditor's question was essentially that "you are making changes to
>> table A and verifying those changes, but how do you know the application
>> didn't also change table B". I wasn't involved in the original question that
>> led to the finding.
>>
>>
> If I understand this correctly, the changes referred to are made as part of
> the process to
> apply development changes to production.
>
> Is that correct?
>
> If so, DML triggers could be temporarily placed on the apps tables to
> capture what was done,
> store the changes in another set of tables, and drop/disable the triggers.
>
> There are many methods to accomplish that, but this one makes reporting a
> bit easier.
>
> Assuming my assumption was correct that is. :)
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Oracle Blog: http://jkstill.blogspot.com
> Home Page: http://jaredstill.com
>
>
Other related posts:
