Re: Why Oracle does not allow rollback of DDL statements?
From: Shakespeare <whatsin_at_xs4all.nl>
Date: Mon, 10 Nov 2008 12:03:16 +0100
Message-ID: <491814f3$0$194$e4fe514c@news.xs4all.nl>
>
> OK, that would make things even worse, because you would have "local"
> objects, visible only from the creating session. There would be no way
> to meaningfully monitor the system and explain SQL as the "noncommitted"
> table would not exist from the perspective of any other user.
>
Date: Mon, 10 Nov 2008 12:03:16 +0100
Message-ID: <491814f3$0$194$e4fe514c@news.xs4all.nl>
Mladen Gogala schreef:
> On Mon, 10 Nov 2008 10:34:53 +0100, Shakespeare wrote:
>
>> Mladen Gogala schreef: >>> On Mon, 10 Nov 2008 10:02:08 +0100, Thomas Kellerer wrote: >>> >>>> But creating objects in a database needs to be consistent as well. I >>>> don't see why having transactional DDL contradicts database >>>> consistency. >>>> >>>> Actually I think it adds to consistency. >>> So, I create table, Noons creates an index to that table, in his own >>> schema. If I was able to roll back the table creation, what happens to >>> Nuno's index? Flashback table to before drop is possible with all >>> releases that support flashback area, since the version 7.3.6. >>> >>> >> Of course, Noons could only create the index AFTER you commit your DDL! >> So no roll back would be possible anymore. >> >> Shakespeare
>
> OK, that would make things even worse, because you would have "local"
> objects, visible only from the creating session. There would be no way
> to meaningfully monitor the system and explain SQL as the "noncommitted"
> table would not exist from the perspective of any other user.
>
Indeed. I wasn't saying it would be any better.... or any good at all. But isn't this the case with all uncomitted transactions? What about two users creating the same table(s) with a delayed commit? And what about DROP TABLE statements? Should they be roll backed as well?????
Shakespeare Received on Mon Nov 10 2008 - 05:03:16 CST