Question

当谈到Oracle 11.2上的v$sql_plan_monitor表时，我遇到了一些奇怪的现象。

我有两张体面的桌子。一个有大约2500万行，另外大约有3500万行，两者都是99％的独特性，只有少数几个重复记录。

解释计划如下（表格名称代替隐私，表格在解释计划之前收集了统计数据）：

--------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                      |       |       | 65611 (100)|          |        |      |            |
|   1 |  SORT AGGREGATE            |                      |     1 |    34 |            |          |        |      |            |
|   2 |   PX COORDINATOR           |                      |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM)     | :TQ10002             |     1 |    34 |            |          |  Q1,02 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE         |                      |     1 |    34 |            |          |  Q1,02 | PCWP |            |
|*  5 |      FILTER                |                      |       |       |            |          |  Q1,02 | PCWC |            |
|*  6 |       HASH JOIN OUTER      |                      |   234K|  7770K| 65611   (1)| 00:19:41 |  Q1,02 | PCWP |            |
|   7 |        PX RECEIVE          |                      |    23M|   513M| 26409   (1)| 00:07:56 |  Q1,02 | PCWP |            |
|   8 |         PX SEND HASH       | :TQ10000             |    23M|   513M| 26409   (1)| 00:07:56 |  Q1,00 | P->P | HASH       |
|   9 |          PX BLOCK ITERATOR |                      |    23M|   513M| 26409   (1)| 00:07:56 |  Q1,00 | PCWC |            |
|* 10 |           TABLE ACCESS FULL| PRETTY_BIG_TABLE     |    23M|   513M| 26409   (1)| 00:07:56 |  Q1,00 | PCWP |            |
|  11 |        PX RECEIVE          |                      |    36M|   384M| 39164   (1)| 00:11:45 |  Q1,02 | PCWP |            |
|  12 |         PX SEND HASH       | :TQ10001             |    36M|   384M| 39164   (1)| 00:11:45 |  Q1,01 | P->P | HASH       |
|  13 |          PX BLOCK ITERATOR |                      |    36M|   384M| 39164   (1)| 00:11:45 |  Q1,01 | PCWC |            |
|* 14 |           TABLE ACCESS FULL| EVEN_BIGGER_TABLE    |    36M|   384M| 39164   (1)| 00:11:45 |  Q1,01 | PCWP |            |
--------------------------------------------------------------------------------------------------------------------------------

给我一些悲伤的数字是Rows步骤的HASH JOIN OUTER值。
甲骨文估计它将输出大约234k行，这是一个相对较小的数量。我知道一个事实是，在过滤结果之前，查询将返回大约50k行，因为它之前已经运行了相同的数据用于测试目的。

*：实际查询本身是一个反连接，使用LEFT JOIN和WHERE来过滤NULL记录。

但是，一旦查询运行，我会检查sql_id表中的v$sql_plan_monitor：

  1  SELECT
  2      plan_line_id,
  3      plan_operation,
  4      ROUND(MAX(plan_cardinality) / 1000) AS est_krows,
  5      ROUND(SUM(output_rows) / 1000) AS actual_krows
  6  FROM v$sql_plan_monitor
  7  WHERE sql_id = 'sql_id_goes_here'
  8  GROUP BY sql_id, sql_exec_id, sql_exec_start, plan_line_id, plan_operation
  9* ORDER BY sql_exec_id, plan_line_id
SQL> /

PLAN_LINE_ID PLAN_OPERATION                  EST_KROWS ACTUAL_KROWS
------------ ------------------------------ ---------- ------------
           0 SELECT STATEMENT                                     0
           1 SORT                                    0            0
           2 PX COORDINATOR                                       0
           3 PX SEND                                 0            0
           4 SORT                                    0            0
           5 FILTER                                               0
           6 HASH JOIN                             234     23084866
           7 PX RECEIVE                          23402        23168
           8 PX SEND                             23402        23168
           9 PX BLOCK                            23402        23168
          10 TABLE ACCESS                        23402        23168
          11 PX RECEIVE                          36699        17772
          12 PX SEND                             36699        17748
          13 PX BLOCK                            36699        17748
          14 TABLE ACCESS                        36699        17748

请注意，查询仍在进行中，因此actual_krows值正在增长。

所以我的问题是：

为什么HASH JOIN的实际行数按五个数量级关闭？
如果能够更精确地估算或更准确地读取实际的行输出进度，我该怎么办？它似乎只给了我关于JOIN的可怕结果，没有别的。

Answer 1

为什么估算错误？

因为理论上，it is impossible to predict if a program will ever finish更不用说预测需要多长时间。实际上，估算很困难，Oracle只有satisficing的时间; Oracle不知道查询是每天提交一次还是每秒提交一千次，并且不能花费大量时间来决定。

我们如何改进估算？

查看整个查询并获得有关表结构和数据分布的一些信息可能会有所帮助。这是很多信息，并不能保证它会有所帮助。相反，这里有一堆方法可能对调整基数很有用。根据您的查询，会话，环境等，并非所有这些都会有所帮助。

ASSOCIATE STATISTICS 评估声明性代码非常困难，在使用过程代码时，Oracle不会太费力地尝试。如果有自定义函数，则默认估计值很差。但您可以指定自定义选择性来更改估算值。在极少数情况下，使用具有相关统计信息的函数替换复杂的SQL表达式可能是值得的。
虚假统计数据 DBMS_STATS.SET_COLUMN_STATS和其他功能可让您将输入更改为估算算法。但请注意，您对此查询的修复不会破坏其他具有完全合理估算的查询。
Extended statistics 正如ibre5041所提到的，列组或表达式可能难以估计。相反，您可以让Oracle收集有关这些组和表达式的统计信息。然后，当它们在查询中使用时，估计可能会好得多。
重写条件某些类型的表达式比其他表达式更难估计。如果可能，尝试重新计算表达式。例如，某些复杂的NVL表达式有时可以使用OR更好地编写。
SQL Profiles ＆＃34; SQL配置文件是包含辅助的数据库对象特定于SQL语句的统计信息。＆＃34;例如，表统计信息可能意味着只有10％的行加入，而配置文件可能会说＆＃34;乘以1000＆＃34;。
未记录的提示 OPT_ESTIMATE和CARDINALITY提示有助于弥补不良估算值。 OPT_ESTIMATE是SQL配置文件使用的，并且是一种很好的方式来表示＆＃34;嘿，将基数提高1000％＆＃34;。 CARDINALITY是一种简单的说法＆＃34;整个查询将返回X行。＆＃34;但这些提示很难使用。
动态采样像`/ * + dynamic_sampling（4）* /这样的提示是告诉优化器的一种方式＆＃34;这是一个昂贵的查询，花时间阅读现有数据，尝试一下，并调整数字＆＃34;。至少，这是理论。在实践中，它并不总是非常有帮助。
基数反馈运行语句两次，如果基数严重错误，Oracle可能会第二次修复它。
自适应查询优化 12c引入了一项功能，其中执行计划偶尔会检查行数，并在估算错误时自行修复。这并不能解决根本原因。而且你还没有。但这听起来很酷，可能是开始考虑升级的一个很好的理由。

我们甚至需要确定估算值吗？

关心基数是明智的。不良基数估计导致许多性能问题。但在许多情况下，基数可能是数量级的错误而且无关紧要。

我没有看到执行计划有任何明显的问题。以正确的方式访问两个大表（如果将使用大多数行，则全表扫描更好），join方法很好（散列连接最适合多行），连接顺序很好（大表是哈希的（即第一个表），探测较大的表（即第二个表）），并行性很好（每个步骤都使用并行性，没有大型行源的广播等）。

如果执行计划是整个故事，我称之为成功。

5个数量级的关闭有时并不重要，特别是当错误接近执行计划的结束时。 234K足以阻止很多错误，例如糟糕的交叉连接。

但是，如果这只是较大查询或视图的一部分，则生成的基数可能会影响其他执行计划。

v $ sql_plan_monitor - 非常不准确的JOIN估计？

1 个答案: