Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: How do you handle Database Configuration Management?

Re: How do you handle Database Configuration Management?

From: Finn Jorgensen <>
Date: Wed, 28 Nov 2007 10:24:51 -0500
Message-ID: <>

When I was managing the deployments of multiple development projects a couple of years back I used a Quest Software tool called Schema Manager. The idea was that you would create a baseline in the tools repository (basically what does production look like now; or in the case of a new project ready to deploy to production, what does dev/test/UAT look like now). New objects are then created in the dev db for version 1.1 etc. and when ready to deploy (to test and then later prod) a compare of the schema(s) are done between the baseline in the repository and the dev db. Changes are stored in a delta in the repository. When deploying, you basically deploy the delta.

The downside of the tool was it always seemed to be 2-3 years behind the Oracle features, so certain types of objects couldn't be deployed, but if your shop isn't too advanced it worked well enough.


PS: I'm not affiliated with Quest Software in any way.

On 11/27/07, <> wrote:
> Application Code can simply be recompiled completely when a new build is
> done. However, recompiling the database involves dropping and re-creating
> tables. This can't be done once you go live.
> Now one method is to use upgrade scripts. So you have one initial release
> of the database and simply run upgrade scripts to increment to a new
> release. This can be a problem if you have to stand up a new schema. After
> some time you can have alot of upgrades to run. This can be management with
> code, but this is run serially and could take a significant amount of time
> to take a new database to the same level.
> Another option is a mix-of upgrades and being able to re-create your
> database tables/code, etc... to the same level. So you have an upgrade
> directory to run upgrades, but you also keep DDL scripts so you can code and
> a script to build this. The problem with this is that you are alot of times
> keeping two versions of the code and to really run a test you have to test
> and maintain both copies.
> Now another option is to use a repository like designer or Erwin. We don't
> have those tools.
> So how do you handle CM for your projects? I have always found this to be
> pretty time consuming. Especially if you have multiple parallel developments
> going on.
> Version 1.1 is going out friday
> One team is working on version 1.2 which is due out in a month
> Another team is working on a different module which is in version 1.3which goes out after that
> You then have to "merge" your code. You can run into a problem where 1.1is in System Test(QA in the private sector) and then it "fails", but version
> 1.2 is in development and developers are working off of the bugged version
> of 1.1.
> btw, we are using Subversion. I have used PVCS and Rational in the past
> and have found those to be more robust tools, however, they also tend to
> require administrators to keep them running.
> --

Received on Wed Nov 28 2007 - 09:24:51 CST

Original text of this message