Как сократить время выполнения моего запроса в базе данных Oracle?

Question

Я извлек эти имена таблиц из разных видов и функций. Время выполнения составляет 1day + для завершения. Моя цель - сократить время от 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" имеет много точек зрения

EXPLAIN PLAN

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 

Answer 1

Ответ был дан в уже комментариях: Вы перекрестно присоединение таблиц.

Сначала вы берете всю запись из таблицы Container в определенный диапазон дат. Скажем, это 200 записей. Затем вы берете все записи из таблицы package. Предположим, что эта таблица содержит 300 записей. Вы объединяете все записи, что дает вам 300 x 200 = 60000 записей. Затем вы берете следующую таблицу и снова умножаете ...

Что можно было бы ожидать, так это то, что таблицы связаны каким-то образом, и поэтому вы должны использовать эти отношения. Предположим, что каждый пакет находится в контейнере. Поэтому каждая запись пакета будет иметь идентификатор контейнера. Вы не хотите, чтобы объединить все пакеты для всех контейнеров, но каждый пакет в один контейнер принадлежит:

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, то СУБД заметило бы свою ошибку и сказал, чтобы присоединиться к записи должным образом, а затем executig бессмыслицы запроса.

---

EDIT: Как для первого запроса вы публикуемыми в вашем редактировании, убедитесь, что все таблицы в поле зрения vw_power_overallyield_batchfe правильно соединены и у вас есть индексы связующих столбцов. Тогда мало что можно сделать. Это может помочь иметь индексы в столбцах даты, поскольку СУБД может решить использовать сканирование индекса диапазона. Вы также можете попытаться выполнить запрос с распараллеливанием (с помощью PARRALLEL HINT).

Линия to_char(scraptxndate, 'MM/DD/YY') <= TXNDATEOUT выглядит подозрительно, кстати. '12/31/14 'будет больше, чем '01/01/15', например. Это не имеет смысла. Разве вы не хотите сравнивать даты, т. Е. scraptxndate <= to_date(TXNDATEOUT,'MM/DD/YY')?