Switchover后新主库启动失败主因是DB_DOMAIN不一致导致监听注册失败；需在切换前确保主备库DB_DOMAIN值完全相同（含空值），否则GLOBAL_DBNAME异常，监听器无法动态注册服务名，引发ORA-12514等连接问题。
switchover后新主库启动失败，大概率不是归档或控制文件问题，而是db_domain不一致导致监听注册失败
Switchover后ALTER DATABASE OPEN报ORA-12514或监听找不到服务
常见现象是：备库执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY后，再ALTER DATABASE OPEN成功，但应用连不上——tnsping通、lsnrctl status里看不到服务名，或者报ORA-12514: TNS:listener does not currently know of service requested。这不是网络或tnsnames.ora配置错，而是监听压根没注册上服务。
根本原因常被忽略：DB_DOMAIN在主备库不一致，导致GLOBAL_DBNAME生成异常，而Data Guard Manager（DGMGRL）和监听器都依赖它做动态服务注册。
- 主库
DB_DOMAIN为example.com，备库为test.local（或为空）→ 两库GLOBAL_DBNAME不同 → DGMGRL切换时无法正确推送服务名到新主库监听器 - 即使
service_name在tnsnames.ora里写对了，监听器内部注册的GLOBAL_DBNAME仍是错的，ALTER SYSTEM REGISTER也刷不出来 - 该问题在12c+使用DGMGRL或
SWITCHOVER VERIFY时更隐蔽，因为验证阶段不校验DB_DOMAIN
如何快速确认DB_DOMAIN是否一致
必须在Switchover前查，而不是切完再救。两库分别执行：
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain';
结果必须完全相同（包括大小写和空值）。若备库返回空（NULL），而主库有值，就已埋雷。
- 主库
DB_DOMAIN非空 → 备库DB_DOMAIN必须设为相同值，且需写入SPFILE：ALTER SYSTEM SET DB_DOMAIN='example.com' SCOPE=SPFILE; - 主库
DB_DOMAIN为空 → 备库也必须显式设为空：ALTER SYSTEM SET DB_DOMAIN='' SCOPE=SPFILE;（不能留默认值） - 改完必须重启备库（
SHUTDOWN IMMEDIATE+STARTUP），否则V$PARAMETER仍读内存值
Switchover后补救：强制重注册服务名
如果已经切完、新主库OPEN成功但监听无服务，别急着重建DG。先尝试修复注册：
- 在新主库执行：
ALTER SYSTEM SET GLOBAL_NAMES=FALSE SCOPE=BOTH;（临时绕过域名校验） - 确认监听器
listener.ora中GLOBAL_DBNAME字段未硬编码，应为db_unique_name_DGMGRL格式（如mydb_stb_DGMGRL） - 执行：
ALTER SYSTEM REGISTER;，然后lsnrctl status看服务名是否出现 - 若仍不显示，检查
V$LISTENER_NETWORK和V$LISTENER_ENDPOINT，确认监听器实际监听的IP/端口与tnsnames.ora中SERVICE_NAME指向一致
DB_DOMAIN不一致引发的连锁反应不止监听
它还会让LOG_ARCHIVE_CONFIG中的DB_UNIQUE_NAME解析异常，导致归档传输静默失败；在RAC环境中更会触发OCR同步冲突。最麻烦的是：这个问题不会在SWITCHOVER VERIFY或VALIDATE DATABASE里报错，只有切完那一刻才暴露——而且错误日志分散在alert.log、listener.log、DGMGRL trace里，很难串起来定位。
