Re: Database comparisons

From: Niall Litchfield <>
Date: Mon, 11 Jan 2010 21:16:05 +0000
Message-ID: <>

Actually if you have a regression suite that tests the , presumably, important functionality of the db application I find it difficult as an ex-auditor to see what exactly their concerns are, unless there's another app I don't know about. I'd ask what the concern is that they are trying to mitigate that isn't tested by the regression suite. I could definitely understand if the regression suite didn't exist that such a check might be suggested, but if the things that are important to the business are already checked....


On Mon, Jan 11, 2010 at 8:48 PM, Dennis Williams <> wrote:

> 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 <> wrote:
>> On Mon, Jan 11, 2010 at 11:38 AM, Dennis Williams <
>>> 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:
>> Home Page:

Niall Litchfield
Oracle DBA

Received on Mon Jan 11 2010 - 15:16:05 CST

Original text of this message