一次成功执行oracle 19c data guard switchover，90%取决于切换前状态确认：主库switchover_status须为to standby或sessions active，备库须为to primary或sessions active；v$archive_dest_status中dest_id=2的status必须valid且error为空；v$archived_log最后几条applied须全为yes；推荐用dgmgrl执行并切后执行alter system register。
能一次成功执行 Oracle 19c Data Guard Switchover，90% 的工作在切换前——不是命令没敲对，而是状态没看清。
查 SWITCHOVER_STATUS 值是否允许切换
这是最常被跳过的一步，但直接决定 ALTER DATABASE COMMIT TO SWITCHOVER 是秒回还是卡住甚至报 ORA-16129。必须分别在主库和备库执行：
- 主库：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;—— 必须返回TO STANDBY或SESSIONS ACTIVE - 备库：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;—— 必须返回TO PRIMARY或SESSIONS ACTIVE - 若主库是
SESSIONS ACTIVE，后续命令必须加WITH SESSION SHUTDOWN，否则会 hang 住 -
NOT ALLOWED表示 Redo 还没传完，别急着切，先查V$ARCHIVE_DEST_STATUS
确认 LOG_ARCHIVE_DEST_STATE_2 已启用且无积压
主库归档发不出去，备库永远收不到日志，Switchover 会在等待日志时超时或报 ORA-16139。
Personality Switcher
下载
创建并切换AI助手人格。使用 /personality 列出并激活已保存的人格；使用 /create-personality 设计新角色，自动填充 SOUL 与 IDENTITY。跨会话和对话压缩时人格持久化，自动恢复心跳。原子切换提供备份与回滚保护，切换前始终备份当前状态。
- 主库查：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——STATUS必须是VALID，ERROR列必须为空 - 检查最近归档是否已应用：
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG WHERE DEST_ID = 2 ORDER BY SEQUENCE# DESC FETCH FIRST 5 ROWS ONLY;—— 最后几条的APPLIED应全为YES -
ARCHIVE_LAG_TARGET在备库不建议设过大（如 > 1800），否则人为拖慢传输节奏
用 DGMGRL 执行比手敲 SQL 更稳
Broker 自动校验依赖项、串行化操作、更新配置元数据，比纯 SQL*Plus 少踩一半坑。
- 连 Broker：
dgmgrl sys/password@primary_db（注意：连当前主库，不是服务名） - 先验证配置：
SHOW CONFIGURATION—— 输出末尾必须是Configuration status: SUCCESS - 发起切换：
SWITCHOVER TO 'orcl_stby';（引号内是目标备库的DB_UNIQUE_NAME，不是 service_name） - 切完立刻查新主库：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;—— 应为PRIMARY和READ WRITE - 别忘了在新主库执行：
ALTER SYSTEM REGISTER;，否则监听器注册的服务名还是旧的，应用连不上
切换后应用连不上？大概率是客户端没刷新
数据库秒级完成，但 JDBC 连接池、TNS 缓存、驱动本身不感知角色变更，导致 ORA-12514 或 ORA-01033。
- TNSNAMES.ora 中对应服务名必须配
(FAILOVER=ON)，且HOST和PORT指向新主库；静态 IP + 单点 VIP 是反模式 - JDBC 连接串里的
service_name要设成新主库的DB_UNIQUE_NAME，不是旧的ORCL - 连接池（如 HikariCP、Druid）需配置
connection-test-query或启用validation-timeout，避免复用失效连接
真正难的从来不是“怎么切”，而是“怎么确认能切”——SWITCHOVER_STATUS、APPLIED 字段、DGMGRL SHOW CONFIGURATION 这三处状态，漏看任意一个，就可能让一次计划内维护变成故障响应。
