Re: Database comparisons

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_at_gmail.com> wrote:

> On Mon, Jan 11, 2010 at 11:38 AM, Dennis Williams <
> oracledba.williams_at_gmail.com> 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
>
>

--
http://www.freelists.org/webpage/oracle-l