adg备库因只读限制无法执行select seq.nextval，会报ora-16000错误；序列值生成需更新seq$表，属dml操作，adg禁止任何dml；替代方案是主库建cache+noorder序列，应用层批量取号并容错处理。
sequence_global 在 adg 上不可用，会报 ora-16000 错误
adg（active data guard）的备库默认只读，所有修改型操作都会被拦截。sequence_global 并不是 oracle 官方术语，但常被误用来指代“在主库创建、期望在备库也能正常 nextval”的全局序列。实际只要备库没开读写（即仍是 adg 模式），任何尝试修改序列状态的操作——包括 select seq.nextval from dual ——都会触发 ora-16000: database open for read-only access。
这是因为序列值生成本质是更新数据字典（SEQ$ 表），属于 DML，而 ADG 备库禁止任何 DML。
- 主库上执行
SELECT s.NEXTVAL FROM DUAL正常，值写入SEQ$ - 同一语句在 ADG 备库执行 → 立即报
ORA-16000 - 哪怕序列是
NOORDER NOCACHE，也无法绕过该限制 -
SESSION级别序列（如用CREATE SEQUENCE ... SESSION）并不存在；Oracle 不支持SESSION关键字创建序列，这是常见误解
真正可用的替代方案：CACHE + NOORDER 序列 + 应用层容错
想让应用在主备两端都能获取唯一值，不能依赖序列直连，必须换思路：把序列当作“主库专用号段生成器”，由应用协调使用。
- 主库建序列时务必加
CACHE 1000（或更大），减少对SEQ$的频繁更新压力 - 避免
ORDER：它强制序列按请求顺序生成，会严重拖慢 RAC 或高并发场景，ADG 下更无意义 - 应用每次从主库批量取一段号（例如
SELECT s.NEXTVAL FROM DUAL CONNECT BY LEVEL ），缓存在内存中分发 - 备库不参与序列生成，只读查询时若需“类序列值”，改用
SYS_GUID()、DBMS_RANDOM.STRING或时间戳+主机ID等无状态方式
示例伪代码：
DECLARE<br> l_start NUMBER;<br>BEGIN<br> SELECT seq.NEXTVAL INTO l_start FROM DUAL;<br> -- 拿到起始值后，本地生成 l_start ~ l_start+99 共100个ID<br>END;
为什么不能靠 DG Broker 或 LOG_ARCHIVE_DEST_n 参数同步序列值
序列值本身不走重做流——Oracle 只记录序列的当前值（LAST_NUMBER）在控制文件和数据字典中，且仅在 ALTER SEQUENCE ... RESTART 或实例重启后 checkpoint 时才固化。归档日志里没有“序列递增”这条操作。
-
LOG_ARCHIVE_DEST_n控制的是归档日志传输，不影响序列状态同步 - DG Broker 的
EDIT DATABASE ... SET PROPERTY无法干预序列行为 - 即使手动在备库执行
ALTER SEQUENCE s RESTART START WITH N，也会因只读报ORA-16000 - 强行开备库读写（
ALTER DATABASE OPEN READ WRITE）就不再是 ADG，失去实时查询+灾备双重价值
最容易被忽略的点：应用连接路由与故障转移后的序列断层
主库宕机、应用自动切到备库（此时已转为新主库），如果之前用的是 CACHE 序列，旧主库最后一批缓存号段可能还没用完，新主库又从自己的 LAST_NUMBER 开始发号，必然导致重复或跳号。
- 不要假设序列值严格连续；业务逻辑必须容忍跳号（这是 Oracle 序列的设计前提）
- 避免在事务中依赖“刚取的 NEXTVAL 等于某张表 INSERT 后的 RETURNING 值”这类强一致性假设
- 如果业务真要求全局单调递增（如金融流水号），序列不是合适工具，应改用集中号段服务（如号段预分配中心）或数据库外的分布式 ID 生成器
ADG 下序列从来就不是“同步对象”，它是主库的本地资源。想让它“看起来同步”，得靠应用兜底，而不是寄希望于数据库配置。
