Re: How do you handle Database Configuration Management?
- From: "Finn Jorgensen" <finn.oracledba@xxxxxxxxx>
- To: ryan_gaffuri@xxxxxxxxxxx
- Date: Wed, 28 Nov 2007 10:24:51 -0500
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.
HTH
Finn
PS: I'm not affiliated with Quest Software in any way.
On 11/27/07, ryan_gaffuri@xxxxxxxxxxx <ryan_gaffuri@xxxxxxxxxxx> 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.
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
