Why cannot I roll back ddl statements in oracle?

Why cannot I roll back ddl statements in oracle? What is a DDL statement first. DDL statements are data definition statements, including creation, modification, and deletion of various data objects, and authorization. In Oracle, DDL statements are converted into DML statements that modify the data dictionary table. A simple DDL statement for modifying a table causes Oracle to perform a large number of queries and modifications using recursive SQL statements in the background. If you are interested, use SQL _TRACE to check which operations are actually performed in the Oracle background based on the DDL statements. In Oracle, a COMMIT statement is issued before the DDL operation is executed by Oracle, and then a DDL operation is executed. As mentioned above, for Oracle, DDL is actually a series of modifications to the data dictionary table, that is, DML operations on the data dictionary table, in theory, Oracle is fully capable of implementing the rollback of DDL statements. Why is Oracle designed to work now. It is important to know that Oracle is known for its flexibility and strong customization. However, Oracle does not give users any possibility to roll back the DDL statements, and there is a very good reason for this. First, let's analyze why Oracle executes a COMMIT statement before and after DDL statements. In fact, the principle is very simple. Oracle aims to isolate the user's read/write operations from the modification of the data dictionary, user Data Reading and Writing should not be in the same transaction as data dictionary operations. To explain why Oracle does not roll back the DDL statements, let's assume that Oracle can roll back the DDL statements to see how this will affect the Oracle database. From now on, assume that DDL is not automatically committed, but a part of the transaction. DDL must meet the read commit isolation mechanism. That is to say, the DDL statements executed by the user cannot be seen by other users before submission. For example, user A executes the create table t statement and then executes some DML statements on user T. At this time, other sessions cannot see the T table. In this case, table T contains two columns, one ID column and one CREATED column. Session A executes alter table t modify created default sysdate not null, inserts some T tables, but does NOT submit them. In this case, session B tries to insert the T table. If the DDL statement is not part of the transaction, there is no conflict between the insertion of session B and the insertion of session A, but the current situation is different, because A executes the modification to the T table, the default value is added to the CREATED column and the value is not null, and the modification is NOT visible to the B session currently, because A does NOT submit the modification. If the value of the CREATED column is not provided for the insert operation of session B, the insert operation will be locked. For B, the CREATED column in the table structure can still be empty, so you can insert A record with the CREATED column as null. However, since A has set T's CREATED column to be non-empty and contains the default value, therefore, insertion of B must be locked. Otherwise, if A and B are all committed, session A will find that, even if A DDL statement is executed, there will still be A record with the CREATED blank in table T. In order to implement the DDL rollback function and implement multi-version read consistency, Oracle must lock the modified table after the DDL occurs to avoid access inconsistency between other sessions. This will cause a lock upgrade in Oracle, seriously affect the concurrency of Oracle, and greatly increase the chance of deadlock. Some people may wonder why SQL Server or some other databases can implement DDL statement rollback. As a matter of fact, Oracle is also capable of implementing DDL rollback, but this will greatly affect the concurrency of Oracle. You should know that Oracle's lock mechanism and multi-version read consistency make Oracle's concurrency second to none among all database products. Obviously, Oracle considers the loss of the most commendable concurrency to achieve DDL rollback. Other databases can be implemented because the lock mechanisms of these databases have certain defects, for example, a large number of locks occupy system resources, read/write operations are blocked, and row-level locks may be automatically upgraded to table-level locks. Because of these problems, implementing DDL rollback does not significantly degrade concurrency, even if DDL does not upgrade row locks to table locks, other factors may also cause this situation.