是，必须显式声明只读。Oracle 19c ADG备库要求存储过程通过READS SQL DATA等PRAGMA明确标识只读性，否则即使仅含SELECT也会因无法静态确认只读性而报ORA-16000；自治事务、隐式写操作（如DBMS_APPLICATION_INFO）及未授权对象访问均被禁止。
只读事务在 ADG 备库上执行失败，是不是没加 READ ONLY 修饰？
不是所有“只读”操作都会被备库接受。Oracle 19c 在 Active Data Guard（ADG）环境下，SELECT 语句默认可在备库执行，但存储过程若隐含写行为（比如调用 DBMS_OUTPUT.PUT_LINE、访问未授权视图、或内部触发自治事务），仍可能报错 ORA-16000: database open for read-only access。关键不是“看起来只读”，而是 Oracle 是否能静态确认其只读性。
必须显式声明存储过程为只读，否则即使内容全是 SELECT，也可能被拒绝执行。这是最常被忽略的一步。
- 使用
READS SQL DATA显式声明：仅读取数据，不修改 - 避免任何可能触发 DML 的逻辑，包括
INSERT INTO ... SELECT、CREATE GLOBAL TEMPORARY TABLE（即使临时表也不行）、DBMS_SCHEDULER.CREATE_JOB等 - 不要在过程中调用未标记只读的自定义函数——它们会污染整个调用链
- 验证方式：
SELECT OBJECT_NAME, STATUS, AUTHID FROM USER_PROCEDURES WHERE PROCEDURE_NAME = 'YOUR_PROC';，确认状态为VALID且无隐式权限升级
为什么在备库执行 PRAGMA AUTONOMOUS_TRANSACTION 会直接报错？
自治事务本质上是“嵌套的独立事务”，它需要自己的事务控制（COMMIT/ROLLBACK），而物理备库处于 READ ONLY WITH APPLY 模式，禁止任何本地事务提交。哪怕你只是想往一张日志表里插一条记录，PRAGMA AUTONOMOUS_TRANSACTION 也会让 Oracle 认为该过程具备写能力，从而拒绝加载或执行。
- ADG 备库不允许任何本地事务生命周期管理，
AUTONOMOUS_TRANSACTION是硬性禁用项 - 替代方案：改用主库专用连接（如通过
DBMS_SCHEDULER或应用层路由），或把日志写入外部系统（如 UTL_HTTP 发送到日志服务） - 注意
DBMS_APPLICATION_INFO.SET_MODULE这类“看似只读”的过程，实际会更新V$SESSION，也属于隐式写操作，同样不可用
ADG_REDIRECT_DML = TRUE 开了，但存储过程里的 DML 还是报错，问题出在哪？
DML 重定向只对**直接执行的 DML 语句**生效，不自动穿透到存储过程内部。也就是说，你在备库 EXEC my_proc，即使过程体里有 UPDATE，也不会被重定向——Oracle 会直接拒绝编译或运行该过程，因为过程定义本身已违反只读约束。
- 过程必须在主库创建并编译（通过 Redo 同步到备库），且不能包含任何 DML 语句
- 如果真需要“备库可写”，只能把 DML 拆出来，由应用层在备库显式发起（如
INSERT /*+ ADG_REDIRECT */ INTO ...），再由过程处理返回结果 - 参数
ADG_REDIRECT_DML对 PL/SQL 块中的 DML 无效，只作用于顶层 SQL 语句 - 检查是否误用了
FOR UPDATE：即使没UPDATE，带FOR UPDATE的游标在备库也会报ORA-16000
如何确保只读存储过程在主备切换后仍可用？
主备角色切换后，原备库变为主库，原主库变为备库。如果你的过程依赖特定数据库角色（比如查 V$DATABASE.DATABASE_ROLE 判断当前是主还是备），就可能出错——因为过程代码没变，但执行环境变了。
- 避免在过程中硬编码角色判断逻辑；如需差异化行为，应由应用传入上下文参数
- 所有对象（表、视图、同义词）必须在主备库中完全一致，包括权限和统计信息；否则备库执行时可能因对象不存在或权限不足而失败
- 特别注意
SYSDATE和SYSTIMESTAMP：它们在主备库上值不同，若过程逻辑依赖时间差（如“过去5分钟的数据”），切换后行为会漂移 - 测试必须覆盖 Switchover 场景：手动执行一次
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY，再验证过程是否仍可执行
