主库存储迁移无法零停机，但借助DG可实现业务无感知切换：中断被转移至秒级备库角色切换环节；前提必须是已建好并验证同步的物理备库，且主库启用FORCE LOGGING、备库为PHYSICAL STANDBY、V$ARCHIVE_DEST_STATUS为VALID、MRP0进程状态为APPLYING_LOG。
主库存储迁移本身无法零停机，但结合dg可做到业务无感知切换——关键不是“迁移中不中断”，而是“把中断转移到备库角色切换环节，并控制在秒级”。
主库换存储前必须先建好物理备库并验证同步状态
这是所有后续操作的前提。没备库，就谈不上DG容灾；备库没同步，切换就是灾难。
- 主库启用
FORCE LOGGING，确保所有变更都进归档流 - 备库必须是
PHYSICAL STANDBY，不能是逻辑备库或Far Sync实例 - 确认
V$ARCHIVE_DEST_STATUS.STATUS为VALID，且APPLIED_SCN与主库MAX(SEQUENCE#)差值≤1 - 检查
V$MANAGED_STANDBY.PROCESS中MRP0进程状态为APPLYING_LOG，不是WAIT_FOR_LOG或IDLE
主库存储迁移期间，所有读写仍走主库，备库持续接收并应用日志
迁移操作（如ASM磁盘组替换、LUN映射变更、存储网关切换）只影响主库I/O路径，不影响DG日志传输链路——只要网络通、归档目标可达、LGWR/ARCH进程正常，备库就一直在追。
- 迁移前停掉主库的
ARCH进程不是必须的，反而会堆积未归档日志；应确保LOG_ARCHIVE_DEST_2指向备库的SERVICE始终可连通 - 主库执行
ALTER DATABASE OPEN RESETLOGS类操作会中断DG，迁移中严禁触发此类动作 - 若主库因存储异常短暂挂起（如ASM disk offline），只要在
REDO TRANSPORT GAP窗口内恢复，备库仍能自动续传；超时则需人工干预FETCH ARCHIVED LOG
切换必须用Broker，手动SWITCHOVER在RAC或复杂配置下必然失败
RAC主库多节点、混合架构（如RAC主+单机备）、含PDB场景下，ALTER DATABASE COMMIT TO SWITCHOVER只能在一个节点执行，其余节点状态不同步，ORA-16789和ORA-16664几乎必现。
-
DGMGRL连接主库后，必须用SWITCHOVER TO '<standby_db_unique_name>'</standby_db_unique_name>，不是SQL*Plus里敲命令 - 切换前Broker会自动校验：
LOG_ARCHIVE_CONFIG双向包含、GLOBAL_DBNAME静态注册为<db_unique_name>_DGMGRL</db_unique_name>、ENABLED_PDBS_ON_STANDBY已设（PDB场景） - 切换耗时取决于备库积压日志量，实测
APPLIED_SCN与主库CURRENT_SCN差值SWITCHOVER过程通常
切换后主库变备库，立刻开始用新存储重建，此时原主库才是真正的“迁移操作窗口”
真正的零停机，是指用户业务全程访问的是“当前主库”。所以迁移动作要放在角色切换之后——此时原主库已降级为备库，业务完全不受影响。
- 新主库（原备库）上线后，立即验证
V$DATABASE.OPEN_MODE=READ WRITE，且应用端连接正常 - 原主库启动到
MOUNT状态，用RMAN或ASMCMD完成存储层重构（如ALTER DISKGROUP ... ADD DISK、REBALANCE） - 重构完成后，在原主库上执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT，重新接入DG链路 - 注意：此时原主库作为新备库，其
DB_UNIQUE_NAME必须仍在所有节点的LOG_ARCHIVE_CONFIG中，否则日志传不回来
最容易被忽略的是：存储迁移不是纯技术动作，而是状态管理动作——你迁的不是文件，是数据库角色与数据流向的确定性。一旦LOG_ARCHIVE_DEST_n里漏掉某个DB_UNIQUE_NAME，或者监听器没注册_DGMGRL服务名，Broker就卡在DISABLED状态，切换根本启动不了。这些细节不提前验证，等迁移中途才发现，业务中断时间就由秒级变成小时级。
