Oracle 数据库升级踩坑：DBLink ORA-02019 问题解决思路

前言

今天协助客户将 Oracle 数据库从 9.2.0.1 升级至 19.3.0.0，升级采用 exp/imp 逻辑迁移方式，升级完成后测试发现，开发使用 DBLink 无法正常工作，报错信息如下：

ORA-02019: connection description for remote database not found

本文记录该问题的分析定位过程及最终解决方案。

问题复现

升级完成后，我确认已成功创建了 DBLink 并进行了基础测试：

-- 从源库提取 DBLink 创建语句 (9i 密码可见)
SQL> SELECT 'CREATE ' || DECODE(U.NAME, 'PUBLIC', 'public ') || 'DATABASE LINK ' || DECODE(U.NAME, 'PUBLIC', Null, 'SYS', '', U.NAME || '.') || L.NAME || ' CONNECT TO ' || L.USERID || ' IDENTIFIED BY "' || L.PASSWORD || '" USING ''' || L.HOST || ''';' TEXT
FROM SYS.LINK$ L, SYS.USER$ U
WHERE L.OWNER# = U.USER#;

-- 在新库创建 DBLink
CREATE public DATABASE LINK LUCIFER.LPC.ORACLE.COM CONNECT TO ORACLE IDENTIFIED BY "ORACLE" USING 'LUCIFER';

-- 基础测试 (成功)
select sysdate from dual@LUCIFER.LPC.ORACLE.COM;

查询结果如下：

然而，应用反馈其查询失败（使用的短名称格式）：

select sysdate from dual@LUCIFER;

在 SQL*Plus 中复现应用查询方式，确实报错：

SQL> select count(*) from od_cow@LUCIFER;
select count(*) from od_cow@LUCIFER
*
ERROR at line 1:
ORA-02019: connection description for remote database not found

问题明确：使用 @LUCIFER（短名称） 访问 DBLink 失败，而使用 @LUCIFER.LPC.ORACLE.COM（完整名称） 成功。

问题分析

初步怀疑问题与域名（Domain） 配置差异有关。对比源库与新库的关键配置：

源库 (9i)

-- global_names 参数 (决定 DBLink 名称是否强制匹配远程库 global_name)
SQL> show parameter global_names

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
global_names boolean FALSE

-- db_domain 参数 (数据库域名)
SQL> show parameter db_domain

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_domain string

-- global_name 值 (数据库全局名称)
SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
ORCL.LPC.ORACLE.COM

新库 (19c)

SQL> show parameter global_names

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
global_names boolean FALSE

SQL> show parameter db_domain

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_domain string

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
ORCL

核心问题定位：源库的 global_name 为 ORCL.LPC.ORACLE.COM，而新库的 global_name 仅为 ORCL。当应用程序使用短名称 @LUCIFER 访问 DBLink 时，Oracle 会尝试将其解析为 LUCIFER.<当前库的 global_name 后缀>。新库后缀为空，因此实际查找的是名为 LUCIFER 的 DBLink，但我们在新库创建的是全名 LUCIFER.LPC.ORACLE.COM，导致名称不匹配而报错。

问题解决

目标：将新库的 global_name 修改为 ORCL.LPC.ORACLE.COM，使其与源库一致。

尝试一：直接 UPDATE GLOBAL_NAME 表 (失败)

-- 新库操作
SQL> UPDATE GLOBAL_NAME SET GLOBAL_NAME='ORCL.LPC.ORACLE.COM';
1 row updated.

SQL> commit;
Commit complete.

-- 测试应用查询 (仍然失败)
SQL> select count(*) from od_cow@LUCIFER;
select count(*) from od_cow@LUCIFER
*
ERROR at line 1:
ORA-02019: connection description for remote database not found

结果：查询依然失败，尝试重建 DBLink (失败)：

• 删除原全名 DBLink (LUCIFER.LPC.ORACLE.COM) 后，重建全名 DBLink 后测试失败。
• 创建短名 DBLink (LUCIFER) 后，使用 @LUCIFER 成功，但 DBLink 名称不符合源库规范（源库 DBLink 是全名）。

尝试二：使用 RENAME 命令 (成功，但有波折)

-- 新库操作：使用 RENAME 命令修改 global_name
SQL> alter database rename global_name to ORCL.LPC.ORACLE.COM;

Database altered.

-- 尝试重建 DBLink (先删除旧的)
SQL> SELECT * FROM dba_db_links;

OWNER DB_LINK USERNAME HOST CREATED
-------------------- ------------------------------------------------------------ -------------------- ------------------------------ ----------
PUBLIC LUCIFER ORACLE LUCIFER

SQL> drop public database link LUCIFER.LPC.ORACLE.COM;
drop public database link LUCIFER.LPC.ORACLE.COM
*
ERROR at line 1:
ORA-02024: database link not found

SQL> drop public database link LUCIFER;
drop public database link LUCIFER
*
ERROR at line 1:
ORA-02024: database link not found

问题：明明存在名为 LUCIFER 的 DBLink (dba_db_links 可查)，却无法删除，提示不存在！为什么删不掉？ 搜了下 MOS，有一篇文档 DB Parameters - Global Database Name (GLOBAL_DB_NAME) (Doc ID 2643771.1) 比较符合：

这个跟我遇到的问题一致，都是 rename 方式修改了 global_name 之后无法删除已创建的 DBLink，解决方案：

手动修正 props$：

-- 检查当前的 GLOBAL_DB_NAME 值
SQL> select name,value$ from props$ where name ='GLOBAL_DB_NAME';

NAME VALUE$
-------------------- ------------------------------------------------------------
GLOBAL_DB_NAME ORCL.LPC.ORACLE.COM

-- rename 修改 global_name
SQL> alter database rename global_name to ORCL;

Database altered.

-- 再次查询，发现 rename 根本没有更新表 props$ 的值
SQL> select name,value$ from props$ where name ='GLOBAL_DB_NAME';

NAME VALUE$
-------------------- ------------------------------------------------------------
GLOBAL_DB_NAME ORCL.LPC.ORACLE.COM

-- 需要手动更新 props$ 表的 GLOBAL_DB_NAME 值
SQL> update props$ set value$ = 'ORCL' where name ='GLOBAL_DB_NAME';

1 row updated.

SQL> commit;

Commit complete.

-- 确保已经更新
SQL> select name,value$ from props$ where name ='GLOBAL_DB_NAME';

NAME VALUE$
-------------------- ------------------------------------------------------------
GLOBAL_DB_NAME ORCL

删除旧的 DBLink (此时成功)：

SQL> drop public database link LUCIFER;

Database link dropped.

重新 RENAME 到目标名称：

SQL> alter database rename global_name to ORCL.LPC.ORACLE.COM;

Database altered.

-- 检查 props$ 表
NAME VALUE$
-------------------- ------------------------------------------------------------
GLOBAL_DB_NAME ORCL.LPC.ORACLE.COM

重建 DBLink (使用源库相同的全名格式)：

SQL> CREATE public DATABASE LINK LUCIFER.LPC.ORACLE.COM CONNECT TO ORACLE IDENTIFIED BY "ORACLE" USING 'LUCIFER';

Database link created.

SQL> SELECT * FROM dba_db_links;

OWNER DB_LINK USERNAME HOST CREATED
-------------------- ------------------------------------------------------------ -------------------- ------------------------------ ----------
PUBLIC LUCIFER.LPC.ORACLE.COM ORACLE LUCIFER

测试数据是否可以正常访问：

SQL> select count(*) from od_cow@LUCIFER;

COUNT(*)
----------
4560938

SQL> select count(*) from od_cow@LUCIFER.LPC.ORACLE.COM;

COUNT(*)
----------
4560939

问题解决！ 应用程序可以正常使用短名称 DBLink 访问。

写在最后
数据库升级过程中，DBLink 是极易出问题的环节，务必高度重视。结合本次及以往经验，总结几点关键注意事项：

名称一致性：确保目标库的 global_name 与源库完全一致（特别是域名部分），这是短名称 DBLink 解析的基础。
创建方式：迁移 DBLink 时，严格使用源库的完整名称格式进行创建，避免在目标库创建不一致的短名称 DBLink。
配置迁移：同步相关的 TNS 条目（tnsnames.ora），保证 DBLink 连接字符串能正确解析到远程数据库。
客户端兼容性：大版本跨度升级时，评估并测试客户端工具（OCI）的兼容性，过旧的客户端或者数据库可能无法连接新版本数据库的 DBLink。
依赖对象：DBLink 失效可能导致依赖对象（如视图、同义词、包）编译失败，显著拖长升级时间，务必优先保证 DBLink 可用性。
系统表更新：如遇 rename global_name 后操作异常（如无法删除 DBLink），检查并手动更新 props$ 表是有效的解决途径 (参考 MOS 文档)。
希望本次故障排查经验能为大家的升级工作提供参考，避免类似问题。升级无小事，细节定成败！