Oracle DBLink连接MySQL完整指南：DG4ODBC配置与踩坑总结

01. 先搞清楚一件事：Oracle的DBLink本身并连不上MySQL

1.1 为什么默认情况下这条链路是断的

很多第一次接触这个需求的同学会默认认为：DBLink嘛，连什么数据库都是DBLink，改了连接串不就行了。我最初也是这么想的，直到在Linux服务器上折腾了一个下午，ORA-28545报错印在屏幕上时才意识到：Oracle的DBLink本质上走的是Oracle Net协议，它默认只认Oracle实例。你把MySQL当成对端目标去建DBLink，Oracle发过去的是一串TNS协议包，MySQL这边根本不知道该怎么回应，两边语言不通，连接自然建立不起来。

也就是说，想用DBLink访问MySQL，中间必须有一个“翻译官”角色。Oracle官方针对这个场景提供了一套组件：Database Gateway for ODBC，简称DG4ODBC。它负责接收Oracle发来的SQL请求，翻译成ODBC调用，再由ODBC驱动去访问MySQL，最终把结果集翻译回Oracle格式。理解了这个链路，后面所有配置就都有了解释。

1.2 完整的数据流转链路是什么样

我用一个实际项目里常用的比喻来解释：Oracle就像一家公司的老板，MySQL是只会说方言的供应商。老板不会直接打电话沟通，于是配了一个懂两门语言的秘书——这个秘书就是DG4ODBC进程。

一条查询从Oracle发起到MySQL返回结果，经历了完整的五步：

1. 客户端在Oracle会话中执行SELECT * FROM "orders"@mysql_lk，Oracle收到SQL后发现表名后面带着DBLink名，于是把它交给Oracle Net层处理。
2. Oracle Net根据连接串里的服务名，把请求发给本地监听器（listener）。
3. 监听器检查tnsnames配置后发现这是一个标注了HS=OK的异构服务，于是拉起一个dg4odbc进程。
4. dg4odbc进程加载init<SID>.ora配置文件，从里面找到HS_FDS_CONNECT_INFO指向的ODBC DSN名称，再通过unixODBC调用MySQL驱动，最终访问到MySQL的数据。
5. 查询结果再沿着原路返回，DG4ODBC把MySQL返回的数据包装成Oracle能识别的行格式。

每一步都有独立的配置文件，任何一层断掉，都会出现不同表现形式的报错。这也是为什么DBLink连MySQL的报错排查起来非常考验耐心——问题不在SQL，而是在这几层“管道”之间。

1.3 不是所有同步需求都适合用DBLink

我在项目上见过不少把DBLink用歪的场景。如果你的需求是“亿级大表、分钟级实时同步、两边高并发”，DBLink真的不是最优选择。这里我把自己在选型时的一套判断标准整理出来，供你参考。

场景	推荐方案	原因
小配置表/维表偶尔查询	DBLink直查	轻量、不需要额外同步链路
百万级以内、每天/每小时同步	DBLink + 物化视图/定时任务	配置一次，长期复用，成本最低
千万级以上、分钟级同步	Canal + Kafka + 同步程序	DBLink逐行封装开销大，扛不住高频大流量
跨云异地、要求不丢数据	数据同步工具 / 消息中间件	DBLink依赖网络稳定性，长链路易中断
只做一次全量迁移	DataX / 直接导出导入	一次性搬数据，没必要建常驻网关

我做过的那个项目，业务端MySQL单表大概200万行，每天同步一批到Oracle数仓，DBLink + 定时任务完全够用。如果你也是类似的数据量级和频率，这篇文章的方案可以直接落地上线。

02. 环境准备三件套：驱动、unixODBC、Gateway，缺一不可

2.1 MySQL ODBC驱动怎么选、怎么装

先说明一个容易混淆的点：DG4ODBC不是数据库驱动，它只是中间翻译进程，真正去和MySQL通信的是ODBC驱动。所以环境准备的第一件事，就是把MySQL ODBC驱动装好。

我这次使用的环境是Oracle Linux 7.9 + Oracle 19c + MySQL 8.0。驱动选择的是官方长期支持的mysql-connector-odbc，安装完成后在/usr/lib64/下能看到libmyodbc8w.so和libmyodbc8a.so两个文件，其中w结尾的是宽字符版本，a结尾的是ANSI版本。处理中文数据时我会优先选宽字符版，后面字符集问题会少很多。

安装命令很简单：

# 安装unixODBC（DG4ODBC依赖它做驱动管理） yum install -y unixODBC unixODBC-devel # 安装MySQL官方ODBC驱动（根据你的MySQL版本选择对应的rpm包） rpm -ivh mysql-connector-odbc-8.0.33-1.el7.x86_64.rpm # 安装后确认so文件存在 ls -l /usr/lib64/libmyodbc8*.so

这里有个版本配套的经验：如果源端MySQL是5.6/5.7，建议用5.3.x版本的ODBC驱动；如果是8.0以上，用8.x驱动。太老的环境配过新的驱动，有机会出现ODBC调用接口不兼容的问题，那种报错看起来像是连接失败，实际上却是驱动版本不匹配。

2.2 unixODBC里要求ODBC层先能独立测通

很多教程会把unixODBC一笔带过，但这个组件非常重要。DG4ODBC走的不是直连数据库的私有接口，而是ODBC标准接口，它需要unixODBC这个管理器来加载驱动、维护DSN。如果你跳过了这一步，后面建DBLink时会反复在ORA-28545和ORA-28511之间来回横跳。

装完之后，DSN统一配置在/etc/odbc.ini里。我一般会在配置后先用unixODBC自带的isql命令独立测试一遍，确认ODBC这一层是通的，再进入Oracle侧配置。这一步本质上是在做问题隔离——ODBC层独立测通了，后面再有报错，责任就不在MySQL驱动了，排查范围直接缩小到Oracle网关层。

2.3 确认DG4ODBC组件到底装了没有

Oracle Linux上安装数据库时，dg4odbc可执行文件并不一定默认存在。有些精简安装或者Desktop版，这个组件会被跳过。检查方法很直接：

# 检查可执行文件是否存在 ls $ORACLE_HOME/bin/dg4odbc # 检查HS样例目录是否存在 ls $ORACLE_HOME/hs/admin/

如果目录是空的或者文件不存在，说明当前数据库没有安装Database Gateway组件。解决办法是在Oracle安装介质中找到对应的组件包，通过runInstaller补装。经验上，标准的企业版安装一般都会带上，但如果你用的是一家云厂商的定制镜像，就要格外留意这一点。

当年我第一次配置时就踩过这个坑：目录都建好了，tnsnames也配了，监听器怎么reload都识别不到那个异构服务，最后发现是根本没有dg4odbc这个可执行文件，白白耗了半天时间。

2.4 版本配套的一些实际建议

Oracle这侧的版本跨度很大，老项目里Oracle 11g非常常见，新项目里则普遍是19c。我对每个主要版本组合给出一个经过验证的驱动搭配：

• Oracle 11g + MySQL 5.6/5.7：用mysql-connector-odbc-5.3.x，实测相对稳定。
• Oracle 12c/19c + MySQL 5.7：用ODBC 5.3或8.0开头版本都行，但要注意HS_FDS_SHAREABLE_NAME参数写的是完整so路径。
• Oracle 19c + MySQL 8.0：用ODBC 8.x系列，体验最好。
• Windows环境：注意64位数据库必须配64位驱动，ODBC数据源也要在“ODBC数据源管理器(64位)”里建，不要用默认打开的32位管理器。

另外一点提醒，如果你有多套Oracle数据库在运行，DG4ODBC是跟随$ORACLE_HOME的，配置时一定要确认$ORACLE_HOME和$ORACLE_SID已经切到目标实例，否则很容易把配置写错地方。

03. 四层配置的完整链路：odbc.ini、init文件、tnsnames、listener

3.1 第一层：odbc.ini 里的DSN

在/etc/odbc.ini文件里添加数据源定义，这一段决定了somedb这个DSN到底连到哪里。我用的是MySQL 8.0，字符集设置为utf8mb4：

[mysql_dsn] Driver = /usr/lib64/libmyodbc8w.so Server = 192.168.10.20 Port = 3306 Database = business_db Option = 3 Charset = utf8mb4

Option = 3是MySQL ODBC驱动里一个经验值，它表示启用CLIENT_FOUND_ROWS和CLIENT_INTERACTIVE两个连接选项，日常读写场景下能规避一些小问题。Charset务必和MySQL端的实际字符集保持一致。

配置保存后执行：

isql -v mysql_dsn dba_user 'dba_password'

如果能看到+---------------------------------------+之类的SQL提示符，说明ODBC层已经通了。

3.2 第二层：init .ora 里的异构服务参数

DG4ODBC进程启动后会去读取$ORACLE_HOME/hs/admin/目录下的init<SID>.ora文件，这里的SID就是后面tnsnames里要用到的SID名。假设我为这个网关定义的SID名是orc2mysql，那么文件名就是initorc2mysql.ora。

文件内容如下：

# 指定DSN名称，对应odbc.ini里的配置 HS_FDS_CONNECT_INFO = mysql_dsn # 指定具体驱动so文件路径 HS_FDS_SHAREABLE_NAME = /usr/lib64/libmyodbc8w.so # 是否开启跟踪日志，排查问题时置为debug HS_FDS_TRACE_LEVEL = off # 字符集控制，解决中文乱码的关键 HS_LANGUAGE = AL32UTF8 HS_NLS_NCHAR = UTF8 # 关闭远程统计信息获取，避免select时远端执行额外统计查询 HS_FDS_SUPPORT_STATISTICS = FALSE # 设置每次fetch行数，对性能有显著影响 HS_FDS_FETCH_ROWS = 5000

几个参数背后的逻辑：HS_FDS_CONNECT_INFO是DG4ODBC转发连接请求时要去查的DSN名，它必须和odbc.ini里的名字一字不差；HS_FDS_TRACE_LEVEL设为debug时可以输出非常详细的连接日志，但正常运行时一定记得关掉，因为日志量会大到吓人。

3.3 第三层：tnsnames.ora 注册异构网络服务名

在$ORACLE_HOME/network/admin/tnsnames.ora中新增一个条目：

mysql_gw = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) (CONNECT_DATA = (SID = orc2mysql)) (HS = OK) )

这段配置里有两个容易踩的坑，我单独拎出来说。

第一个坑：这里的HOST和PORT指向的是Oracle监听器自己的地址和端口，不是MySQL的地址。有些同学会习惯性地把这里写成MySQL的IP和3306端口，结果监听器死活无法转发。记住，Oracle会话是通过本地监听器找到dg4odbc进程的，不是直接找MySQL。

第二个坑：CONNECT_DATA里的SID必须和刚才的init文件名后缀一致，而且HS = OK这个标记必须显式声明。没有这个标记，监听器只会把它当成一个普通的Oracle服务名，不会拉起异构网关。

3.4 第四层：listener.ora 让监听器认识dg4odbc

监听器默认只监听动态注册的数据库服务，不会自动知道存在一个叫orc2mysql的异构服务。因此需要在$ORACLE_HOME/network/admin/listener.ora里加上静态注册信息：

SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = orc2mysql) (ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1) (SID_NAME = orc2mysql) (PROGRAM = dg4odbc) ) )

注意ORACLE_HOME要替换成你自己的实际路径。配置完成后重启监听器：

lsnrctl stop lsnrctl start lsnrctl status

在lsnrctl status输出中，如果你能看到类似Service "orc2mysql" has 1 instance(s)的条目，并且实例状态是UNKNOWN，说明静态注册已经生效。此时整条链路已经打通，可以进入下一步创建DBLink。

3.5 创建DBLink并验证三种查询写法

在Oracle SQL客户端执行：

CREATE DATABASE LINK mysql_lk CONNECT TO "dba_user" IDENTIFIED BY "dba_password" USING 'mysql_gw';

这里特别注意：CONNECT TO后面的用户名和密码，指的是MySQL里的账号，而不是Oracle的账号。USING后面写的是tnsnames里定义的网络服务名mysql_gw。

验证查询有三种写法，我刚入门时就在这里被表名大小写折磨过：

-- 写法1：MySQL表名是纯小写，用双引号包起来（推荐） SELECT COUNT(*) FROM "orders"@mysql_lk; -- 写法2：如果MySQL表名本身就是大写，可以不加引号 SELECT COUNT(*) FROM ORDERS@mysql_lk; -- 写法3：查dual验证连通性 SELECT * FROM dual@mysql_lk;

为什么必须加双引号？Oracle默认会把未加引号的标识符自动转成大写，然后发给MySQL。如果MySQL端表名是小写orders，DG4ODBC把ORDERS传过去之后，MySQL会报Table doesn't exist，反映到Oracle侧就是ORA-00942: table or view does not exist。这个问题在单表同步时几乎必现，记住这个经验能给你省下不少时间。

3.6 Windows环境的配置差异

Windows上做这件事的原理和Linux完全一样，区别只在于界面操作：ODBC DSN需要在“ODBC数据源管理器(64位)”中创建，并且一定要建系统DSN而不是用户DSN；init<SID>.ora和tnsnames的配置路径都在%ORACLE_HOME%\hs\admin和%ORACLE_HOME%\network\admin下。其他参数完全通用，这里就不单独展开写了。

04. 同步方案怎么定：直查、物化视图刷新、还是定时增量抽取

4.1 三种方案怎么选

链路通了之后，下一个问题就是：数据怎么同步？我在实际项目里用过三种方式，它们的定位很不一样。

同步方案	实现成本	数据实时性	适合场景
每次直查远程表	最低	每次访问都是最新	小配置表、偶尔查询
物化视图定时全量刷新	中等	分钟/小时级	百万级以内单表、全量快照
时间戳增量+定时任务	最高	分钟级	中大表、有更新时间字段

下面分别说说每种方案的具体操作和注意事项。

4.2 物化视图：一条语句搞定定时快照

如果目标只是“每天把MySQL这张订单表同步到Oracle，作为数仓基础表”，物化视图是最省事的方案。用一条SQL就能建出来：

CREATE MATERIALIZED VIEW mv_orders BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND START WITH SYSDATE NEXT SYSDATE + 1 AS SELECT * FROM "orders"@mysql_lk;

BUILD IMMEDIATE表示创建时立即执行一次查询，把数据落下来。REFRESH COMPLETE表示每次刷新都全量重建，ON DEMAND表示不自动定时刷，而是靠后面的START WITH和NEXT控制。

这里必须强调一个理念：异构源下不要指望REFRESH FAST。快速刷新依赖物化视图日志，而DG4ODBC场景下MySQL端根本不存在Oracle的物化视图日志，所以快速刷新不仅不会加快速度，还可能出现ORA-12034等日志相关错误。老老实实用COMPLETE，全量刷新虽然听起来笨重，但对于百万级以内的表，刷新完成通常只需要几十秒到几分钟，完全可接受。

手动刷新可以用：

DBMS_MVIEW.REFRESH('mv_orders', 'C');

注意物化视图刷新时查询的是旧数据，刷新完成瞬间才切换为新数据，所以如果你需要严格的数据一致性，记得把刷新任务安排在业务低峰期。

4.3 时间戳增量+定时任务：适合更大的表

当源表数据量到了几百万行以上，每次都全量刷新会很浪费。这时候需要增量同步。增量同步的前提是MySQL端表里有一个可靠的更新时间字段，且该字段有索引。以updated_at为例，整体思路是：在Oracle侧建一张目标表，然后定时把MySQL端大于目标表最大updated_at的记录插进来。

先建目标表结构：

CREATE TABLE orders_dw AS SELECT * FROM "orders"@mysql_lk WHERE 1=0;

再通过DBMS_SCHEDULER创建定时任务：

BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name => 'SYNC_ORDERS_JOB', job_type => 'PLSQL_BLOCK', job_action => ' DECLARE v_max_dw DATE; BEGIN SELECT NVL(MAX(updated_at), DATE ''1970-01-01'') INTO v_max_dw FROM orders_dw; INSERT INTO orders_dw SELECT * FROM "orders"@mysql_lk WHERE updated_at > v_max_dw; COMMIT; END;', start_date => SYSTIMESTAMP, repeat_interval => 'FREQ=MINUTELY; INTERVAL=30', enabled => TRUE ); END; /

这套方案的优点是实现简单、对源库影响小。但它有几个硬伤，必须在设计阶段就想清楚：

第一，MySQL端如果发生的是物理删除，时间戳增量同步检测不到。被删掉的行不会出现在增量结果里，Oracle侧目标表会一直保留已删除的数据。解决思路是让业务端改为软删除，或者额外维护一张删除日志表，同步任务里单独处理删除标记。

第二，重复执行时如果源端更新字段有重复值，可能出现主键冲突。稳妥的做法是把INSERT换成MERGE，用主键判断是插入还是更新。

第三，时间戳字段本身要建索引，否则每条增量SQL都会变成全表扫描，对MySQL压力很大。

4.4 一个特别容易踩的坑：SQL不会全部下推到远端

DBLink查询时，Oracle的优化器会尽量把WHERE这类简单过滤条件下推给远端，但遇到GROUP BY、ROWNUM分页、自定义函数时，大概率会变成“把整张表拉回本地再处理”。这个问题的经典表现就是分页查询：

-- 这种写法看着没问题，实际可能把整张orders表拉到Oracle端再分页 SELECT * FROM ( SELECT t.*, ROWNUM rn FROM "orders"@mysql_lk t ) WHERE rn BETWEEN 1 AND 100;

20万行以内感觉不明显，200万行以上就会明显变慢。实践中的做法是：在MySQL端先建一个视图，把分页、聚合这类复杂逻辑封装在视图里，Oracle通过DBLink直接查这个视图。这样复杂计算留在MySQL侧执行，Oracle拿到的已经是精简后的结果集。这个思路在数据抽取任务里非常实用，建议优先考虑。

05. 踩坑记录与性能实测：这些问题排查了我一整天

5.1 ORA-28545连接失败的典型排查链路

这个报错是DBLink连MySQL时出现频率最高的一个，原文是ORA-28545: error diagnosed by Net8 when connecting to an agent。它说明DG4ODBC进程已经拉起来了，但通过ODBC访问MySQL时失败。我一般按照下面这条链路从上往下排查：

1. 先用isql独立测DSN，确认ODBC层是通的。如果isql都不通，问题回到MySQL驱动、网络、账号权限上。
2. 检查initorc2mysql.ora里的HS_FDS_CONNECT_INFO是否和odbc.ini里的DSN名一字不差。我遇到过大小写不匹配导致连接失败的案例。
3. 检查运行Oracle进程的操作系统用户对odbc.ini和驱动so文件是否有读权限。有时候DSN配在root家目录下，Oracle用户读不到，自然连不上。
4. 确认LD_LIBRARY_PATH环境变量里包含unixODBC的库路径。dg4odbc加载驱动时会依赖这些库，缺了路径就会加载失败。
5. 如果以上都没问题，在init文件里把HS_FDS_TRACE_LEVEL改成debug，重启监听后再执行查询，然后去$ORACLE_HOME/hs/log/下看跟踪日志。日志里会明确显示加载了哪个so、连接了哪个地址、失败的具体原因。

这套排查链路能覆盖绝大多数ORA-28545场景。记住一个原则：逐层隔离，不要从上到下乱翻配置。

5.2 中文乱码的根因和彻底解决办法

第一次同步中文数据时，我遇到了????乱码，典型的现象是MySQL端中文正常，Oracle端查出来全是问号。乱码的根因是字符集在MySQL、ODBC驱动、DG4ODBC、Oracle四个环节之间发生了不一致解码。

解决办法分三步：

1. MySQL端确认表和连接字符集是utf8mb4。
2. /etc/odbc.ini里设置Charset = utf8mb4。
3. initorc2mysql.ora里设置HS_LANGUAGE = AL32UTF8，并加上HS_NLS_NCHAR = UTF8。

如果改完之后仍然乱码，可以用DUMP函数快速定位是哪一侧解码错了：

SELECT DUMP(name) FROM "users"@mysql_lk WHERE ROWNUM = 1;

查看返回结果的字节序列，判断到底是UTF-8还是GBK编码。字节序列以227, 129, ...开头一般是UTF-8，以196, 227这类双字节开头往往是GBK。定位到哪一侧之后，把对应环节的字符集设置改齐，问题就能解决。

5.3 MySQL大小写引发的ORA-00942

这个问题我在3.5节里提过，但这里必须再强调一次，因为它在实际项目中太常见了。MySQL在Linux下默认表名是大小写敏感的，而Oracle默认会把SQL里的未加引号标识符转成大写。两者一碰撞，就是ORA-00942: table or view does not exist。

解决方法是查询时统一用双引号包裹原始名称：

SELECT order_id, order_amount FROM "orders"@mysql_lk WHERE ROWNUM <= 100;

注意，列名也可能遇到同样的问题。MySQL里列名同样可以是小写，Oracle转大写后就会报ORA-00904: invalid identifier。最稳的方案是在所有涉及异构表的SQL里，把表名和列名全部用双引号包成实际存储的大小写。写物化视图的时候尤其要小心，一开始写对了，后面刷新才不会因为大小写问题频繁失败。

5.4 大数据量同步的实测表现和调优方向

我实测的环境是：单表200万行、15个字段，局域网千兆网络，Oracle 19c + MySQL 8.0。直接执行SELECT * FROM "orders"@mysql_lk全量拉取，耗时约60秒，性能瓶颈主要体现在DG4ODBC逐行翻译和ODBC往返开销上。

优化的效果排序如下：

1. 只查需要的列。很多同步任务习惯SELECT *，其实10个字段和15个字段的传输量差距很明显，改成显式列名后性能提升约20%。
2. 把WHERE条件下推。让MySQL提前过滤掉不需要的行，减少传输数据量，这个优化在大表上效果最明显。
3. 调大fetch批次。在init文件里设置HS_FDS_FETCH_ROWS = 5000，减少ODBC往返次数，实测比默认值快了一倍左右。
4. 用PL/SQL批量插入。如果是从远程表抽取到Oracle本地表，配合BULK COLLECT和FORALL可以显著降低上下文切换开销。示例代码：

DECLARE CURSOR c IS SELECT order_id, order_amount, updated_at FROM "orders"@mysql_lk WHERE updated_at >= TRUNC(SYSDATE - 1); TYPE t_tab IS TABLE OF c%ROWTYPE; v_tab t_tab; BEGIN OPEN c; LOOP FETCH c BULK COLLECT INTO v_tab LIMIT 5000; EXIT WHEN v_tab.COUNT = 0; FORALL i IN 1..v_tab.COUNT INSERT INTO orders_dw VALUES v_tab(i); END LOOP; COMMIT; END; /

注意FORALL只支持INSERT/UPDATE/DELETE，不支持SELECT，所以抽取和导入要拆成分步操作。

5.5 物化视图刷新失败的常见原因和应对

物化视图在异构场景下比普通视图脆弱，最常见的问题是刷新失败。我遇到过的几种情况：

第一种，源表结构变更。MySQL端某张表加了字段，物化视图定义没动，刷新时Oracle按旧结构去解析远程表，结果报ORA-00904无效列。解决办法没有捷径——DROP MATERIALIZED VIEW再重新创建。所以我历来建议把建视图的SQL维护成脚本文件，方便随时重建。

第二种，刷新任务堆积。如果REFRESH COMPLETE一次执行时间很长，而定时任务间隔又很短，两个刷新任务可能重叠。物化视图刷新默认不允许并发执行，后一个任务会排队等待甚至失败。解决办法是把NEXT间隔设置成大于全量刷新耗时的值。

第三种，ORA-12034物化视图日志过期。异构场景下这个报错较少见，但一旦出现，基本只能删除重建物化视图来恢复。

在处理物化视图问题时，可以通过USER_MVIEW_REFRESH_TIMES视图查看最后一次刷新的时间，确认真实情况：

SELECT mview_name, last_refresh_date, last_refresh_type FROM user_mview_refresh_times;

这段排查经验适用于DBLink同步方案中大部分“视图刷新失败”的场景，先确认源表结构有没有变化，再去查刷新日志，基本都能定位到根因。

最后说点个人体会。DBLink同步MySQL这件事，刚跑通时会觉得配置繁琐得离谱，但一旦把驱动、ODBC、init文件、tnsnames、listener这五层的关系理清楚，后面加表、加库都只是重复劳动。我给团队定了一条规矩：所有需要同步的表，先在MySQL端确保有时间戳字段且建了索引，再谈DBLink同步，不然迟早要为增量同步方案付出代价。这套配置和步骤我已经在多个环境下验证过，从零开始按顺序操作，正常半小时内能跑通第一个查询。如果你在配置过程中遇到奇怪的报错，建议把报错信息连同lsnrctl status和isql测试结果一起整理出来，这类问题九成出在DSN名不一致、操作系统权限、字符集这三件事上。