Why there is implicit commit before and after executing DDL Statements

Question

Hi Guys,
Please let me know why there is implicit commit before and after executing DDL Statements ?
Regards,
sushmita

Answer 1

Helyos wrote:
This is because Oracle has design it like this.Come on Helyos, that's a bit of a weak answer. :)
The reason is that it makes no sense to update the structure of the database whilst there is outstanding data updates that have not been committed.
Imagine having a column that is VARCHAR2(50) that currently only has data that is up to 20 characters in size.
Someone (person A) decides that it would make sense to alter the table and reduce the size of the column to varchar2(20) instead.
Before they do that, someone else (person B) has inserted data that is 30 characters in size, but not yet committed it.
As far as person B is concerned that insert statement has been successful as they received no error, and they are continuing on with their process until they reach a suitable point to commit.
Person A then attempts to alter the database to make it varchar2(20).
If the database allowed that to happen then the column would be varchar2(20) and the uncommitted data would no longer fit, even though the insert was successful. When is Person B going to find out about this? It would be wrong to tell them when they try and commit, because all their transactions were successful, so why should a commit fail.
In this case, because it's two different people, then the database will recognise there is uncommitted transactions on that table and not let person B alter it.
If it was just one person doing both things in the same session, then the data would be automatically committed, the alter statement executed and the person informed that they can't alter the database because there is (now) data exceeding the size they want to set it to.
It makes perfect sense to have the database in a data consistent state before any alterations are made to it, hence why a commit is issued beforehand.
Here's something I wrote the other day on the subject...
DDL's issue a commit before carrying out the actual action
As long as the DDL is syntactically ok (i.e. the parser is happy with it) then the commit is issued, even if the actual DDL cannot be executed for another reason.
Example...
We have a table with some data in it...
SQL> create table xtest as select rownum rn from dual;
Table created.
SQL> select * from xtest;
        RN
         1We then delete the data but don't commit (demonstrated by the fact we can roll it back)
SQL> delete from xtest;
1 row deleted.
SQL> select * from xtest;
no rows selected
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
        RN
         1
SQL> delete from xtest;
1 row deleted.
SQL> select * from xtest;
no rows selectedSo now our data is deleted, but not committed, what if we issue a DDL that is syntactically incorrect...
SQL> alter tab xtest blah;
alter tab xtest blah
ERROR at line 1:
ORA-00940: invalid ALTER command
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
        RN
         1... the data can still be rolled back. This is because the parser was not happy with the syntax of the DDL statement.
So let's delete the data again, without committing it, and issue a DDL that is syntactically correct, but cannot execute for another reason (i.e. the database object it refers to doesn't exist)...
SQL> delete from xtest;
1 row deleted.
SQL> select * from xtest;
no rows selected
SQL> truncate table bob;
truncate table bob
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
no rows selectedSo, there we have it. Just because the statement was syntactically correct, the deletion of the data was committed, even though the DDL couldn't be performed.
This makes sense really, because if we are planning on altering the definition of the database where the data is stored, it can only really take place if the database is in a state where the data is where it should be rather than being in limbo. For example, imagine the confusion if you updated some data on a column and then altered that columns datatype to be a different size e.g. reducing a varchar2 column from 50 character down to 20 characters. If you had data that you'd just updated to larger than 20 characters whereas previously there wasn't, then the alter table command would not know about it, would alter the column size and then the data wouldn't be valid to fit whereas the update statement at the time didn't fail.
Example...
We have a table that only allows 20 characters in a column. If we try and insert more into that column we get an error for our insert statement as expected...
SQL> create table xtest (x varchar2(20));
Table created.
SQL> insert into xtest values ('012345678901234567890123456789');
insert into xtest values ('012345678901234567890123456789')
ERROR at line 1:
ORA-12899: value too large for column "SCOTT"."XTEST"."X" (actual: 30, maximum: 20)Now if our table allowed more characters our insert statement is successful. As far as our "application" goes we believe, nay, we have been told by the database, we have successfully inserted our data...
SQL> alter table xtest modify (x varchar2(50));
Table altered.
SQL> insert into xtest values ('012345678901234567890123456789');
1 row created.Now if we tried to alter our database column back to 20 characters and it didn't automatically commit the data beforehand then it would be happy to alter the column, but then when the data was committed it wouldn't fit. However the database has already told us that the data was inserted, so it can't go back on that now.
Instead we can see that the data is committed first because the alter command returns an error telling us that the data in the table is too big, and also we cannot rollback the insert after the attempted alter statement...
SQL> alter table xtest modify (x varchar2(20));
alter table xtest modify (x varchar2(20))
ERROR at line 1:
ORA-01441: cannot decrease column length because some value is too big
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
X
012345678901234567890123456789
SQL>Obviously, because a commit statement is for the existing session, if we had tried to alter the table column from another session we would have got
SQL> alter table xtest modify (x varchar2(20));
alter table xtest modify (x varchar2(20))
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
SQL>... which is basically saying that we can't alter the table because someone else is using it and they haven't committed their data yet.
Once the other session has committed the data we get the expected error...
ORA-01441: cannot decrease column length because some value is too bigHope that explains it