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/。重点查找类似“TNS-12545”或“No such device”这样的错误，它们通常直接指向底层的网卡或路由配置问题。/client/tnslsnr_ _alert.log
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地址各不相同。这种状态，靠执行一次命令是修复不了的，必须逐层、逐节点地去确认解析结果和资源状态，才能把整个链路重新对齐。
