如何修改SCAN IP_修改DNS解析后使用srvctl更新集群信息

srvctl modify scan 报 ORA-01017 或连接失败的本质与解决

遇到 srvctl modify scan 报 ORA-01017 或连接失败，先别急着怀疑密码。这事儿的关键，往往不是认证信息错了，而是连接集群的“内部通道”被拒绝了。简单来说，命令执行前，Oracle会尝试用你当前环境变量里的 ORACLE_HOME 和 GRID_HOME 去连接集群（底层是通过 crsctl 调用OCR）。如果当前用户没权限访问GI的根操作通道，或者 grid 用户的环境根本没生效，那认证失败就是必然结果。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

所以，核心思路是确保你正站在正确的“位置”上操作：

• 务必以 grid 用户身份运行命令。别用 oracle 或 root 用户直接操作。这里有个细节：要用 su - grid（带横杠），它会把 grid 用户的环境变量完整加载进来；如果用 su grid，环境可能没切干净，命令照样会失败。
• 先打个底，检查集群状态是否健康。运行 crsctl check crs，确认它返回的是 CRS-4638: Oracle High A vailability Services is online。如果集群服务本身就不在线，srvctl 命令必然失败。
• 还有一种情况：你打算更新的SCAN名字，在DNS里已经解析到了新IP，但OCR里还存着旧值。这时候 srvctl modify scan 可能会拒绝更新，因为它检测到潜在冲突。所以，操作前最好确认一下，旧的SCAN记录是否已经从DNS中彻底下线了，避免出现“双SCAN”的混乱局面。

修改 DNS 后 srvctl modify scan 报 ORA-15032 / ORA-15274

这类错误听起来吓人，但本质很清晰：OCR（Oracle集群注册表）里的SCAN VIP资源依赖关系，没能跟上DNS的变化。也就是说，DNS记录你改完了，但GI（Grid Infrastructure）还在傻傻地尝试用老IP去启动VIP资源，结果当然是启动失败。这个失败会触发整个修改操作回滚，并抛出ORA错误。

要解决这个问题，得按顺序来：

• DNS缓存是第一个坑。DNS修改后，必须等待TTL（生存时间）过期，让所有节点的DNS缓存更新。如果等不及，可以在所有集群节点上清空本地DNS缓存（比如重启 nscd 服务），并检查 /etc/resolv.conf 的配置。目的是确保在所有节点上执行 nslookup 得到的结果是完全一致的新IP。
• 操作前先“停车”。执行修改命令前，先把相关的SCAN资源停掉：srvctl stop scan 和 srvctl stop scan_listener。这是为了避免旧的VIP还占着网络端口，导致新的地址绑不上去。
• 命令要写“全名”。使用 srvctl modify scan 时，必须用 -n 参数显式指定完整的SCAN全限定域名（FQDN），例如 -n mycluster-scan.example.com。如果只写 mycluster-scan，GI可能会自己拼接一个错误的域名后缀，导致解析失败。

srvctl modify scan 成功但 lsnrctl status 看不到新 SCAN listener

命令返回成功，只是万&里长征第一步。SCAN监听器的启动，依赖于SCAN VIP成功绑定到操作系统的网卡上。如果VIP没绑上，监听器就是“无源之水”。

这时候，你需要层层排查：

• 先看网络层。用 ifconfig 或 ip addr 命令，检查对应的SCAN VIP是否真的作为一个别名IP（比如 eth0:1）出现在某块网卡上。如果看不到，监听器自然无法监听。
• 再核对OCR配置。运行 srvctl config scan 和 srvctl config scan_listener，仔细比对输出中的IP地址，是否和DNS解析的结果一模一样。如果不一致，说明OCR的更新可能没真正落地，你需要重新执行一遍修改命令。
• 最后查日志。监听器日志是个宝藏，位置通常在 $GRID_HOME/log//client/tnslsnr__alert.log。重点查找类似“TNS-12545”或“No such device”这样的错误，它们通常直接指向底层的网卡或路由配置问题。

SCAN IP 修改后客户端连不上，但 tnsping 扫描名却成功

这个现象最让人困惑：客户端应用连不上，但用 tnsping 去测试SCAN名字，居然显示成功。其实，tnsping 仅仅验证了两件事：DNS解析是否成功，以及到目标IP的TCP端口（默认1521）是否能通。它完全不检查SCAN监听器是否真的准备好接受数据库连接了。

常见的情况是，SCAN监听器进程是起来了，但它背后没有加载任何数据库服务名——也就是说，数据库实例根本没注册到这个监听器上。

• 检查监听器状态。运行 lsnrctl status LISTENER_SCAN1，仔细看输出里有没有包含数据库 SERVICE_NAME 的行。如果没有，那问题就明确了：数据库没注册过来。
• 修正数据库配置。数据库端的 remote_listener 参数必须指向新的SCAN名。执行 ALTER SYSTEM SET remote_listener='new-scan.example.com:1521' SCOPE=BOTH，然后立刻执行 ALTER SYSTEM REGISTER，强制数据库实例向新的SCAN监听器注册。
• 注意端口细节。SCAN监听器默认只监听1521端口。如果客户端的连接字符串里写的是其他端口（比如1522），那么即使DNS解析正确，连接也会失败，而且通常只表现为连接超时，错误信息不明显。

说起来，最棘手的其实是那个“时间窗口”：DNS修改生效、GI配置更新、数据库注册刷新，这三者如果没同步好，就会导致客户端、GI节点、数据库实例看到的SCAN地址各不相同。这种状态，靠执行一次命令是修复不了的，必须逐层、逐节点地去确认解析结果和资源状态，才能把整个链路重新对齐。