dbms_sql.parse可验证语法而不执行，解析通过即视为合法，但仅抛异常不返回详情；需用open_cursor+parse+close_cursor封装check_syntax函数，并捕获异常确保游标安全关闭。
dbms_sql.parse 是唯一能真正“解析但不执行”的入口，但它不返回语法错误详情，只抛异常。
DBMS_SQL.PARSE 能否验证语法而不执行？
可以，但仅限于“解析通过即视为语法合法”。DBMS_SQL.PARSE 会触发 Oracle 的硬解析流程：校验对象存在性、权限、语义合法性（如列名是否属于表）、语法结构。它不会真正运行 SQL，也不会访问数据，所以 DML/DDL 不会生效，SELECT 也不会返回结果。
常见误判点：
- 表名或列名拼写错误 → 抛
ORA-00942或ORA-00904，PARSE失败 - 绑定变量未声明或类型不匹配 → 抛
ORA-01008或ORA-06502，必须在PARSE前确保占位符格式统一（如:var） - 使用了当前用户无权限的对象 → 抛
ORA-00942，即使该对象物理存在
注意：PARSE 对 DDL（如 CREATE TABLE）同样有效，但要求调用者已显式被授予对应系统权限（如 CREATE TABLE），否则直接失败。
如何封装一个安全的语法检查函数？
核心是捕获异常并统一返回码，同时强制关闭游标——漏掉 DBMS_SQL.CLOSE_CURSOR 会导致游标泄漏，严重时耗尽 open_cursors 参数上限。
推荐写法：
FUNCTION check_syntax (p_query IN CLOB) RETURN INTEGER IS
l_cursor NUMBER;
BEGIN
l_cursor := DBMS_SQL.OPEN_CURSOR;
DBMS_SQL.PARSE(l_cursor, p_query, DBMS_SQL.NATIVE);
DBMS_SQL.CLOSE_CURSOR(l_cursor);
RETURN 0; -- success
EXCEPTION
WHEN OTHERS THEN
IF DBMS_SQL.IS_OPEN(l_cursor) THEN
DBMS_SQL.CLOSE_CURSOR(l_cursor);
END IF;
RETURN -1; -- parse failed
END;
关键细节：
- 输入用
CLOB而非VARCHAR2，避免长 SQL 截断（尤其含注释或大文本时） - 必须用
DBMS_SQL.IS_OPEN判断再关游标，不能无条件CLOSE_CURSOR（可能报ORA-01001） - 不要试图从
SQLERRM提取具体错误类型——不同版本 Oracle 返回信息不一致，不可靠
为什么不用 EXECUTE IMMEDIATE 来验证？
EXECUTE IMMEDIATE 无法分离“解析”和“执行”阶段。它对 DML/DDL 会真实执行（哪怕加了 WHERE 1=0），对 SELECT 则必须定义接收变量或用 BULK COLLECT，且一旦解析失败就直接抛异常，没有中间态供你干预。
典型陷阱：
-
EXECUTE IMMEDIATE 'SELECT * FROM nonexistant_table' INTO ...→ 直接报错退出，无法捕获“只是语法/对象问题” -
EXECUTE IMMEDIATE 'CREATE TABLE t(x INT)'→ 表真被建出来了，不是“验证”而是“执行” - 想验证带绑定变量的语句时，
EXECUTE IMMEDIATE要求你提供实际值，而PARSE只需语句本身
动态 SQL 解析后还能不能改语句？
不能。DBMS_SQL.PARSE 是一次性操作：游标状态锁定为该 SQL 文本。后续调用 DBMS_SQL.BIND_VARIABLE 或 DBMS_SQL.EXECUTE 都基于已解析的语句结构。若要换 SQL，必须 CLOSE_CURSOR 后重新 OPEN_CURSOR + PARSE。
这意味着：
- 无法复用同一个游标 ID 执行多条不同结构的 SQL
- 如果要批量验证多个语句，每个都得独立开游标、解析、关游标——别省那一步
CLOSE_CURSOR - 游标 ID 是会话级资源，跨 PL/SQL 块传递需显式
OUT参数，不推荐；应保持“开–用–关”在同一个作用域内
最易被忽略的一点：Oracle 不会缓存 DBMS_SQL 解析结果，每次 PARSE 都是硬解析。高频调用时，性能开销比 EXECUTE IMMEDIATE 显著更高——验证只用于开发期或低频管理场景，别放进高并发循环里。
