Re: Why Oracle does not allow rollback of DDL statements?

On Nov 10, 11:06 pm, Serge Rielau <srie..._at_ca.ibm.com> wrote:

> That's the first I hear about that. Can you point to any docs explaining
> the behavior you imply? I'm also told that SQL Server (like DB2) has
> transactional DDL. Even TRUNCATE table is transactional.

Instead of reading marketing materials, try using the product. I'm stuck with having to use it, so rather than reading "tickmarks" from
a marketing "competitive" list, I aqctually have to deal with the blessed thing.

It is supposed to *be* there. However, it is so inconsistent as to make it essentially unusable.
For example: Try to drop a table that is not there - a common example of a
"oops" statement in an upgrade script. It produces an error, but does NOT
cause a rollback to take place or lock other scripts out. Now, try to select form an incorrect table name - another common example
os a "oops" statement in an u[grade script. It produces an error, and DOES
put the transaction in a suspended state that is neither rollback nor commit:
if you are running the script interactively, you then have to manually take a
decision on which way it goes.

Do a search around the forums to see what folks are using to run upgrade
scripts - the example given to "reinforce how useful it is". *NO* one recommends that transactional DDL be used. Exactly and precisely
because it is not consistent in how it handles errors and what causes an auto
or manual rollback of a transaction in error. Let's not get into logfile overheads...

Which makes it, to me, essentially the equivalent of "not there": couldn't
care less what the marketing nonsense says.

> Oracle has to sort out timing today. The only difference is that it has
> a statement level view on things rather than a transaction level view.

Yup. I can live with that. Received on Tue Nov 11 2008 - 00:37:36 CST