ORA-12505报错90%因SID与服务名混淆：DBeaver中Connection type选错（SID/Service name）或填入值不匹配实际注册名，应查v$parameter或lsnrctl status确认正确服务名并选用Service name模式。
ORA-12505 报错时，90% 是 SID 和服务名填反了
看到 ORA-12505: TNS:listener does not currently know of SID given in connect descriptor，别急着改密码或重装驱动。这错误明确表示监听器“听到了请求，但不认识你写的那个名字”——它不是连不上，是叫错了人。
根本原因就一个：你在 DBeaver 里选了 SID 模式，但数据库实际注册的是 SERVICE_NAME（比如 Oracle 12c+ 的 PDB、RAC、ATP 都只用服务名）；或者反过来，选了服务名模式，但 URL 或参数里误填了 SID 字符串。
- Oracle 11g 及更早单实例库：SID 和服务名可能相同，
SID=ORCL偶尔能蒙对 - Oracle 12c/19c/21c 默认启用多租户（CDB/PDB），
SID指向 CDB 实例，而你真正要连的通常是 PDB，它的接入点只能是SERVICE_NAME（如XEPDB1、ORCLPDB1） - DBeaver 连接向导里有个关键开关：
Connection type，选项是SID或Service name—— 它不光影响界面字段名，更会决定最终生成的 JDBC URL 格式
DBeaver 的 Connection type 到底控制什么
这个下拉选项不是 UI 装饰，它直接决定 JDBC URL 的语法结构和底层解析逻辑：
- 选
SID→ 生成 URL 形如jdbc:oracle:thin:@host:port:ORCL（三个冒号，末尾是 SID） - 选
Service name→ 生成 URL 形如jdbc:oracle:thin:@//host:port/ORCLPDB1（双斜杠开头，末尾是服务名） - 如果选了
Service name却在“Database/SID”输入框里填ORCL（一个传统 SID），DBeaver 仍会拼出@//host:port/ORCL，但监听器查不到这个服务名，直接报ORA-12505 - 反之，选
SID却填入XEPDB1（明显是服务名格式），URL 变成@host:port:XEPDB1，监听器按 SID 查，当然也找不到
怎么确认该用 SID 还是服务名
别猜，别试，直接查数据库本身最可靠：
- 登录数据库执行：
SELECT value FROM v$parameter WHERE name = 'service_names';—— 返回值就是你该填的服务名（可能多个，用逗号分隔，任选其一） - 查监听器注册了啥：
lsnrctl status（需在数据库服务器上运行），看输出里Services Summary下列出的名字，不是Instance "xxx"那行 - 翻
$TNS_ADMIN/tnsnames.ora文件（如果 DBA 给过），里面每个条目等号右边的SERVICE_NAME=...值就是服务名；SID=...是旧式配置，现在极少单独用 - 不确定时，优先选
Service name模式 —— Oracle 官方自 12c 起已将服务名设为默认和推荐方式，SID 属于遗留兼容项
URL 格式写错也会触发 ORA-12505
即使 Connection type 选对了，手写 URL 时一个字符错，照样报错：
- 用服务名时，必须是
@//host:port/service_name（注意双斜杠//），写成@/host:port/service_name或@host:port/service_name都会退化成 SID 解析逻辑 - 服务名区分大小写，
XEPDB1≠xepdb1，尤其在 Linux 环境下 - 服务名里不能有空格、中文、下划线以外的特殊字符；若含域名（如
hrapp.prod.example.com），确保 DNS 可解析或 hosts 有映射 - 端口必须是监听器端口（默认
1521），不是 HTTP 端口（如8080）或数据库后台进程端口
最稳的做法：在 DBeaver 连接向导里老老实实选好 Connection type，然后只填 Host、Port、Database/SID（此时它其实是服务名字段）、Username、Password —— 让 DBeaver 自动生成 URL，别手敲。
