如何在Oracle数据库中减少查询的执行时间?

时间:2015-07-10 07:39:49

标签: sql oracle database-performance

我从不同的视图和函数中提取了这些表名。执行时间需要1天+才能完成。我的目标是将时间从1天缩短到30分钟或更短。我的老板建议我在视图下调整视图内的所有查询。关于如何缩短时间的任何提示或建议?

查询

SELECT to_char(con.originalstartdate, 'MM/DD/YY') TXNDATEIN,
       to_char(con.originalstartdate, 'HH24:MI:SS') TIMEIN,
       to_char(CON.LASTACTIVITYDATE, 'MM/DD/YY') TXNDATEOUT,
       to_char(con.lastactivitydate, 'HH24:MI:SS') TIMEOUT,
       pack.mes_packagename, prodfam.productfamilyname,
       con.containername RELATEDCONTNAME, shd.qty QTYIN, 
       con.qty QTYOUT, qtyhist.qty, lossrea.lossreasonname,
       resdef.resourcename WS, emp.fullname EMPLOYEENAME,
       oprtn.operationname, hml.txndate,
       (   SELECT GET_DIFFUSION_CONTAINER_APP(con.containername) 
           FROM DUAL) AS DIFFUSION
FROM container con, package pack, productfamily prodfam, 
     lossreason lossrea, resourcedef resdef, employee emp, 
     operation oprtn, qtyhistory qtyhist, splithistorydetails shd,
     historymainline hml
where con.lastactivitydate >=  to_date('06/23/2014 6:00:00', 'MM/DD/YYYY HH:MI:SS')
and con.lastactivitydate < to_date('06/24/2014 6:00:00', 'MM/DD/YYYY HH:MI:SS')
and hml.txndate >= to_date('06/23/2014 6:00:00', 'MM/DD/YYYY HH:MI:SS') 
and to_char(hml.txndate, 'MM/DD/YYYY') <= to_char(con.lastactivitydate, 'MM/DD/YYYY')
ORDER BY RELATEDCONTNAME;

ORIGINAL QUERY

SET ECHO OFF
SET COLSEP ,
SET PAGES 0
SET LINESIZE 1000
SET TRIMSPOOL ON
SET FEEDBACK OFF
SET UNDERLINE OFF
SET VER OFF

column NCURRENT NEW_VALUE VFILE NOPRINT
column NYEST NEW_VALUE VFILE2  
column NNOW NEW_VALUE VFILE3  
column NCURRENTYEAR NEW_VALUE VFILE4  
column WEEKCODE NEW_VALUE VFILE5 

select to_char(sysdate -2 , 'RRRR-MM-DD')||' 06:00:00' NYEST
--select '2013-05-18 12:00:00' NYEST
from dual;

select to_char(sysdate-1, 'RRRR-MM-DD')||' 06:00:00' NNOW
--select '2013-05-19 12:00:00' NNOW
from dual;

select to_char(sysdate, 'RRRR') NCURRENTYEAR
from dual;

select 'FName_'||to_char(sysdate-1, 'MONDDRRRR')||'.csv' NCURRENT
from dual;

spool [Filepath];

select 
       TXNDATEIN||','||TIMEIN||','||TXNDATEOUT||','||TIMEOUT||','||  MES_PACKAGENAME||','||MINICOMPANYNAME||','||PRODUCTFAMILYNAME||','||RELATEDCONTNAME||','||
       QTYIN||','||QTYOUT||','||QTY||','||LOSSREASONNAME||','||WS||','||REPLACE(EMPLOYEENAME,',',' ')||','||OPERATIONNAME||','||
       (SELECT GET_DIFFUSION_CONTAINER_APP(RELATEDCONTNAME) FROM DUAL) AS DIFFUSION
from 
 vw_power_overallyield_batchfe
where 
txndate >=  to_date('&&VFILE2', 'yyyy-mm-dd HH24:MI:SS')
and txndate < to_date('&&VFILE3', 'yyyy-mm-dd HH24:MI:SS')
and scraptxndate >= to_date('&&VFILE2', 'yyyy-mm-dd HH24:MI:SS') 
and to_char(scraptxndate, 'MM/DD/YY') <= TXNDATEOUT 
ORDER BY RELATEDCONTNAME;
spool off;
exit
  • “vw_power_overallyield_batchfe”有很多观点

分析计划

    PLAN_TABLE_OUTPUT

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)|
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |                          |    18E|    15E|       |    18E  (0)|
|   1 |  FAST DUAL                             |                          |     1 |       |       |     2   (0)|
|   2 |  SORT ORDER BY                         |                          |    18E|    15E|    15E|    18E  (0)|
|   3 |   MERGE JOIN CARTESIAN                 |                          |    18E|    15E|       |    18E  (0)|
|   4 |    MERGE JOIN CARTESIAN                |                          |    18E|    15E|       |    18E  (0)|
|   5 |     MERGE JOIN CARTESIAN               |                          |    18E|    15E|       |   204P  (1)|
|   6 |      MERGE JOIN CARTESIAN              |                          |    54T|  5457T|       |   521G  (1)|
|   7 |       MERGE JOIN CARTESIAN             |                          |    84G|  7259G|       |   942M  (1)|
|   8 |        MERGE JOIN CARTESIAN            |                          |    17M|  1258M|       |   210K  (1)|
|   9 |         MERGE JOIN CARTESIAN           |                          |  8713 |   536K|       |    87   (3)|
|  10 |          MERGE JOIN CARTESIAN          |                          |    16 |   816 |       |    16  (13)|
|  11 |           MERGE JOIN                   |                          |     1 |    43 |       |    13  (16)|
|  12 |            SORT JOIN                   |                          |     3 |    24 |       |     5  (20)|
|* 13 |             INDEX RANGE SCAN           | HISTORYMLBYTXNDATEANDRES |     3 |    24 |       |     4   (0)|
|* 14 |            SORT JOIN                   |                          |     4 |   140 |       |     8  (13)|
|  15 |             TABLE ACCESS BY INDEX ROWID| CONTAINER                |     4 |   140 |       |     7   (0)|
|* 16 |              INDEX RANGE SCAN          | CONTAINERBYLADATE        |     5 |       |       |     3   (0)|
|  17 |           BUFFER SORT                  |                          |    25 |   200 |       |     9  (23)|
|  18 |            TABLE ACCESS FULL           | PACKAGE                  |    25 |   200 |       |     3   (0)|
|  19 |          BUFFER SORT                   |                          |   552 |  6624 |       |    84   (3)|
|  20 |           TABLE ACCESS FULL            | RESOURCEDEF              |   552 |  6624 |       |     4   (0)|
|  21 |         BUFFER SORT                    |                          |  2020 | 24240 |       |   210K  (1)|
|  22 |          TABLE ACCESS FULL             | PRODUCTFAMILY            |  2020 | 24240 |       |    24   (0)|
|  23 |        BUFFER SORT                     |                          |  4814 | 81838 |       |   942M  (1)|
|  24 |         TABLE ACCESS FULL              | EMPLOYEE                 |  4814 | 81838 |       |    54   (2)|
|  25 |       BUFFER SORT                      |                          |   638 | 12122 |       |   521G  (1)|
|  26 |        TABLE ACCESS FULL               | OPERATION                |   638 | 12122 |       |     6   (0)|
|  27 |      BUFFER SORT                       |                          |   411K|  2009K|       |   204P  (1)|
|  28 |       TABLE ACCESS FULL                | SPLITHISTORYDETAILS      |   411K|  2009K|       |  3785   (1)|
|  29 |     BUFFER SORT                        |                          |  1171K|  5720K|       |    18E  (0)|
|  30 |      TABLE ACCESS FULL                 | QTYHISTORY               |  1171K|  5720K|       |  4690   (1)|
|  31 |    BUFFER SORT                         |                          |  1382 | 13820 |       |    18E  (0)|
|  32 |     TABLE ACCESS FULL                  | LOSSREASON               |  1382 | 13820 |       |     4   (0)|
----------------------------------------------------------------------------------------------------------------

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

  13 - access("HML"."TXNDATE">=TO_DATE(' 2014-06-23 06:00:00', 'syyyy-mm-dd hh24:mi:ss') AND 
              "HML"."TXNDATE" IS NOT NULL)
  14 - access(TO_CHAR(INTERNAL_FUNCTION("HML"."TXNDATE"),'MM/DD/YYYY')<=TO_CHAR(INTERNAL_FUNCTION("CON".
              "LASTACTIVITYDATE"),'MM/DD/YYYY'))
       filter(TO_CHAR(INTERNAL_FUNCTION("HML"."TXNDATE"),'MM/DD/YYYY')<=TO_CHAR(INTERNAL_FUNCTION("CON".
              "LASTACTIVITYDATE"),'MM/DD/YYYY'))
  16 - access("CON"."LASTACTIVITYDATE">=TO_DATE(' 2014-06-23 06:00:00', 'syyyy-mm-dd hh24:mi:ss') AND 
              "CON"."LASTACTIVITYDATE"<TO_DATE(' 2014-06-24 06:00:00', 'syyyy-mm-dd hh24:mi:ss'))

Note
-----
   - 'PLAN_TABLE' is old version

enter code here

1 个答案:

答案 0 :(得分:1)

答案已在评论中给出:您正在交叉加入您的表格。

首先,您要在特定日期范围内从表Container获取所有记录。让我们说这是200条记录。然后从表package中获取所有记录。假设此表包含300条记录。您组合所有记录,为您提供300 x 200 = 60000条记录。然后你拿下一张桌子并再次繁殖,......

人们所期望的是表格是以某种方式相关的,因此你会使用这些关系。假设每个包都驻留在一个容器中。因此,每个包记录都有一个容器ID。您不希望将所有包加入所有容器,而是将每个包连接到它所属的一个容器:

FROM container con 
JOIN package pack ON pack.container_id = con.id

FROM container con, package pack 
WHERE pack.container_id = con.id

但你不应该。这种容易出错的隐式连接语法在二十多年前被上面提到的显式连接所取代。如果您已经使用过

FROM container con 
JOIN package pack

没有ON子句,那么DBMS会注意到你的错误并告诉你正确加入记录而不是执行无意义的查询。

编辑:对于您在编辑中发布的原始查询,请确保vw_power_overallyield_batchfe视图中的所有表都已正确连接,并且您在链接列上有索引。然后你几乎无能为力。由于DBMS可能决定使用范围索引扫描,因此在日期列上建立索引可能会有所帮助。您还可以尝试执行并行化查询(使用PARRALLEL HINT)。

to_char(scraptxndate, 'MM/DD/YY') <= TXNDATEOUT看起来很可疑,顺便说一下。例如,'12 / 31/14'将大于'01 / 01/15'。这似乎没有意义。您不想比较日期,即scraptxndate <= to_date(TXNDATEOUT,'MM/DD/YY')