oracle存储过程编译时禁止直接使用create table等ddl语句，因其隐式提交会破坏事务一致性，必须用execute immediate在运行时动态执行。
不能直接写 create table，必须用 execute immediate 包一层，否则编译就报 pls-00103。
为什么存储过程里写 CREATE TABLE 会编译失败
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在运行时解析执行
EXECUTE IMMEDIATE 执行建表的典型结构
核心是拼出合法 SQL 字符串，并处理运行时可能的异常（比如表已存在）。注意权限、大小写、引号嵌套这些细节。
- 表名和字段名必须大写或用双引号包裹，否则
user_tables查询不到（Oracle 默认转大写） - 建表语句字符串里不能直接拼接变量，否则有 SQL 注入风险；稳妥做法是用
DBMS_ASSERT.SIMPLE_SQL_NAME校验表名 - 常见错误码：
ORA-00955（对象已存在）、ORA-01031（权限不足） - 如果过程由用户 A 创建、用户 B 调用，且 B 没有建表权限，会失败；需加
AUTHID CURRENT_USER
示例：
CREATE OR REPLACE PROCEDURE create_dynamic_table(p_table_name VARCHAR2) AUTHID CURRENT_USER AS
v_sql VARCHAR2(1000);
v_clean_name VARCHAR2(128);
BEGIN
v_clean_name := DBMS_ASSERT.SIMPLE_SQL_NAME(p_table_name);
v_sql := 'CREATE TABLE ' || v_clean_name || ' (id NUMBER, name VARCHAR2(50))';
EXECUTE IMMEDIATE v_sql;
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -955 THEN
NULL; -- 忽略“表已存在”
ELSE
RAISE;
END IF;
END;
建表后加注释、加约束等后续操作怎么写
每个 DDL 操作都要单独一条 EXECUTE IMMEDIATE，因为每条都会隐式提交，不能合并成一句。
- 注释用
COMMENT ON TABLE和COMMENT ON COLUMN，注意字符串里双引号要转义（用两个双引号） - 主键、索引、外键等约束必须用
ALTER TABLE ... ADD CONSTRAINT，不能写在CREATE TABLE语句里（除非你确定字段名、类型完全静态） - 如果要在同一事务中完成建表+插入数据，插入必须用 DML + 显式
COMMIT，但建表本身已提交，所以“建表+插入”天然跨事务
例如加注释：
v_sql := 'COMMENT ON TABLE ' || v_clean_name || ' IS ''动态生成的日志表'''; EXECUTE IMMEDIATE v_sql; <p>v_sql := 'COMMENT ON COLUMN ' || v_clean_name || '.name IS ''员工姓名'''; EXECUTE IMMEDIATE v_sql;</p>
容易被忽略的权限与自治事务场景
最常踩的坑不在语法，而在执行上下文。
- DDL 执行依赖的是存储过程所有者的权限，不是调用者——除非声明了
AUTHID CURRENT_USER - 在触发器里调用这类过程？必须加
PRAGMA AUTONOMOUS_TRANSACTION，否则报ORA-04092（trigger 中不允许 commit） - 建表语句里如果用了序列、同义词、视图等依赖对象，确保它们在运行时存在且可访问
-
EXECUTE IMMEDIATE不支持分号结尾；如果是执行匿名 PL/SQL 块，则块末尾要加分号
真正麻烦的从来不是“怎么写”，而是“谁在什么上下文里执行它”。权限、自治事务、对象可见性这三点漏掉任何一个，都可能让过程在测试环境跑通，上线就崩。
