维护前必须确认remote_listener生效，检查其配置、scan监听器状态及pmon注册日志；停机须用srvctl stop instance而非shutdown abort；验证新连接100%切走需脚本测试；确保auto_start=always且依赖正常；客户端应使用scan名连接。
维护前必须确认 remote_listener 是否生效
节点停机前如果 remote_listener 没配置或失效，SCAN 监听器就无法感知其他节点的负载变化，新连接仍可能被错误分发到待维护节点，导致连接堆积甚至超时。检查方法很简单：
- 在任意节点执行
show parameter remote_listener，确认值非空且与tnsnames.ora中定义的别名一致（如LISTENERS_RAC） - 运行
lsnrctl status，看 SCAN 监听器下该 service 是否显示多个instance（例如Instance "rac1", status READY和Instance "rac2", status READY） - 查
v$listener_network或监听日志，确认 PMON 是否在持续向远程 listener 注册（日志中应有service-update记录）
用 srvctl stop instance 而不是直接 shutdown abort
直接 shutdown abort 会跳过实例优雅退出流程，Clusterware 无法及时回收资源，VIP 可能残留、SCAN listener 仍认为该实例“可用”，新连接继续打进来。正确做法是交由 GI 统一调度：
- 执行
srvctl stop instance -d <db_name> -i <inst_name></inst_name></db_name>（例如srvctl stop instance -d racdb -i racdb1） - 该命令会触发 Clusterware 先迁移 service、释放 VIP、关闭监听器，再终止数据库进程
- 过程中
crsctl stat res -t可观察状态从ONLINE→STOPPING→OFFLINE - 若需强制停止（如实例僵死），用
srvctl stop instance -f，但之后务必手动检查crsctl stat res -t确保无残留
验证负载是否真正切走：别只看 v$session
v$session 显示的是已建立连接，而负载均衡只影响“新连接”的分配。维护中真正要盯的是新连接去向：
- 在待维护节点停实例前，先用脚本循环建连接：
for i in {1..50}; do sqlplus -s /@racdb @get_inst.sql; sleep 0.1; done -
get_inst.sql内容：select instance_name from v$instance; - 停掉
racdb1后再跑同样脚本，输出应全部为racdb2—— 这才说明新连接已 100% 切走 - 注意：
v$active_services中对应 service 的failover_type和failover_method必须是SELECT/BASIC或SESSION/BASIC，否则 TAF 不生效，应用侧可能报错
硬件重启后实例没自动拉起？检查 ora..db resource 状态
Oracle Linux 8.4 上 GI 默认启用 auto-start，但常见故障点是 resource 被人工 disable 或依赖关系异常：
- 执行
crsctl stat res ora.racdb.db -p | grep AUTO_START，值必须是always - 若为
restore或never，需运行crsctl modify resource ora.racdb.db -attr "AUTO_START=always" - 检查依赖：
crsctl stat res ora.racdb.db -dependency，确保不卡在ora.asm或ora.<diskgroup>.dg</diskgroup>上（常见于 ASM disk header 损坏或 udev 规则未生效） - 重启后首次启动慢？可能是 ASM 实例等待磁盘心跳超时，可临时调大
_asm_hbeatiowait（仅调试用）
tnsnames.ora 中硬编码的 VIP 地址。哪怕服务端一切正常，客户端若缓存了旧 VIP 或直连了待下线节点的 VIP，连接仍会失败。建议维护窗口期统一要求应用方使用 SCAN 名连接，并确认其解析指向的是集群当前有效的 SCAN IP 列表。
