通过查询v$database视图的DATABASE_ROLE字段是否为PRIMARY来判断；需用具备SELECT ANY DICTIONARY权限的用户执行SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE，并trim()后精确比对，不可依赖URL、OPEN_MODE或连接状态。
如何判断Oracle物理备库是否已切换为主库？
物理备库切换后，数据库角色和打开模式会变化，但JDBC连接本身不会自动感知——它只认当前连接的实例状态。必须主动查询动态性能视图才能确认角色变更。
-
V$DATABASE是唯一可靠来源：查DATABASE_ROLE字段（值为PRIMARY或PHYSICAL STANDBY），不能依赖OPEN_MODE（备库切换后可能为READ WRITE，但主库也可能为READ WRITE） - 必须用有
SELECT ANY DICTIONARY权限的用户（如sys as sysdba）执行查询，普通应用账号默认无权访问V$DATABASE - 不要在连接池初始化时只查一次：切换可能发生在运行中，需定期轮询或在关键业务前校验
JDBC查询V$DATABASE的最小可行代码
直接执行 SQL 查询比调用 Oracle 特有 API 更轻量、更可控，且不依赖 ojdbc8.jar 以外的额外依赖。
String sql = "SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE";
try (PreparedStatement ps = conn.prepareStatement(sql);
ResultSet rs = ps.executeQuery()) {
if (rs.next()) {
String role = rs.getString("DATABASE_ROLE").trim();
String openMode = rs.getString("OPEN_MODE").trim();
boolean isPrimary = "PRIMARY".equals(role);
// 注意：isPrimary 为 true 才代表当前是主库
}
}
- 务必
trim()字段值：Oracle 返回的DATABASE_ROLE带尾部空格，直接equals("PRIMARY")会失败 - 不要用
rs.getString(1)这类序号取值：列顺序不保证，必须用列名 - 异常处理要区分
SQLException类型：如果是 ORA-00942（表或视图不存在），说明权限不足；ORA-01017（用户名/密码错误）则可能是连接到了错误实例
为什么不能靠连接URL或TNS别名判断？
物理备库切换后，原主库可能仍监听同一地址端口，TNS 名称、JDBC URL 完全不变——连接串里写的 mydb.example.com:1521/ORCL 在切换前后都有效，但背后实例角色已反转。
- 连接成功 ≠ 当前是主库：备库启用
ADG（Active Data Guard）时可同时接受读写连接（若开启ENABLE PLUGGABLE DATABASE或使用ALTER DATABASE OPEN READ WRITE），此时连接能通，但写操作会报 ORA-16000（database open for read-only access） - 不能依赖
conn.getMetaData().getURL()：返回的是初始连接串，不反映实时角色 - DNS 或负载均衡器重定向也无法解决：它们只管网络可达性，不管 Oracle 内部角色状态
生产环境检测频率与超时设置建议
检测本身开销极小（毫秒级），但频繁查 V$DATABASE 可能被审计策略拦截或触发监控告警，需平衡及时性与扰动。
立即学习“Java免费学习笔记（深入）”；
- 非关键场景：每 30–60 秒查一次，配合连接池的
validationQuery（如设为SELECT 1 FROM DUAL）做连通性兜底 - 写操作前强制校验：在执行 INSERT/UPDATE/DELETE 前，先查
V$DATABASE并断言isPrimary == true，否则抛自定义异常（如NotPrimaryException） - 设置合理查询超时：
ps.setQueryTimeout(3)，避免因 RAC 节点故障或锁表导致线程卡死
真正容易被忽略的是权限配置——很多团队把 JDBC 用户权限限制得很死，结果检测逻辑永远走不到 isPrimary 分支，却误以为“没切换”。先确保 SELECT ANY DICTIONARY 或明确授予 SELECT ON V_$DATABASE，再谈逻辑。
