ORA-01017报错八成非密码错误，而是SERVICE_NAME配置错误或PDB未真正就绪；需查v$pdbs确认OPEN_MODE为READ WRITE/READ ONLY，并用v$services核对实际注册的服务名，确保tnsnames.ora中SERVICE_NAME与之完全一致，且lsnrctl status中可见该服务。
ora-01017 不是密码错，八成是 service_name 指错了容器，或 pdb 根本没真正就绪。
查 PDB 是否已 open 且服务已注册
连不上 PDB，第一反应不该是改密码，而是确认它是否“在线可被发现”。v$pdbs 和 v$services 是唯二可信来源：
-
SELECT con_id, name, open_mode FROM v$pdbs;—— 状态必须是READ WRITE或READ ONLY，MOUNTED或NEW都不行 -
SELECT name, pdb FROM v$services WHERE pdb IS NOT NULL;—— 输出的name列才是监听器认的服务名（比如myapp），不是 PDB 名本身（如PDBORCL） - 若查询无结果，说明该 PDB 还没向监听器注册服务：可能没执行
ALTER PLUGGABLE DATABASE pdborcl SAVE STATE;，或 CDB 重启后它没自动 open
验证 tnsnames.ora 中的 SERVICE_NAME 是否精确匹配
客户端用的 SERVICE_NAME 必须和上一步 v$services.name 的值完全一致——大小写、下划线、有无域名后缀，一个字符都不能差：
- 常见错误：把
PDBORCL（PDB 名）直接当SERVICE_NAME写进tnsnames.ora，但实际注册的服务名可能是小写的pdbo或自定义的hrsvc - 检查方式：
tnsping pdbo（替换成你查到的真实 service 名），若返回OK说明解析成功；若报ORA-12154，就是tnsnames.ora条目缺失或拼写不一致 - RAC 环境下，
SERVICE_NAME对应的是数据库服务，不是 SCAN 地址或节点名；用错会导致连接被路由到没承载该 PDB 的实例上
确认监听器里真有这个 service
lsnrctl status 的输出里必须出现对应 service 的条目，否则客户端再怎么配对也白搭：
- 运行
lsnrctl status，在Services Summary下找类似Service "pdbo" has 1 instance(s)的行 - 如果没看到，说明动态注册失败。检查 PDB 内是否设置了
local_listener：SHOW PARAMETER local_listener，若为空或指向无效别名，service 就不会上报 - 手动改过
listener.ora后，必须lsnrctl reload（或 stop/start），否则新配置不生效；客户端也可能缓存旧解析，可临时加tnsping验证
用 sqlplus 直连验证最可靠
别信 IDE 或应用日志的模糊提示，命令行直连能暴露真实问题：
- 成功：
sqlplus hr/hr@pdbo→ 显示Connected. - 报
ORA-12154：tnsnames.ora解析失败，回头核对条目名和服务名 - 报
ORA-01017：密码或用户权限问题（此时才该查用户是否存在、是否被锁、密码是否过期） - 报
ORA-12514：监听器收到请求，但没找到对应 service —— 说明tnsnames.ora里的SERVICE_NAME存在，但监听器没加载它，回到上一步排查注册逻辑
最容易被忽略的是：PDB open 了 ≠ 服务自动注册了。必须确保 SAVE STATE 已执行，且 local_listener 可达。动态注册机制默认开启，但一旦配置出错，它就静默失效——没有报错，只有连接失败。
