CREATE TABLE在存储过程中直接写会报PLS-00103错误，因Oracle编译器在解析阶段禁止DDL语句出现在PL/SQL可执行块中；必须用EXECUTE IMMEDIATE延迟到运行时执行，但该DDL仍会触发不可回滚的隐式提交。
为什么CREATE TABLE在存储过程中直接写就报PLS-00103
因为Oracle编译器在解析阶段就拒绝DDL语句出现在PL/SQL可执行块中，不是运行时报错，而是根本过不了语法检查。只要出现CREATE、DROP、ALTER等关键字，立刻抛PLS-00103错误，对象都不会生成。
根本原因在于DDL自带隐式COMMIT，而PL/SQL块默认运行在一个事务上下文里，Oracle不允许在常规执行流中插入事务边界变动操作。
- 错误写法：
CREATE PROCEDURE p AS BEGIN CREATE TABLE t (x NUMBER); END; - 正确路径：必须用
EXECUTE IMMEDIATE包裹，让DDL延迟到运行时执行 - 注意：即使用了
EXECUTE IMMEDIATE，该DDL仍会触发隐式提交，打断主事务
EXECUTE IMMEDIATE执行DDL后还能回滚吗
不能。任何通过EXECUTE IMMEDIATE执行的DDL（如CREATE TABLE、CREATE INDEX、TRUNCATE）都会立即隐式提交，且不可回滚。
常见误判场景：
- 在自治事务（
AUTONOMOUS_TRANSACTION）里执行DDL → 主事务后续ROLLBACK不影响它 - 调用
DBMS_STATS.GATHER_TABLE_STATS→ 默认cascade => TRUE可能触发索引统计收集，间接引发DDL类隐式提交 - 动态建表后立刻
INSERT再ROLLBACK→ 表结构还在，只是数据被回滚
验证方法：在事务中执行EXECUTE IMMEDIATE 'CREATE TABLE tmp_test (id NUMBER)'，然后ROLLBACK，再查USER_TABLES——表仍在。
哪些操作看似安全实则偷偷COMMIT
除了显性DDL，以下操作在Oracle 11g+中也会触发隐式提交，容易被忽略：
-
CREATE INDEX、DROP INDEX：哪怕在EXECUTE IMMEDIATE里，也立即提交 -
ANALYZE TABLE（旧方式）：已弃用但仍有遗留代码，等价于DDL级提交 -
DBMS_JOB.SUBMIT（非DBMS_SCHEDULER）：提交作业定义时隐式COMMIT - 自治事务内任意
COMMIT或DDL：主事务无法回滚其修改，且锁已释放
特别注意：TRUNCATE TABLE虽是DML语法，但行为等同DDL，同样隐式提交、不可回滚。
如何检测存储过程里有没有隐式提交点
没有内置函数能直接“扫描”出隐式提交，但可通过组合手段定位风险点：
- 搜索关键词：
CREATE、DROP、ALTER、TRUNCATE、ANALYZE、GATHER_（如GATHER_TABLE_STATS）、SUBMIT（DBMS_JOB） - 检查是否用了
PRAGMA AUTONOMOUS_TRANSACTION，并确认其内部是否有DDL或COMMIT - 在测试环境开启
SQL_TRACE或使用V$TRANSACTION视图观察事务号（XIDUSN）是否在过程中变更 - 对关键过程加
SAVEPOINT+ROLLBACK TO测试，若回滚后DDL结果仍在，说明存在隐式提交
最隐蔽的坑往往不在你写的代码里，而在调用的包过程里——比如DBMS_REDEFINITION.START_REDEF_TABLE这种重量级操作，内部全是DDL链。
