>> The following list contains the steps necessary when upgrading a
>> production database:
> That is a bold assertion.

I'm sorry. Here's a rewrite :
...
The following list contains the steps I'm currently taking to
upgrade a production database:
...
Is that better ? :)

> 1) Make sure no-one is using it, rename the database to prove it.
> 2) Take a file copy of the database just in case. (The server can't
> see the file because it is renamed so it can be safely copied).
> 3) Run your upgrade DDL.

Our 'internal' development version is constantly being modified/messed
around with. The argument was that at some point it's probably easier to
just provide a shiny new 'guaranteed to be working' database (plus
client app) instead of trying to maintain a 'delta DDL'.

> 4) Run a backup of the 'upgraded' database with -g option.
> 5) Restore the backup file from step 4 (rebalances everything)
> 6) Rename the restored database in 5 so the alias points to it again.
> 7) Finished
> *snip*

Understood. Thanks for sharing.

Regards,
t.s.