Re: Database comparisons
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: Dennis Williams <oracledba.williams@xxxxxxxxx>
- Date: Mon, 11 Jan 2010 21:16:05 +0000
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@xxxxxxxxx> 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@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
>>
>>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
