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

From: ddf <>
Date: Wed, 12 Nov 2008 13:44:23 -0800 (PST)
Message-ID: <>

Comments embedded.

On Nov 12, 2:35 pm, wrote:
> On Nov 12, 2:38 pm, DA Morgan <> wrote:
> > wrote:
> > > Dbms_redef appears only for redefining tables. Its purpose is on-line
> > > redefinition of tables. It has too much overhead: requires lots of
> > > additional storage depending on size of your tables.
> > Incorrect. Look at the demo in Morgan's Library. You can change
> > constraints, triggers, etc.
> > > I doubt Oracle will provide transaction based ddl because of its
> > > architecture and all exiting base of code; however, this does not mean
> > > that this feature is not useful.
> > A bottle of scotch can be useful. But I generally don't carry one
> > with me while driving a car. I would make the same argument with
> > respect to production databases. It might be nice to have in dev
> > but anyone using it in test or prod should be shown the door.
> > --
> > Daniel A. Morgan
> > Oracle Ace Director & Instructor
> > University of Washington
> > (replace x with u to respond)
> > Puget Sound Oracle Users
> It seems you are drunk in Oracle Scotch that you have lost objectivity
> to anything else.

Not necessarily.

> It is shame that you are a University Professor.

I disagree. In my mind it's a shame you're behaving in such a manner.

> Profressors should have broader midset instead of being salesman for a
> company.

When did Daniel try to sell you anything?

> No one can doubt your knowledge of Oracle, but at the same
> everyone in this forum knows you lack objectivity.

This IS an Oracle forum ... have you forgotten that?

> When one database dominates, innovations stop.- Hide quoted text -

Yet I haven't witnessed that in over 20 years in the arena. You're welcome to prove otherwise.

> - Show quoted text -

As I see it differences make the world an interesting place, and there are plenty of them in this thread.

Any 'good' feature of a database is open to misuse and abuse, regardless of the intent of the developers of the database code. I agree with Laurenz that transactional DDL can be beneficial when used to upgrade applications during a scheduled outage as all changes will be successfully applied or they'll all be rolled back. No 'piecemeal' modifications to code/objects that would need to be 'sifted through' to find where to restart the process.

Then, I also agree with Daniel and Joel as anyone using transactional DDL on a live production system, in the middle of a work day when everyone and his cat is 'hitting' the database, should be considered a fool. Yet, to implement transactional DDL for the first purpose opens the floodgates for those with more 'horse' than 'sense' to do the latter; it's a double-edged sword.

I'm used to Oracle and its ways (after over 20 years in the trenches) and would not have thought of implementing transactional DDL in a database. Certainly there are good reasons to have it (Laurenz listed a very good one) just as there are good reasons to *not* have it. I tend to weigh in on the 'it's not broken, so why fix it' side; I don't want to have the need to ride herd on developers, programmers or (gasp) end users creating DDL nightmares waiting to be committed in a running production system. But, we're all different, and it would be a terribly boring place if we weren't.

It's an interesting discussion, and I side with the currently implemented DDL mechanisms Oracle provides. Others don't, and that makes for a lively interchange of ideas. Just remember this is a technical forum, not a pulpit. You can believe anything you want, and I'll respect your right to believe it, as long as you don't try to convert me in the process.

David Fitzjarrell Received on Wed Nov 12 2008 - 15:44:23 CST

Original text of this message