DDL语句在EXECUTE IMMEDIATE中会隐式提交且不可回滚：执行前先提交当前未提交的DML，再执行DDL并再次提交；即使DDL失败，首次提交仍生效，导致事务边界断裂。
DDL语句在EXECUTE IMMEDIATE中会隐式提交，且不可回滚
Oracle对DDL（如 CREATE、DROP、TRUNCATE）的处理机制和DML完全不同：只要 EXECUTE IMMEDIATE 成功执行一条DDL语句，Oracle就会在语句前后各做一次 COMMIT —— 第一次把当前未提交的DML事务提交掉，第二次才提交DDL本身。这意味着：
- 即使你刚在存储过程中执行了
INSERT但还没COMMIT，紧接着用EXECUTE IMMEDIATE 'CREATE TABLE ...'，前面那批插入数据就立刻落库、无法ROLLBACK - DDL执行失败（比如表已存在），第一次隐式
COMMIT仍会发生，导致前面的DML“被连带提交” - 整个过程不依赖调用方是否显式提交，也不受存储过程异常退出影响——DDL一跑，事务就断了
动态SQL中DDL与DML混用时，事务边界会被意外截断
常见错误场景是：想在一个逻辑单元里先改数据、再建索引或分区。例如：
EXECUTE IMMEDIATE 'UPDATE orders SET status = ''PROCESSED'' WHERE id IN (SELECT id FROM temp_ids)'; -- 这里没 COMMIT EXECUTE IMMEDIATE 'CREATE INDEX idx_orders_status ON orders(status)'; -- 隐式提交上面的 UPDATE
结果是：索引建完，UPDATE 也生效了，但你本意可能是“全成功才提交，任一失败就回滚”。这种写法实际把事务拆成了两段，中间无回滚支点。
- 避免混用：DDL前确保所有DML已
COMMIT或ROLLBACK，不要依赖“后面再统一提交” - 若必须原子化，改用
DBMS_SQL包（不推荐）或拆成两个独立步骤 + 外部事务控制 - 测试时注意：PL/SQL Developer 或 SQL*Plus 正常退出也会触发隐式提交，掩盖问题
存储过程中直接写DDL语法不合法，必须走EXECUTE IMMEDIATE字符串
Oracle编译器在解析存储过程时，会拒绝任何裸DDL语句（如 CREATE TABLE），报错 PLS-00103。所以必须用字符串包裹后交给 EXECUTE IMMEDIATE 执行——但这只是绕过编译检查，不改变其运行时的事务行为。
- 错误写法：
CREATE TABLE t (id NUMBER);→ 编译失败 - 正确写法：
EXECUTE IMMEDIATE 'CREATE TABLE t (id NUMBER)';→ 编译通过，但立即触发双COMMIT - 权限注意：存储过程执行DDL，需要调用者拥有对应对象权限，且不能仅靠定义者权限（
DEFINER'S RIGHT）绕过
最易被忽略的一点：隐式提交不是“DDL成功才发生”，而是“DDL开始执行前就已提交前置事务”。哪怕 EXECUTE IMMEDIATE 报错退出，前面的DML早已不可逆。
