做数据这行时间长了跨库查询这个需求几乎每年都要碰上几回而且场景惊人地固定核心交易跑在 Oracle 上后来新建的报表平台落在了 SQL Server或者反过来老系统是一堆 SQL Server 的存量历史表新平台换成了 Oracle 19c两边都有数据谁也不能立刻下线。这种时候要把两边的数据拉到一起做关联、做核对、做对账就得面对 Oracle 和 SQL Server 中实现跨库查询这件事。这篇文章不讲概念定义我按自己踩过的坑来写Oracle 侧用 Database Link 怎么建、建完为什么查不动SQL Server 侧链接服务器怎么配、为什么同一个查询换个写法从 40 秒变成 1.2 秒异构方向 Oracle 访问 SQL Server 要过哪几道配置关以及一堆报错代码背后的真实原因。做运维的、做数据开发的、做报表的都能直接从里面抄走可用的配置和排查思路。1. 跨库查询的三种形态先分清你在哪一层很多人一说跨库查询就想到 Database Link 和链接服务器其实这个需求内部差异极大分不清形态就会出现杀鸡用牛刀或者工具选错了怎么调都慢的局面。我在动手之前通常先问三个问题这两个库是同一个实例还是不同实例是同一个产品还是不同产品查询是只读还是要写这三个问题的答案基本决定了后面走哪条路。1.1 同实例不同库、同产品跨实例、跨产品异构第一种形态最简单也是被最多人忽略的同一个数据库实例下的不同库或不同用户。SQL Server 里就是SELECT * FROM OtherDB.dbo.OrdersOracle 里就是SELECT * FROM OTHER_SCHEMA.ORDERS本质上是权限问题而不是连接问题。这类查询性能几乎无损唯一要小心的是 SQL Server 不同数据库之间排序规则collation不一致时会报无法解决 equal to 操作的排序规则冲突需要显式加COLLATE。我在做数据仓库分层的时候ODS 和 DWD 分在不同数据库就用这种方式直接跨库写入比走链接服务器快一个量级。第二种是同产品跨实例Oracle 到 Oracle 用 Database LinkSQL Server 到 SQL Server 用链接服务器链路走的是数据库自己的网络协议元数据基本同构类型映射几乎没有损耗这是跨库查询里最顺的一类。第三种是跨产品异构Oracle 查 SQL Server 或者反过来中间必然要过一层 ODBC 或 OLE DB 提供程序类型映射、谓词下推、大字段支持都会打折扣。这一点后面我会专门用一节讲因为绝大多数跨库查询特别慢的抱怨都出在这里。提示先确认形态再选方案。同实例跨库不要配链接服务器那是在给自己加一层网络开销和运维负担。1.2 为什么不建议在应用层用循环拼查询见过太多项目这么干应用先把主表数据查出来拿到一批 ID然后用IN或者循环拼 SQL 去另一个库查明细最后在 Java 代码里做内存关联。这种写法在数据量小的时候看着没问题一旦主表几万行就是几万次网络往返接口响应时间直接从毫秒级跳到分钟级。而且每一次查询都是独立的数据库会话上下文两个库之间没有任何优化器层面的协同等于把所有代价都推给了应用层和网络。数据库自带的跨库能力核心优势不是能查而是让优化器参与进来。链接服务器也好、Database Link 也好远程表的统计信息哪怕不完整优化器至少知道这是一张远程表可以选择把过滤条件推下去、可以选择在远端做完聚合再传结果而不是无脑全量拉回来。这个差别在实际项目里非常夸张我后面会用一个真实案例说明。所以我的原则是能下推到数据库层做的关联就不要在应用层拼。2. Oracle 侧Database Link 从建到用Oracle 的跨库查询主力就是数据库链接Database Link下称 DBLINK。它本质上是当前库里保存的一条到远端库的连接定义包含网络地址、认证方式和目标服务名。查询的时候在表名后面加链接名剩下的交给优化器。搭建过程不复杂但几个参数配置错了会导致查询结果不对或者性能崩掉这部分我有过血泪教训。2.1 三种链接的权限边界与创建语法按归属划分DBLINK 分私有Private、公有Public和全局Global三类。私有链接只有创建者能用适合一对一的临时对接公有链接全库都能引用适合多个应用共用一条链路全局链接主要配合分布式数据库的全局命名使用日常业务里很少碰。我一般优先建私有谁用谁建出问题好定位也避免所有人都挤在一条链路上互相影响。创建私有链接的语法是这样CREATE DATABASE LINK ora_ext_link CONNECT TO remote_user IDENTIFIED BY Pssw0rd_2024 USING ORCL_REMOTE;这里CONNECT TO后面是远端库上的账号USING后面是 tnsnames.ora 里的别名也可以直接写 EZConnect 字符串。公有链接多一个关键字CREATE PUBLIC DATABASE LINK pub_ext_link CONNECT TO remote_user IDENTIFIED BY Pssw0rd_2024 USING ORCL_REMOTE;建完先验证连通性别急着写业务 SQL。我习惯用一句最小查询探测SELECT sysdate FROM dualora_ext_link; SELECT * FROM user_db_links; SELECT owner, db_link, username, host FROM dba_db_links;user_db_links能看到自己的链接dba_db_links需要 DBA 权限。注意all_db_links视图里不显示密码列这是正常的不是配置出错。删除用DROP DATABASE LINK ora_ext_link;公有链接要带PUBLIC关键字。注意IDENTIFIED BY后面如果密码包含特殊字符一定要用双引号包起来否则解析会出错。密码里别用双引号本身那会让转义变得很麻烦。2.2 TNS 别名、EZConnect 与 GLOBAL_NAMES 的坑USING后面写什么是新人最容易卡住的地方。写 tnsnames.ora 里的别名前提是当前库服务器上的 tnsnames.ora 里有对应条目而且TNS_ADMIN指向的目录正确。判断方法很简单在数据库服务器上用tnsping测一下通了说明解析没问题。如果tnsping都通不了那 DBLINK 必然建不起来别浪费时间在 SQL 上折腾。另一种写法是 EZConnect直接把主机端口服务名写进去CREATE DATABASE LINK ora_ext_link CONNECT TO remote_user IDENTIFIED BY Pssw0rd_2024 USING (DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST10.20.30.41)(PORT1521))(CONNECT_DATA(SERVICE_NAMEORCLPDB)));这种写法省去了 tnsnames.ora 的维护但 IP 写死在链接定义里机房调整或者主备切换的时候要重建链接。我的选择是正式环境统一用别名异地临时排查用 EZConnect。GLOBAL_NAMES这个参数必须提一句。它默认为 FALSE一旦被改成 TRUEOracle 就要求 DBLINK 的名字必须和远端数据库的全局名完全一致否则报ORA-02085: database link ... connects to ...。很多规范文档里推荐打开它来避免链路混乱但如果你的链接名是ora_ext_link这种自定义名打开之后全挂。处理方式是在会话级别临时关掉ALTER SESSION SET global_names FALSE;或者在参数文件里改。我个人的做法是DBA 明确要求全局命名规范时才打开否则保持默认链接命名用一套自己的约定比如库名_环境_方向。2.3 同义词与视图让业务 SQL 完全无感直接在业务 SQL 里写empora_ext_link有两个问题一是下游改链路名的时候要全量改代码二是业务开发很容易忘记加查出来的是本库同名表。解决办法是建同义词把远程对象包一层CREATE SYNONYM emp_ext FOR empora_ext_link; CREATE SYNONYM dept_ext FOR remote_user.deptora_ext_link;这样业务 SQL 写SELECT * FROM emp_ext就行链路调整的时候只改同义词应用代码零改动。如果是多表关联或者需要做字段裁剪、类型转换再包一层视图更合适CREATE OR REPLACE VIEW v_emp_detail AS SELECT e.empno, e.ename, d.dname FROM empora_ext_link e JOIN deptora_ext_link d ON e.deptno d.deptno;这里有个性能上的关键点视图里的关联是在本地库完成的优化器会把两个远程表的数据拉回来做连接。如果两张表都很大这就是灾难。更合理的做法是在远端建好视图本地只建一个同义词指向它让过滤和连接在远端完成本地只收结果集。提示DBLINK 上的 DMLINSERT、UPDATE、DELETE语法上支持但性能极差且容易产生分布式事务问题。大批量写入请用 ETL 或者远端存储过程别直接怼 DBLINK。2.4 Oracle 反向访问 SQL ServerHeterogeneous Services 实战Oracle 要查 SQL Server得靠异构服务Heterogeneous Services加上网关组件现在主流是 DG4ODBC。这条路配置环节多我按顺序列一下关键动作每一步都有坑。第一步装 ODBC 驱动。Linux 上装 Microsoft ODBC Driver for SQL ServerWindows 上用系统自带的 ODBC 数据源管理器配一个系统 DSN。Windows 下必须配成系统 DSN配成用户 DSN 的话 Oracle 服务是以系统账户运行的读不到。第二步写$ORACLE_HOME/hs/admin/initSID.oraSID 就是后面监听里要用的名字HS_FDS_CONNECT_INFO MSSQL_DSN HS_FDS_TRACE_LEVEL OFF HS_FDS_SHAREABLE_NAME /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.so HS_LANGUAGE AMERICAN_AMERICA.AL32UTF8第三步改 listener.ora加一个 SID_DESCSID_LIST_LISTENER (SID_LIST (SID_DESC (SID_NAME MSSQLGW) (ORACLE_HOME /u01/app/oracle/product/19c/dbhome_1) (PROGRAM dg4odbc) ) )第四步在 tnsnames.ora 加别名指向这个网关第五步建 DBLINK 指向该别名。这里最容易遇到的就是ORA-28547: connection to server failed, probable Oracle Net admin error这个报错八成不是网络问题而是initSID.ora里的驱动路径写错了或者 ODBC DSN 名字拼错或者监听没有重载配置。每次改完监听都要lsnrctl reload改完init文件要重启监听因为网关进程启动时才读这个文件。查 SQL Server 表的时候语法也要注意SQL Server 的表名和架构名在 Oracle 侧通常需要用双引号包起来SELECT * FROM dbo.Ordersmssqlgw WHERE OrderDate SYSDATE - 7;这里还有个类型映射的坑。SQL Server 的VARCHAR映射到 Oracle 的VARCHAR2INT映射到NUMBER但DATETIME2、UNIQUEIDENTIFIER、NVARCHAR(MAX)这类类型支持得不完整容易报错或者截断。我遇到过最典型的是身份证号、订单号这种长数字串在 SQL Server 里是VARCHAR(18)经过网关拉到 Oracle 后如果中间被当成数字处理就会变成科学计数法尾数丢失看起来像18 位号码末几位全变 0。这种字段在跨库链路上一定要全程用字符串类型传递别让它有任何机会被隐式转成数值。3. SQL Server 侧链接服务器全流程拆解SQL Server 这边的对应机制叫链接服务器Linked Server底层是 OLE DB 提供程序。配置过程比 Oracle 的 DBLINK 稍微啰嗦一点但参数一旦调好查询写法的灵活性反而更高。我把几个关键存储过程和参数拆开讲。3.1 sp_addlinkedserver 参数逐项说明最常用的建法是这个EXEC sp_addlinkedserver server ORCL_LINK, srvproduct Oracle, provider OraOLEDB.Oracle, datasrc ORCL_REMOTE;server是本地给这条链路起的名字随便起但要和后面查询里写的名字一致。srvproduct在产品是 Oracle 的时候可以连提供程序都省掉系统会自动选如果是 SQL Server 到 SQL Server写法就不一样EXEC sp_addlinkedserver server SQLSRV_ERP, srvproduct SQL Server, datasrc 10.20.30.55,1433;注意这里provider和srvproduct都不写走的是 SQL Server 自己的原生客户端。这里有个常见误解很多人以为srvproduct SQL Server时指定的datasrc是实例名其实写 IP 加端口更稳实例名依赖 SQL Browser 服务解析Browser 没开就会报与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。建完之后有几个服务器选项必须调否则性能会很糟EXEC sp_serveroption ORCL_LINK, rpc out, true; EXEC sp_serveroption ORCL_LINK, collation compatible, true; EXEC sp_serveroption ORCL_LINK, data access, true; EXEC sp_serveroption ORCL_LINK, use remote collation, true;rpc out打开之后才能调用远程存储过程做 Oracle 存储过程的封装调用必须开。collation compatible告诉优化器两端排序规则兼容这个开关直接影响谓词能否下推后面性能那一节我会重点讲。3.2 登录映射与安全模式选择建完服务器还要配登录映射否则查询会以匿名方式连远端直接报登录失败EXEC sp_addlinkedsrvlogin rmtsrvname ORCL_LINK, useself FALSE, rmtuser remote_user, rmtpassword Pssw0rd_2024;useself FALSE表示用这里指定的固定账号去连远端这也是最常用的模式。如果设成 TRUESQL Server 会拿当前登录的 Windows 凭据去做委派需要配置 Kerberos 委派链路一长就容易失败我一般不推荐在跨库场景里用。还有一种写法是locallogin指定特定本地账号映射到特定远端账号做细粒度权限隔离的时候有用。密码在这一步是明文写在存储过程里的虽然存储之后会被加密存放但执行语句很可能落在日志、脚本库或者工单系统里。我的习惯是配置脚本不落版本库用一次性执行的临时脚本执行完删掉或者干脆用useself配合服务账户。安全审计严格的场景远程账号只给目标表的 SELECT 权限绝不给任何 DDL 权限这是底线。3.3 四种查询写法与各自的适用场景SQL Server 跨库查询有四种主流写法搞不清区别就会写出性能极差的语句。第一种是四部分命名SELECT * FROM ORCL_LINK.REMOTE_USER.EMP WHERE DEPTNO 10;这种写法最直观但优化器拿到的是一个远程表它不知道远端的数据分布很多情况下会把整张表拉回本地再过滤。第二种是 OPENQUERY把整段 SQL 发给远端执行SELECT * FROM OPENQUERY(ORCL_LINK, SELECT * FROM EMP WHERE DEPTNO 10);这种写法的优势极其明显过滤是在远端完成的本地只收 10 号部门的结果。代价是这段 SQL 的语法必须符合远端数据库的规则Oracle 里写SYSDATESQL Server 里写GETDATE()不能混用。第三种是 OPENROWSET适合临时、一次性的查询不需要预先建链接服务器SELECT * FROM OPENROWSET( OraOLEDB.Oracle, ORCL_REMOTE;remote_user;Pssw0rd_2024, SELECT * FROM EMP WHERE DEPTNO 10);要能这么用得先打开Ad Hoc Distributed Queries配置项这个开关有安全风险生产环境默认是关的用完记得关回去。第四种是 OPENDATASOURCE和 OPENROWSET 类似一般只在临时排查时用。提示日常开发我基本只用 OPENQUERY 一种。四部分命名在关联查询里看着优雅但性能不可控除非你确定远程表很小。3.4 连 Oracle 时提供程序怎么选SQL Server 访问 Oracle可选OraOLEDB.OracleOracle 官方提供程序和MSDAORA微软自带早已停止更新。只选 OraOLEDBMSDAORA 在新版本 Windows 上经常装不上或者连不上而且不支持较新的 Oracle 类型。装 OraOLEDB 要注意版本对齐64 位的 SQL Server 必须配 64 位的提供程序装成 32 位的话在 SSMS 里能看到链接服务器但查询时报7302或7303错误。还有个小坑Oracle 客户端安装时要勾选Oracle Provider for OLE DB组件默认安装是不带的。装完之后建议在服务器上先用一段 VBScript 或者简单的 OLE DB 测试工具验证一下提供程序可用再去 SSMS 里配链接服务器不然报错信息会绕一大圈才能定位到根因。3.5 分布式事务与 MSDTC 配置跨库写操作会牵出分布式事务的问题。SQL Server 在链接服务器上执行 UPDATE、INSERT 时如果涉及事务提升会尝试启动分布式事务报错信息通常是7391: 无法启动分布式事务。解决方式是两台服务器都开启 MSDTC并在本地 DTC和入站/出站事务里做互相允许的配置Windows 防火墙要放行相关端口。我的建议是能不用就不用。跨库写操作本来就应该谨慎把写操作拆成远端执行 本地记录两步或者干脆用 ETL 工具做定时同步比在两台服务器之间维持分布式事务简单得多。分布式事务一旦卡住排查成本极高而且容易在高峰期造成连接池堆积。4. 性能跨库查询慢的根因和四招应对跨库查询的性能问题归根结底就一句话优化器看不清楚远端的数据。本地优化器对远程表的统计信息几乎是空白只能用一个很小的估算值去猜行数猜错了执行计划就全错。理解了这一点所有的优化手段都清楚了。4.1 远程扫描、本地扫描与执行计划怎么看打开执行计划看跨库查询你会看到远程查询和远程扫描这类算子。区别在于远程查询算子表示 SQL Server 把整条语句发给了远端远端执行完返回结果这通常是最好的情况远程扫描算子表示 SQL Server 让远端把整张表的数据传回来然后在本地做过滤、连接、排序这是最差的情况。我见过一张 200 万行的表因为写法不对每次查询都从 Oracle 往 SQL Server 传 200 万行网络带宽跑满查询 40 秒。判断方法很直接在执行计划里把鼠标悬停在远程算子上看实际行数和估计行数。如果远端返回的行数远大于最终结果行数说明谓词没有下推。这种情况换 OPENQUERY 写法把 WHERE 条件写进远端 SQL 里立刻见效。4.2 谓词下推、OPENQUERY 与 collation compatible谓词下推能不能成功取决于三个条件写法是否支持、提供程序是否支持、排序规则是否兼容。写法上OPENQUERY 一定下推四部分命名看情况。提供程序上OraOLEDB.Oracle的下推能力比MSDAORA好。排序规则上collation compatible设为 TRUE 之后SQL Server 才敢放心地把字符串比较推到远端执行否则它担心两端排序规则不一致导致结果不对只能拉回本地比。这三条里最容易漏掉的是第三条。我遇到过一次同一个查询改成 OPENQUERY 之后快了但一个带字符串等值连接的查询还是慢。后来发现就是这个选项没开打开后执行计划从远程扫描变成了远程查询耗时从 22 秒掉到 3 秒。4.3 统计信息缺失导致的 N 次往返比全量拉取更隐蔽的一种慢是嵌套循环加远程查找。现象是小表做驱动表大表做被驱动表优化器按每行一次远程调用的方式执行一万行就是一万次网络往返。每次往返哪怕只有 20 毫秒累计也是 200 秒。执行计划里表现为嵌套循环算子下面挂一个远程查询并且执行次数等于驱动表的行数。解决思路有三种。第一种把被驱动表的必要字段用 OPENQUERY 一次性拉到本地临时表再和本地表关联牺牲一点内存换网络往返。第二种改成哈希连接提示SELECT * FROM dbo.LocalTable l JOIN OPENQUERY(ORCL_LINK, SELECT * FROM EMP) r ON l.empno r.EMPN O OPTION (HASH JOIN);第三种也是最彻底的把过滤条件下推到远端让远端先缩到几万行再参与连接。我一般按这个顺序试多数情况下第一种就能解决。4.4 一个从 40 秒压到 1.2 秒的实际案例说个上个月刚处理的。客户 SQL Server 2019 通过链接服务器查 Oracle 19c 的订单表做每天的对账报表。原写法是四部分命名关联本地客户表SELECT c.CustName, o.OrderNo, o.Amount FROM dbo.Customer c JOIN ORCL_LINK.ERP.ORDERS o ON c.CustId o.CUST_ID WHERE o.ORDER_DATE 2024-05-01;跑一次 40 秒左右执行计划显示远程扫描返回了 1800 万行本地做过滤和连接网络传输量接近 1GB。改造分三步先把日期条件下推到远端用 OPENQUERY 只取当月数据再把链接服务器的collation compatible打开最后在远端 Oracle 的ORDERS表上确认ORDER_DATE和CUST_ID两个字段有索引。改造后的写法SELECT c.CustName, o.OrderNo, o.Amount FROM dbo.Customer c JOIN OPENQUERY(ORCL_LINK, SELECT ORDER_NO, CUST_ID, AMOUNT FROM ERP.ORDERS WHERE ORDER_DATE DATE 2024-05-01) o ON c.CustId o.CUST_ID OPTION (HASH JOIN);注意 OPENQUERY 里字符串里的单引号要用两个单引号转义这是最容易写错的地方。改造后耗时 1.2 秒网络传输量降到 3MB 左右。这里有个细节值得说即使下推成功OPTION (HASH JOIN)也不是必须的但如果本地客户表行数较多加上它会更稳避免优化器又选回嵌套循环。5. 报错速查与排查路径跨库查询的报错信息普遍不友好一个错误码背后可能有五六个原因。我把高频的几个整理成表配合我自己的定位顺序能省掉大量试错时间。5.1 Oracle 侧高频错误错误码常见原因定位动作ORA-02019找不到数据库链接确认链接名拼写、是否为私有链接、当前用户是否有权限ORA-12154无法解析服务名在数据库服务器上执行tnsping 别名检查 TNS_ADMIN 和 tnsnames.oraORA-02085全局命名冲突检查global_names参数或把链接名改成和远端全局名一致ORA-28547网关连接失败检查initSID.ora里的驱动路径、ODBC DSN 名改完要重启监听ORA-28040认证协议版本不匹配通常是客户端和数据库版本差异过大调整SQLNET.ALLOWED_LOGON_VERSION_SERVERORA-03113通信通道结束检查防火墙是否中断长连接、远端是否有资源限制ORA-28547这个我在异构配置里专门提过它和Oracle 监听服务无法启动经常一起出现。监听起不来的常见原因是端口被占、listener.ora语法错误、或者ORACLE_HOME环境变量没设对。定位顺序是先用lsnrctl status看能不能连上监听再用lsnrctl start看报什么错最后查监听日志文件日志里的信息比屏幕输出详细得多。5.2 SQL Server 侧高频错误错误码常见原因定位动作7302提供程序未正确注册确认 64 位提供程序已安装并在 SSMS 里可见7303提供程序初始化失败检查提供程序版本与 SQL Server 位数是否一致7399提供程序报错看是否认证失败、远端服务未启动逐步用测试连接验证7391分布式事务无法启动检查两台机器的 MSDTC 配置和防火墙17051SQL Server 版本评估期已过这是评估版授权到期和跨库无关但会拦住整个实例53 / 258网络或实例名解析失败改用 IP端口检查 Browser 服务17051这个错误码值得单独说一句因为它看起来像跨库配置问题实际上和链接服务器一点关系都没有是实例本身的评估版授权到期服务根本起不来所有查询都失败。判断方法很简单错误发生在所有连接上而不是只有跨库查询那就要往实例级别的问题去想别在链接服务器上浪费时间。5.3 一套通用的三分钟定位法报错出来先别慌按这个顺序走能定位到九成的问题。第一步把跨库这一层剥掉直接在远端数据库上用同样的条件跑一遍 SQL确认远端本身没问题、有权限、数据在。第二步从最简查询开始SELECT COUNT(*) FROM OPENQUERY(...)一步步加条件、加字段、加关联找到第一个失败或者变慢的点。第三步检查链路配置本身用sp_testlinkedserver测连接EXEC sp_testlinkedserver ORCL_LINK;或者用 Oracle 侧的SELECT 1 FROM dualdblink。第四步把执行计划打开看远程算子返回的实际行数。这四步走完问题基本就露出水面了。我特别强调第一步因为大量所谓的跨库问题其实是远端权限或者数据问题剥离链路验证能立刻排除一半可能。6. 实操心得什么时候该用什么时候必须绕开配置层面的东西讲完了最后聊聊选型。技术手段都有适用边界跨库查询不是万能的用错地方会变成长期的技术债。6.1 选型红线跨库查询适合的场景有三类低频的核对和排查、数据量小且能下推的实时查询、临时的数据抽取验证。反过来这几种情况我强烈建议绕开高频交易类接口依赖跨库查询、大数据量关联分析、需要跨库写事务一致性、需要毫秒级响应的场景。高频接口依赖跨库查询是最典型的坑。链路抖动一次整个业务就跟着抖。我见过一个订单查询接口直接查了远端库远端做维护窗口的时候本地接口全量超时。正确做法是把远端数据同步到本地一份用 CDC 或者定时 ETL 保持准实时接口只查本地表。跨库查询留给运维和数据分析用不要放在业务主链路上。大数据量关联分析也别硬上。跨库查询的网络传输量是真正的瓶颈源端加索引、谓词下推这些手段能把数据量压下去但一旦结果集本身就是百万行级别怎么优化都传不动。这种情况应该用数据同步工具先把数据整表搬到数仓再在同一个库内做分析反而更快。6.2 安全与运维上的几条硬规矩第一条远程账号用最小权限。只给需要的那几张表的 SELECT并且用独立的只读账号不要复用业务账号更不要给 DBA 账号。原因很简单链接服务器和 DBLINK 里的凭据一旦泄露等于把远端库的入口交出去了而且跨库查询出问题时一个权限过大、能改数据的链路排查起来要命。第二条密码管理和链路治理要有台账。链路名、方向、用途、创建人、关联的业务方都记下来。我见过一个库里有三十多条 DBLINK没人知道哪条还在用谁都不敢删。这种状态持续下去后面接手的同事只能靠猜。定期用dba_db_links和sys.servers拉一遍清单和台账对一下对不上的就查。第三条监控链路状态。跨库查询的性能劣化往往是缓慢的等业务方反馈的时候通常已经影响一段时间了。可以做个简单巡检脚本定时跑sp_testlinkedserver记录响应时间一旦某条链路响应时间从 10 毫秒涨到 500 毫秒说明后面有东西变了可能是远端数据量涨了、索引失效了、或者网络链路有抖动。这类问题提前发现比事后救火便宜太多。第四条关于数据类型必须留个心眼。跨库链路上的隐式类型转换是最阴险的问题因为它不报错只给你一个看似正常但实际错误的结果。前面提到的身份证号变科学计数法就是一例金额字段因为精度映射丢小数也是常见情况。我自己的习惯是跨库传输的字段凡是 ID、编号、金额、证件号这类敏感数据全部显式转成字符串或者是高精度类型传递并且在链路刚建好的时候用几条真实数据做校验比对两端的值是否完全一致。这个动作花十分钟能省掉后面几天的对账排查。第五条版本升级前把链路全部测一遍。数据库版本升级、操作系统补丁、ODBC 驱动更新任何一个环节变动都可能让原本好用的链路失效。我们这边做过一次 SQL Server 从 2016 升到 2019 的变更升级之后有两条 Oracle 链接服务器的查询突然变慢最后查出来是提供程序版本没跟着升走的还是老驱动。这种问题在升级方案里预留验证时间比事后回滚划算得多。我个人在跨库查询这件事上的体会是搭建本身从来不是难点难的是让它长期稳定、性能可预期。把配置做对只用一天把监控和治理做起来才是长期功夫。链路这东西能少一条就少一条每多一条就多一个半夜被叫起来的机会。真要做跨库分析我更倾向于把数据先落到一个地方而不是让两个库在运行时互相依赖。
