必须先停备库再停主库并停监听，再统一修改IP、hosts、网络配置及tnsnames.ora/listener.ora中所有HOST值，11g需重启实例生效，最后验证归档传输与MRP应用状态。
主备库IP变更前必须停掉监听和数据库实例
机房搬迁本质是网络层迁移，Data Guard对IP地址敏感，不能边运行边改。一旦只改/etc/hosts或网卡配置却不重启监听和实例，会出现连接超时、归档传输中断、ORA-12541: TNS:no listener等错误，且DG Broker可能持续报ERROR: ORA-16778: redo transport error。
正确顺序是：先停备库（shutdown immediate），再停主库（避免切换过程中产生新归档无法传输）；然后停两边的监听（lsnrctl stop）；最后统一修改操作系统IP、/etc/hosts、网卡配置文件（如ifcfg-ens160）。漏掉任意一环，后续STARTUP MOUNT或ALTER DATABASE RECOVER MANAGED STANDBY DATABASE都会失败。
tnsnames.ora和listener.ora里所有HOST值必须同步更新
Data Guard依赖Oracle Net连接主备，而连接串中的HOST字段硬编码了IP。搬迁后若只改了/etc/hosts但没动tnsnames.ora，主库仍会尝试往旧IP发归档，导致ARCH process died；备库的listener.ora若仍监听旧IP，则主库无法连上备库的监听器，v$archive_dest_status中STATUS显示ERROR，ERROR列出现ORA-12170: TNS:Connect timeout occurred。
需检查并修改以下位置：
- 主库
$ORACLE_HOME/network/admin/tnsnames.ora中所有条目（含PRIMARY、STANDBY、DB_UNIQUE_NAME对应别名）的HOST=值 - 备库
$ORACLE_HOME/network/admin/tnsnames.ora中指向主库的条目 - 主库和备库各自的
$ORACLE_HOME/network/admin/listener.ora中LISTENER段的(ADDRESS=(PROTOCOL=TCP)(HOST=...) - 若使用DG Broker，还需确认
dgmgrl连接使用的别名在tnsnames.ora中已更新
切换后必须验证归档传输与应用是否真正恢复
IP改完、实例重启、监听启动后，很多人以为就结束了，其实最关键的验证还没做。常见假成功现象：数据库能OPEN、DG Broker显示STATE = SUCCESS，但v$archived_log里最新归档的APPLIED = 'NO'，或v$managed_standby中PROCESS = 'MRP0'状态为WAIT_FOR_LOG而非APPLYING_LOG。
必须执行三步验证：
- 在主库执行
ALTER SYSTEM SWITCH LOGFILE，观察备库v$archived_log是否有新归档记录，且DEST_ID = 2、APPLIED = 'YES' - 查备库
v$managed_standby，确认PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG' - 用
SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY比对主备最近归档序号，差值应≤1（网络延迟允许范围内）
若发现归档堆积未应用，优先检查alter database recover managed standby database using current logfile disconnect是否执行成功，以及log_archive_dest_2参数里的VALID_FOR是否仍指向旧DB_UNIQUE_NAME。
11g不支持在线重配置，所有参数变更必须重启生效
Oracle 11g的Data Guard没有12c+的EDIT DATABASE ... SET PROPERTY动态能力。像log_archive_dest_2这种核心参数，如果搬迁后还残留旧IP或旧DB_UNIQUE_NAME，仅用ALTER SYSTEM SET ... SCOPE=BOTH是无效的——它只会写入spfile，但当前实例仍按内存中旧值运行，直到重启。
所以搬迁后务必检查：
-
SHOW PARAMETER log_archive_dest_2输出中的VALUE字段是否已包含新IP和新DB_UNIQUE_NAME -
SELECT NAME, VALUE FROM V$SPPARAMETER WHERE NAME LIKE 'log_archive_dest%'确认spfile已持久化 - 执行
SHUTDOWN IMMEDIATE+STARTUP MOUNT，再启MRP，否则归档传输永远卡在旧配置上
最容易被忽略的是：11g备库在MOUNT状态下无法直接ALTER SYSTEM SET修改log_archive_dest_n，必须先ALTER DATABASE OPEN READ ONLY再改，但这样又会导致MRP停止——所以最稳妥的做法，就是把所有参数更新写进pfile/spfile，然后干净重启。
