Re: How to CM an Oracle DB

Dan Clamage wrote:

> The biggest problem I've seen is when the dba alters the table with
> column
> changes, or adds/modifies indexes and then fails to note the changes
> in the
> original creation scripts, which ultimately fall into disuse and are
> soon
> forgotten. When tables and indexes have to be regenerated, the
> panicking

That's a good point. When the scripts are not what is used to update the database, what incentive do people have to trust them? They don't. As a result, the scripts fall into disuse, the database degenerates into an adhoc collection of hacks. This is particularly a problem when you try to replicate this database structure onto another database (especially when its a different brand).

> dba searches his local disk fruitlessly for the scripts. Or the dba
> splits
> and his replacement get to go nuts trying to figure out where the
> scripts
> and everything are. Nothing uglier than a bunch of alter table
> statements
> that add/modify columns (I use alter exclusively for
> primary/foreign/unique
> key/check constraints).
> So I wrote a PL/SQL package which reverse engineers an entire schema,
> so
> the dba always has a fresh and clean script to recreate database
> objects.
> - Dan Clamage

   I applaud your use of hte PL/SQL package.

In fact, you may want to post it somewhere.

-Ron Perrella Received on Tue Oct 28 1997 - 00:00:00 CET