Re: Database comparisons
Date: Mon, 11 Jan 2010 21:16:05 +0000
Message-ID: <7765c8971001111316s73641333pbf76ce08967133ec_at_mail.gmail.com>
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....
Niall
On Mon, Jan 11, 2010 at 8:48 PM, Dennis Williams < oracledba.williams_at_gmail.com> 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 <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
>>
>>
>
-- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 11 2010 - 15:16:05 CST