[AWR]SQL*Net message from dblink等待事件

Inkcup

SQL*Net message from dblink 是一个常见的等待事件，它明确地指出了性能瓶颈的位置：数据库链接。

这个等待事件本身描述的是一个正常操作：本地会话通过数据库链接访问远程数据库，正在等待远程数据库通过网络返回数据。

但是，当它成为系统首要的等待事件时，就意味着应用程序花费了大量时间在等待跨数据库的调用上。 这通常不是数据库链接本身的错误，而是使用方式或远程系统性能的问题。

---------根本原因解释

简单来说，这个等待事件是一个 “信使”等待事件。想象一下：

    你的本地数据库（A）派出一名信使（通过dblink）去远程数据库（B）取一份报告（执行查询）。

    信使出发后，本地数据库（A）的会话就没事可做了，它只能等待（SQL*Net message from dblink）。

    这个等待时间包括了：

        网络传输延迟（信使跑过去和跑回来的时间）。

        远程数据库执行SQL的时间（远程数据库准备报告的时间）。

因此，这个等待事件的总时间 ≈ 网络延迟 + 远程SQL的执行时间。


---------主要原因分析

导致这个等待事件异常高的原因主要有三大类：
1. 网络问题（延迟/带宽）

    高网络延迟：如果本地和远程数据库之间的网络往返时间很长，即使远程查询很快，每次交互也会很慢。

    网络带宽不足：如果查询返回大量的数据（例如，一个没有WHERE子句的查询），低带宽会导致数据传输非常缓慢。

2. 远程SQL语句性能低下（最常见的原因）

这是最可能的原因。通过dblink执行的SQL在远程数据库上可能效率极低，例如：

    缺少合适的索引，导致全表扫描。

    执行了复杂的多表连接，消耗大量资源。

    进行了大规模的数据排序或聚合。

关键点：慢的根源在远程数据库上，但症状表现在本地数据库的等待事件中。
3. 低效的应用程序设计

    在循环中调用dblink：这是一个“致命”的设计。例如，在PL/SQL循环中，为每一行都通过dblink去远程数据库查询一次。这会导致数以千计的网络往返，放大所有问题。

    选择了过多数据：使用 SELECT * ... 并通过dblink传输了大量本地并不需要的列和行。

---------诊断步骤

你需要确定问题是网络慢还是远程SQL慢。

第一步：定位正在通过dblink执行的SQL

在本地数据库的AWR报告或实时监控中，找到通过dblink执行的SQL。

-- 查看当前正在通过dblink执行的SQL
SELECT s.sid, s.username, s.machine, s.program, s.sql_id, t.sql_text
FROM v$session s, v$sql t
WHERE s.sql_id = t.sql_id
AND UPPER(t.sql_text) LIKE '%DBLINK_NAME%'; -- 替换为你的dblink名称


第二步：分析远程SQL的性能

这是最关键的一步。在远程数据库上，获取上一步中找到的SQL的執行計劃。

    1.登录到远程数据库。

    2.使用 SQL_ID 或SQL文本，生成该SQL的執行計劃（AWR报告或 DBMS_XPLAN.DISPLAY_CURSOR）。

    3.检查執行計劃，看是否有全表扫描、低效的连接等。

第三步：评估网络性能

你可以通过一个简单的测试来评估网络和远程数据库的基本性能。在本地数据库执行：

SELECT /*+ NO_RESULT_CACHE */ COUNT(*)
FROM dual@your_dblink_name;

多次执行这个查询，并记录平均时间。这个时间大致反映了网络往返延迟 + 远程数据库解析和执行一个简单查询的开销。

    如果这个时间本身就很长（例如 > 100ms），那么网络延迟可能是主要问题。

    如果这个时间很快，但你的业务SQL很慢，那么问题几乎肯定是远程SQL本身性能低下。

---------解决方案

根据诊断结果，采取针对性措施：
1. 优化远程SQL（最有效的方案）

    在远程数据库上为查询条件列添加索引。

    重写SQL，避免在远程端进行复杂的操作（如排序、聚合）。如果可能，将操作移到本地。

    在远程数据库上收集统计信息，确保优化器能选择最佳執行計劃。

2. 优化应用程序设计

-绝对避免在循环中使用dblink。取而代之，使用 批量操作。

×错误示范（循环）：
BEGIN
  FOR rec IN (SELECT id FROM local_table) LOOP
    SELECT remote_column INTO v_var
    FROM remote_table@dblink
    WHERE remote_id = rec.id; -- 每次循环一次网络往返！
    ...
  END LOOP;
END;

√正确示范（批量）：
BEGIN
  -- 一次网络往返，获取所有数据
  INSERT INTO local_temp_table (id, remote_data)
  SELECT r.id, r.remote_column
  FROM remote_table@dblink r, local_table l
  WHERE r.id = l.id;

  -- 然后在本地处理
  FOR rec IN (SELECT * FROM local_temp_table) LOOP
    ...
  END LOOP;
END;


-减少数据传输量：

        只选择需要的列：SELECT col1, col2 FROM ... 而不是 SELECT * FROM ...。

        在远程端使用 WHERE 子句进行强力过滤，只返回必要的行。

3. 优化网络

    与网络团队合作，检查本地与远程数据库之间的网络路径，确保使用的是低延迟、高带宽的链路。

    确保数据库服务器的网络配置（如TCP参数）是优化的。

4. 使用物化视图（战略性方案）

如果数据不需要实时更新，物化视图 是最佳选择。

    在本地数据库创建一个物化视图，定期从远程数据库刷新数据。

    应用程序直接查询本地的物化视图，完全避免了dblink调用、网络延迟和远程数据库的负载。

    这相当于用存储空间和定期刷新的开销，换取了巨大的性能提升和稳定性。

5. 调整SQL*Net参数（辅助方案）

在数据库专家的指导下，可以调整一些SQL*Net参数，可能会对大量数据传输有所帮助：

    SDU_SIZE：调整会话数据单元大小。

    TDU_SIZE：调整传输数据单元大小。
    通常在数据库链接和监听器的配置中设置。