性能调优技巧-Plsql/sql-Database答案

【问题标题】：Performance tuning tips -Plsql/sql-Database性能调优技巧-Plsql/sql-Database
【发布时间】：2016-08-16 22:05:58
【问题描述】：

我们在生产中面临性能问题。 mv referh 程序运行时间很长，差不多 13 到 14 个小时。

在 MV 中引用程序正在尝试引用 5 个 MV。其中一个MV是长期运行的。

下面是长期运行的MV脚本。

SELECT rcvt.transaction_id,
    rsh.shipment_num,
    rsh.shipped_date,
    rsh.expected_receipt_date,
    (select rcvt1.transaction_date from rcv_transactions rcvt1
    where rcvt1.po_line_id = rcvt.po_line_id
    AND rcvt1.transaction_type   = 'RETURN TO VENDOR'
    and rcvt1.parent_transaction_id=rcvt.transaction_id
    )transaction_date
  FROM rcv_transactions rcvt,
    rcv_shipment_headers rsh,
    rcv_shipment_lines rsl
  WHERE 1                     =1
  AND rcvt.shipment_header_id =rsl.shipment_header_id
  AND rcvt.shipment_line_id   =rsl.shipment_line_id
  AND rsl.shipment_header_id  =rsh.shipment_header_id
  AND rcvt.transaction_type   = 'RECEIVE';

Shipment 表包含数百万条记录，以上查询试图提取几乎 60% 到 70% 的数据。我们怀疑数据负载是原因。我们正在努力提高上述脚本的性能。所以我们添加了日期过滤器来限制数据。

SELECT rcvt.transaction_id,
    rsh.shipment_num,
    rsh.shipped_date,
    rsh.expected_receipt_date,
    (select rcvt1.transaction_date from rcv_transactions rcvt1
    where rcvt1.po_line_id = rcvt.po_line_id
    AND rcvt1.transaction_type   = 'RETURN TO VENDOR'
    and rcvt1.parent_transaction_id=rcvt.transaction_id
    )transaction_date
  FROM rcv_transactions rcvt,
    rcv_shipment_headers rsh,
    rcv_shipment_lines rsl
  WHERE 1                     =1
  AND rcvt.shipment_header_id =rsl.shipment_header_id
  AND rcvt.shipment_line_id   =rsl.shipment_line_id
  AND rsl.shipment_header_id  =rsh.shipment_header_id
  AND rcvt.transaction_type   = 'RECEIVE'
    AND TRUNC(rsh.creation_date)  >=  NVL(TRUNC((sysdate - profile_value),'MM'),TRUNC(rsh.creation_date) );

对于 1 年的概况，它显示出一些改进，但如果我们给出 2 年的范围，它比以前的查询更差。

任何改进性能的建议。

请帮忙

【问题讨论】：

那么，您是否运行过基本的分析工具，例如解释计划、tkprof 和 ADDM 报告？在没有深入了解您的系统、环境和许多其他细节的情况下，这里没有人会通过查看一些查询来诊断您的性能问题。对不起。
您是否在进行增量刷新？还是全面刷新？第二种方法显然需要完全刷新，因为您引用的是非确定性函数调用 (sysdate)。第一个可能会根据源表上的 MV 日志进行增量刷新（我只是不确定内联子查询，而不仅仅是进行外部联接或将其分解）。通常，MV 将用于聚合数据或从远程数据库复制数据，但我看不到任何数据库链接或聚合函数。
@JustinCave 感谢您的更新。我们正在进行完全刷新而不是快速刷新。原因是每天平均 10k 条记录会插入到基表中，如果我们使用快速引用会降低系统性能。
@OldProgrammer 感谢更新。是的，我们分析了解释计划/AWR 报告。由于我在安全网络中工作，我无法分享解释计划/awr 报告
你用物化视图做什么？聚合？还是复制？我没有看到任何数据库链接，也没有看到任何聚合函数。如果您无法提供查询计划或有关您的等待事件的任何信息，并且您不想考虑进行增量刷新（每天 10,000 次更改对于我的笔记本电脑来说是一个微不足道的数字），我不确定是什么除了建议重组为多个 MV 之外，我们还可以为您做。

标签： oracle performance sql-tuning database-tuning

【解决方案1】：

我会将该标量子查询提取到常规外部联接中。

标量子查询的成本可以是poor，您会强制它进行大量单条记录查找（可能是通过索引），而不是为其提供其他选项。

“然后主查询在选择列表中有一个标量子查询。

因此，Oracle 在计划表中显示了两个独立的计划。一个用于驱动查询 - 成本为 2，一个用于标量子查询，每次执行的成本为 2083。

但是 Oracle 不“知道”标量子查询将运行多少次（即使在许多情况下它可以预测最坏的情况），并且在查询。”

【讨论】：

您可能会考虑将您的答案标记为与 11g 及更早版本相关。在 Oracle 12c 中，优化器可以取消嵌套标量子查询并将它们转换为（通常）散列连接。