DBMS_SQL.PARSE报ORA-00900主因是动态SQL字符串拼接错误，如未转义换行、绑定变量格式错误（须为:v_name）、单引号未双写、第三个参数未显式指定DBMS_SQL.NATIVE。
DBMS_SQL.PARSE 为什么总报 ORA-00900 错误
动态 sql 字符串里混入了未转义的换行、多余空格或绑定变量写法错误，dbms_sql.parse 就会直接拒绝解析，不是语法真错，而是字符串没拼对。
- 拼接 SQL 时用
REPLACE(sql_str, CHR(10), ' ')清掉换行，别依赖编辑器缩进 - 所有绑定变量必须写成
:v_name形式，不能是&v_name或${v_name}（后者是 SQL*Plus 或外部脚本逻辑） - 如果 SQL 含单引号，用两个单引号转义：
'WHERE name = ''' || p_name || ''''，漏一个就变语法错误 -
DBMS_SQL.PARSE的第三个参数必须明确写DBMS_SQL.NATIVE，写2或省略在某些 Oracle 版本会触发非预期行为
如何安全获取动态查询的列元数据
不查 DBMS_SQL.DESCRIBE_COLUMNS，FETCH_ROWS 之前根本不知道字段名和类型，硬写 DEFINE_COLUMN 必然崩。
- 调用
DBMS_SQL.DESCRIBE_COLUMNS后，必须遍历desc_tab数组，逐个调用DEFINE_COLUMN，不能只定义前 5 列就假设后面一样 - 列类型为
VARCHAR2时，DEFINE_COLUMN第三个参数必须传足够长度（比如 4000），传 1 会导致截断且无警告 - 如果查询含表达式（如
UPPER(name) as u_name），desc_tab(i).col_name可能为空，得 fallback 到desc_tab(i).col_alias - Oracle 12c+ 支持
DBMS_SQL.DESCRIPTOR，但兼容性差，老环境坚持用DESCRIBE_COLUMNS更稳
DBMS_SQL.EXECUTE 和 FETCH_ROWS 的顺序陷阱
很多人以为 EXECUTE 后立刻 FETCH_ROWS 就行，结果返回 0 行——其实没重置游标状态，或者没处理多结果集场景。
-
EXECUTE返回的是语句执行状态（成功/失败），不是行数；真正取数必须靠循环调用FETCH_ROWS - 每次
FETCH_ROWS前要检查返回值：0 表示没更多行，负数才是错误（如 -100 是 no_data_found，但这里不是异常，是正常结束信号） - 如果动态 SQL 是 PL/SQL 块（含 BEGIN...END），
EXECUTE执行完就结束了，不能后续FETCH_ROWS—— 这类必须用OPEN...FOR+ 动态 ref cursor - 批量 fetch 时别设太大（如 10000），内存压力陡增；200–500 是较安全的默认值
绑定变量类型不匹配导致隐式转换失败
DBMS_SQL.BIND_VARIABLE 对类型极其敏感，VARCHAR2 绑给数字字段，或 DATE 绑给字符串字段，Oracle 不自动转，直接报 ORA-06502。
- 绑定前务必确认目标字段类型：查
USER_TAB_COLUMNS或用DESCRIBE_COLUMNS获取col_type值（12=DATE, 2=NUMBER, 1=VARCHAR2） - 数字类型统一用
TO_NUMBER()显式转，别信输入参数“看起来像数字” - 日期类型必须用
TO_DATE(p_date_str, 'YYYY-MM-DD HH24:MI:SS')，格式不匹配比类型不匹配更难排查 - NULL 值绑定要单独处理：用
DBMS_SQL.BIND_VARIABLE_NULL，而不是传空字符串或 0
动态游标真正的复杂点不在语法，而在每一步都要手动校验中间状态——没有自动类型推导，没有运行时列名补全，连 fetch 结束都得自己判返回值。漏掉任意一环，错误就藏在看似成功的返回码里。
