Re:How to CM Oracle DB (DBAs input requested)

From: Mark <mso_at_doubled.com>
Date: 1997/10/25
Message-ID: <mso-2510971942000001_at_m188.doubled.com>#1/1


[Quoted] groups added:comp.software-eng, comp.databases, comp.databases.oracle.misc,

             comp.databases.oracle.tools

[Quoted] In article <m3oh4d6h3b.fsf_at_biff.bitsko.slc.ut.us>, Ken MacLeod <ken_at_bitsko.slc.ut.us> wrote:

_at_ Mark <mso_at_doubled.com> writes:
_at_
_at_ > . . . This project uses an Oracle DB and uses
_at_ > Oracle financials. Oracle Designer2000 and Developer2000 are used to
_at_ > work on/develop the DB.
_at_ > . . .
_at_ > 1) The politial issue is that the DBA and Oracle developers feel all CM
_at_ > should be concerned with is keeping track of the DB patches (which they
_at_ > maintain themselves in their environment).
_at_ > . . .
_at_ > 2) The functional issue is that I do not know how to CM a DB. I cannot
_at_ > find any resourses that describe how a database should be CM'd.
_at_ > . . .
_at_ > Does anyone know of any resourses I can refer to or can anyone provide
_at_ > any type of help or suggestion regarding CM of databases?
_at_
_at_ Unfortunately, not much. I've been at the same point on a few
_at_ occasions now and unless your modelling and implementation tools
_at_ support automated CM directly you're SOL, on *both* issues :-(.

Thank you for your input, I may not of understood your response completely or I may not have been clear on what I was looking for. Let me ask a few questions and hopefully clear things up. Basically, I am not looking for the how's and why's of Oracle DB creation/configuration/maintenance, but the what's-- what is used to do it and how can it be CM'd.

  1. Once a generic Oracle (7.x.x) database is installed in one environment for a project (say development), can it be configured/setup by using files containing configuration info or instructions, like SQL scripts? Can the DB then be maintained/changed using the same?
  2. If so, are SQL scripts the only way, or do other tools such as [Quoted] Developer/Designer produce files that are then are "run" on the database to configure it and maintain it? [Quoted]
  3. If I understand things correctly, the answer to both of the above is yes. If I am wrong or the answer is not that simple, please explain.
  4. Now this question comes as a result of discussions with our DBA. I have reservations about her answer (along with her answers to the ones above). If these files are written/made properly, can they be used to configure/maintain a database with the same configuration in other environments for the same project (say system test and production)?
  5. Again, if I understand things correctly, the answer is yes. If I am wrong or the answer is not that simple please explain.

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

[Quoted] The tool we have is PCVS, I am not too familiar with it. But from the little I have learned, what the company saved in license/purchase cost they will more than lose in person-hours -- I miss ClearCase. Hopefully, as I learn more about PVCS it won't look as bad.

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

[Quoted] Does it produce a "blueprint" snapshot of the database structure? I am interested in finding a tool or procedure where the database structure can be retrieved and baselined, then periodicly thereafter obtain new snapshots of the database. Then use the "blueprint" snapshots to see what/if something has changed in the database structure. The primary goal being is to be able to show/verify that the database structure has not changed between snapshots and secondly, possibly show/verify that changes made are consistant with CCB/Release Notes.

_at_ --
_at_ Ken MacLeod
_at_ ken_at_bitsko.slc.ut.us

Thanks,

Mark
mso_at_doubled.com Received on Sat Oct 25 1997 - 00:00:00 CEST

Original text of this message