Re: How to CM an Oracle DB

Mark <mso_at_doubled.com> writes:

> I have been doing CM for over a year now. Recently, I have been put on a
> new project as the CM Manager. This project uses an Oracle DB and uses
> Oracle financials. Oracle Designer2000 and Developer2000 are used to
> work on/develop the DB.
>
> I have encountered two issues regarding the above:
>
> 1) The politial issue is that the DBA and Oracle developers feel all CM
> should be concerned with is keeping track of the DB patches (which they
> maintain themselves in their environment). This scope of CM is not
> anywhere close to being acceptable. If CM is to manage (and be
> responsible for) the configuration of the system (in system test and in
> production), the database needs to be CM'd just like everything else,
> especially since its the heart of the system.
>
> 2) The functional issue is that I do not know how to CM a DB. I cannot
> find any resourses that describe how a database should be CM'd. The
> books I have go into painful detail about SCM, but don't mention
> anything about databases.
>
> Does anyone know of any resourses I can refer to or can anyone provide
> any type of help or suggestion regarding CM of databases?

Unfortunately, not much. I've been at the same point on a few occasions now and unless your modelling and implementation tools support automated CM directly you're SOL, on *both* issues :-(.

Platinum Enterprise and Desktop were chosen for administration on my current project. As far as I can tell, Platinum simply makes changes quick and easy, and oops we forgot the management part.

I've never been in the position to choose commercial tools, so I don't have a list of any that support CM, but I'm aware that many do, especially those that run on Unix.

If you're on a project that is comfortable with ``tool builders'', I've had and have heard of great success using simple flat file schemas with [generally Perl] scripts to implement them and load procedures. If you're more heavily into iterative development you can use state files and such to minimize build time. You can pull out DB size and naming to use multiple private workareas. Having Perl access to the schema gives you an opportunity to more easily maintain a large test data set between schema changes -- I've found that to be a very big selling point for this technique.

The tool building approach is a good candidate for any ``project'' based tool (i.e. like CVS but not like SCCS or RCS).

The last time I ran into this brick wall I started designing another tool along these lines and I do have a skeleton of it if you want, including a script that reads an Oracle export file to create the initial baseline or to do checking.

-- 
  Ken MacLeod
  ken_at_bitsko.slc.ut.us