Re: How do you handle Database Configuration Management?
- From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- To: ryan_gaffuri@xxxxxxxxxxx
- Date: Wed, 28 Nov 2007 10:16:17 +0000
On Nov 28, 2007 4:07 AM, <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.
>
It can if you include intermediate tables to migrate the data to the new
format. There's a norwegian, now dutch, ERP package that used to use this
technique - almost certainly still does.
>
> 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.
>
This is the method I tend to see in practice. It has the clear advantage to
the software developer of focussing upgrades/fixes/new functionality in
atomic units, you are correct that it can take considerable time. If you
have the luxury of working with the DBA of the system you might well be able
to tune the scripts as appropriate.
>
> 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.
>
If you mean code branching (I can patch from 1.1 to 1.x but there is no
direct path to 2.0) then I think this also makes some sense. It tends to be
expensive for the customer because invasive fixes tend to get delayed to the
2.0 release and then that particular upgrade is riskier and requires a
greater investment in testing.
>
> 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
>
>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
