在Oracle中选择查询花费时间

时间:2017-12-20 09:00:36

标签: oracle database-performance oracle12c

我的生产环境中有以下查询

SELECT CIF,
  DECODE( 'INFENG' , '' ,NVL(ALT1_NAME,NAME),NAME),
  DECODE( 'INFENG' , '' ,NVL(ALT1_SHORT_NAME,SHORT_NAME),SHORT_NAME),
  CORP_ID
FROM tb.CMG ,
  tb.SST
WHERE SST.BANK_ID      = '54'
AND CMG.PRIMARY_SOL_ID = SST.SOL_ID
AND SST.SET_ID         = '000'
AND CMG.BANK_ID        = '54'
AND CMG.ENTITY_CRE_FLG = 'Y'
AND EXISTS
  (SELECT 1
  FROM tb.CPHONE
  WHERE CPHONE.PHONE_B2KID = CMG.CIF_ID
  AND PHONENO LIKE '%4444%'
  )
AND CORP_ID IS NULL
AND ROWNUM   < 801
ORDER BY 4

结果需要5分钟以上。查询的解释计划是

  Plan hash value: 4143484456

--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                               | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                        |                          |     1 |   207 |  9732   (1)| 00:00:01 |
|   1 |  SORT ORDER BY                          |                          |     1 |   207 |  9732   (1)| 00:00:01 |
|*  2 |   COUNT STOPKEY                         |                          |       |       |            |          |
|*  3 |    FILTER                               |                          |       |       |            |          |
|   4 |     NESTED LOOPS                        |                          |  4325 |   874K|  5297   (1)| 00:00:01 |
|   5 |      NESTED LOOPS                       |                          | 44112 |   874K|  5297   (1)| 00:00:01 |
|*  6 |       INDEX RANGE SCAN                  | IDX_SOL_ID_SET_TABLE     |     1 |    16 |     1   (0)| 00:00:01 |
|*  7 |       INDEX RANGE SCAN                  | IX_ACCOUNTS_PSOLID       | 44112 |       |     1   (0)| 00:00:01 |
|*  8 |      TABLE ACCESS BY INDEX ROWID        | ACCOUNTS                 |  4325 |   806K|  5296   (1)| 00:00:01 |
|   9 |     NESTED LOOPS SEMI NA                |                          |     1 |    92 |     2   (0)| 00:00:01 |
|* 10 |      TABLE ACCESS BY INDEX ROWID BATCHED| PHONEEMAIL               |     1 |    83 |     1   (0)| 00:00:01 |
|* 11 |       INDEX RANGE SCAN                  | IX_ORGKEY_PHONEEMAILTYPE |     3 |       |     1   (0)| 00:00:01 |
|* 12 |      TABLE ACCESS BY INDEX ROWID BATCHED| NON_CUSTOMERS            |     1 |     9 |     1   (0)| 00:00:01 |
|* 13 |       INDEX RANGE SCAN                  | PK322                    |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(ROWNUM<801)
   3 - filter( EXISTS (SELECT /*+ <not feasible>)
   6 - access("SST"."SET_ID"='000' AND "SST"."BANK_ID"='54')
       filter("SST"."BANK_ID"='54')
   7 - access("ACCOUNTS"."PRIMARY_SOL_ID"=SYS_OP_C2C("SOL_ID") AND "ACCOUNTS"."BANK_ID"=U'54')
   8 - filter("ACCOUNTS"."ENTITY_CRE_FLAG"=U'Y' AND "ACCOUNTS"."CORP_ID" IS NULL)
  10 - filter("PHONEEMAIL"."PHONEOREMAIL"=U'PHONE' AND SUBSTR("PHONENO",1,20) LIKE U'%4444%' AND 
              SUBSTR("PHONENO",1,20) IS NOT NULL AND "SUSPECTID" IS NULL AND "CONTACTID" IS NULL)
  11 - access("PHONEEMAIL"."ORGKEY"=:B1)
  12 - filter("A"."CONVFLAG"=U'N' OR "A"."CONVFLAG" IS NULL)
  13 - access("A"."NONCUSTOMERID"="PHONEEMAIL"."NONCUSTOMERID")

Note
-----
   - dynamic statistics used: dynamic sampling (level=1)
   - this is an adaptive plan
   - 1 Sql Plan Directive used for this statement

有人可以告诉我如何优化此查询以减少执行时间。

我在测试数据库中的日期相同,查询时间不到一分钟。那里的解释计划是

   Plan hash value: 888087711

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                               | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                        |                      |     1 |   296 | 15491   (7)| 00:00:01 |
|   1 |  SORT UNIQUE                            |                      |     1 |   296 | 15490   (7)| 00:00:01 |
|*  2 |   COUNT STOPKEY                         |                      |       |       |            |          |
|   3 |    NESTED LOOPS                         |                      |     1 |   296 | 15489   (7)| 00:00:01 |
|   4 |     NESTED LOOPS                        |                      |     1 |   283 | 15488   (7)| 00:00:01 |
|*  5 |      HASH JOIN RIGHT SEMI NA            |                      |     1 |    92 | 15487   (7)| 00:00:01 |
|*  6 |       TABLE ACCESS STORAGE FULL         | NON_CUSTOMERS        |     9 |    81 |     2   (0)| 00:00:01 |
|*  7 |       TABLE ACCESS STORAGE FULL         | PHONEEMAIL           |   783K|    62M| 15482   (7)| 00:00:01 |
|*  8 |      TABLE ACCESS BY INDEX ROWID BATCHED| ACCOUNTS             |     1 |   191 |     1   (0)| 00:00:01 |
|*  9 |       INDEX RANGE SCAN                  | IX_ACCOUNTS_ORGKEY   |     1 |       |     1   (0)| 00:00:01 |
|* 10 |     INDEX RANGE SCAN                    | IDX_SOL_ID_SET_TABLE |     1 |    13 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(ROWNUM<801)
   5 - access("A"."NONCUSTOMERID"="PHONEEMAIL"."NONCUSTOMERID")
   6 - storage("A"."CONVFLAG"=U'N' OR "A"."CONVFLAG" IS NULL)
       filter("A"."CONVFLAG"=U'N' OR "A"."CONVFLAG" IS NULL)
   7 - storage("PHONEEMAIL"."PHONEOREMAIL"=U'PHONE')
       filter("PHONEEMAIL"."PHONEOREMAIL"=U'PHONE' AND SUBSTR("PHONENO",1,20) LIKE U'%4444%' AND 
              SUBSTR("PHONENO",1,20) IS NOT NULL AND "SUSPECTID" IS NULL AND "CONTACTID" IS NULL)
   8 - filter("ACCOUNTS"."ENTITY_CRE_FLAG"=U'Y' AND "ACCOUNTS"."CORP_ID" IS NULL)
   9 - access("PHONEEMAIL"."ORGKEY"="ACCOUNTS"."ORGKEY" AND "ACCOUNTS"."BANK_ID"=U'54')
  10 - access("SST"."SET_ID"='000' AND "SST"."BANK_ID"='54')
       filter("SST"."BANK_ID"='54' AND "ACCOUNTS"."PRIMARY_SOL_ID"=SYS_OP_C2C("SST"."SOL_ID"))

Note
-----
   - dynamic statistics used: dynamic sampling (level=1)
   - this is an adaptive plan
   - 2 Sql Plan Directives used for this statement

1 个答案:

答案 0 :(得分:0)

您没有提供太多信息(例如,如果查询返回完整的800行或更少,则没有说明,所以无法准确回答。

以下是解决声明问题时应遵循的一些步骤:

<强> 1。了解查询正在做什么

该查询正在加入两个表CMGSST。另外,它会从EXISTSCMG执行CPHOME子查询 (这可能是两张桌子的视图)。 最后,您将结果限制为800行。

<强> 2。找到可接受的执行计划

你应该说服自己哪个执行计划是正确的 - 知道你的数据需要知道。

明显的起点是表CMG(因为它参与了连接和EXISTS子查询)。

问题是接下来该做什么 - 加入或EXISTS条件。您的第一个执行计划首先执行连接,然后解析EXISTS(NESTED LOOPS SEMI)。 漫长的执行时间表明它不行。一种解释是EXISTS非常严格,即CPHONE存在的CMG不多。 因此,您只能通过它们执行大量的连接循环到SST表,因为不存在CPHONE

第二个执行计划支持这个理论,因为它首先执行EXISTS谓词(使用HASH JOIN RIGHT SEMI)而不是连接。

第3。让Oracle执行该执行计划

那么甲骨文为什么不做“正确”的工作呢?书架上写着它 - 这里只有非常基本和明显的东西:

  • 您在两个环境dynamic sampling level 1中使用,这意味着至少有一个表没有优化器统计信息您只使用32个块进行动态采样。

收集丢失的统计信息或者增加DS级别(您可以在查询中使用提示)。

  • 请注意,您在两个环境Sql Plan指令中使用,并且您在测试中有两个,而在prod中只有一个。检查他们试图纠正错误估计的哪一部分。

  • 使用dbms_sqltune.report_sql_monitor运行查询,以查看估算的基数与广告之间的差异 实际基数。