How to script schema upgrade as single success unit

Question

We currently use a combination of Ingres and SQL Server databases. When upgrading a schema of our own design we will script the upgrade as a single success unit. If any part fails then the whole lot is rolled back. (This is a slight simplification but it's the general principle we follow). However in Oracle I believe DDL statements are automatically committed. This is thwarting our attempts to adopt the same approach with Oracle.
As a simple example say a column is being moved from one table to another (for whatever reason). The application changes to be implemented depend on three things happening:
1. table_new has column_new added to it
2. column_new on table_new is populated from column_old on table_old
3. table_old has column_old dropped from it
so the upgrade script will run something like:
Start Transaction
alter table table_new add column_new(etc... ;
update table_new set column_new = (select column_old from table_old etc.... ;
alter table_old drop column_old ;
If Error then
Rollback
Else
Commit Transaction
This way if there is an error then the database is left in a state that works with the old application code. If the upgrade succeeds then the new application code can implemented.
So my questions are:
1. Am I correct in thinking that in Oracle, step 1 above will commit as soon as it's submitted preventing rollback?
2. If so then what would people recommend as a way to achieve a single success unit for a schema upgrade?
We were hoping to use flashback with restore points to perform the equivalent of a rollback if there were any errors in the upgrade script. Having tried that this afternoon though, I received an error about being unable to flashback the table because it had been changed (don't have the error here I'm afraid as I'm at home now). Would restoring the tablespace (we are setting up one tablespace per schema) to a point in time before the upgrade script started be reasonable? It seems a little extreme and also considerably more difficult to script than the flashback option. Otherwise I'm thinking that some combination of creating a new table, populating it, dropping the old table, renaming the new table with the original name might be an option. However this obviously has much greater overheads, higher chance of error and considerably more messing about if constraints, rules and procedures are involved.
Any suggestions or corrections on what I've added above are appreciated.
thanks
Mark

Answer 1

Thanks for the responses.
Unfortunately this will always be a case of altering the schema rather than creating it once applications are running against Oracle.
Tablespace point in time recovery is probably looking like the best option so far. A script would only ever upgrade one schema at a time and we're setting things up to use one tablespace per schema.
Proving and then rehearsing a TSPITR (as I believe it's called) is on the list of things that we need to do but it seems like it may be needed as a more routine tool than just in emergencies. I shall concentrate my reading in that direction. Would anybody care to offer any opinions on automating restores for this situation? We have people on call but generally only plan to come in out of hours to check the outcome of big upgrades. Smaller schema upgrades are left to pass or rollback overnight.
It's a real shame that flashback works at the database and table levels but does not have a tablespace option as that would be perfect. Flashing back the whole database could be problematic as we will probably end up with multiple schemas in each database, each one being used by different applications so we could realistically have applications running against some schema_a whilst we're upgrading schema_b. Flashing back the whole database would obviously then cause problems in schema_a, or schema_a or the associated application would have to be suspended while we upgraded schema_b. Whilst we're lucky enough to have some downtime with most of our applications, this is gradually disappearing and there are some which are now approaching 24/7 availability.
I'm still open to other suggestions though. This seems so much more complicated than the approach which has worked for Ingres and SS. Do you apply schema changes whilst the system is running? Does somebody do this manually or is it scheduled?
thanks again
Mark