Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Проблема со скоростью исполнения запроса  [new]
padavan
Member [заблокирован]

Откуда:
Сообщений: 4795
Есть 2 идентичные(по структуре и по индексам) таблицы: f_deal(11Гб) и f_deal_new(19Гб). Таблица f_deal_new просто содержит некоторые "архивные" данные. Была поставлена задача долить эти данные в боевую таблицу f_deal. При попытке произвести загрузку появились сильные проблемы со скоростью выполнения запросов. Вот пример одного из подобных "проблемных" запросов:

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
 
SQL> explain plan for
  2  Select count(*)
  from f_deal_new n
 where trunc(n.date_lst_mntd) >= to_date('01.07.2007', 'DD.MM.YYYY')
   and trunc(n.date_lst_mntd) <= to_date('31.07.2007', 'DD.MM.YYYY')
   and n.deal_mod_desc = 'YWZ'
   and n.st_hst = 'Y'
   and n.oper_type <> 'A5'
   and not exists (select 1
          from f_deal partition(p_st_hst_y) d
         where n.deal_id = d.deal_id
           and n.oper_type = d.oper_type
           and n.date_lst_mntd = d.date_lst_mntd
           and n.st_hst = d.st_hst)
           ;  3    4    5    6    7    8    9   10   11   12   13   14   15
 
Explained.
SQL> 
SQL> select * from table (sys.dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------------------
 
-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                           |  Name               | Rows  | Bytes |TempSpc| Cost  | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                     |     1 |    53 |       | 29935 |       |       |
|   1 |  SORT AGGREGATE                     |                     |     1 |    53 |       |       |       |       |
|*  2 |   FILTER                            |                     |       |       |       |       |       |       |
|*  3 |    TABLE ACCESS BY LOCAL INDEX ROWID| F_DEAL_NEW          |  4606 |   238K|       | 29930 |     2 |     2 |
|   4 |     BITMAP CONVERSION TO ROWIDS     |                     |       |       |       |       |       |       |
|   5 |      BITMAP AND                     |                     |       |       |       |       |       |       |
|*  6 |       BITMAP INDEX SINGLE VALUE     | F_DEAL_NEW_MOD_BIT  |       |       |       |       |     2 |     2 |
 
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------------------
|   7 |       BITMAP CONVERSION FROM ROWIDS |                     |       |       |       |       |       |       |
|   8 |        SORT ORDER BY                |                     |       |       |  6248K|       |       |       |
|*  9 |         INDEX RANGE SCAN            | F_DEAL_NEW_DATE     |   343K|       |       |   916 |     2 |     2 |
|* 10 |    TABLE ACCESS BY LOCAL INDEX ROWID| F_DEAL              |     1 |    43 |       |     5 |     2 |     2 |
|* 11 |     INDEX RANGE SCAN                | PK_F_DEAL_P1_D_S    |     1 |       |       |     4 |     2 |     2 |
-------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "F_DEAL" "D" WHERE "D"."OPER_TYPE"=:B1 AND "D"."DEAL_ID"=:B2 AND
 
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------------------
              "D"."DATE_LST_MNTD"=:B3 AND "D"."ST_HST"=:B4))
   3 - filter("SYS_ALIAS_4"."ST_HST"='Y' AND "SYS_ALIAS_4"."OPER_TYPE"<>'A5')
   6 - access("SYS_ALIAS_4"."DEAL_MOD_DESC"='YWZ')
   9 - access(TRUNC("SYS_ALIAS_4"."DATE_LST_MNTD")>=TO_DATE(' 2007-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              TRUNC("SYS_ALIAS_4"."DATE_LST_MNTD")<=TO_DATE(' 2007-07-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
  10 - filter("D"."DATE_LST_MNTD"=:B1)
  11 - access("D"."DEAL_ID"=:B1 AND "D"."OPER_TYPE"=:B2 AND "D"."ST_HST"=:B3)
       filter("D"."ST_HST"=:B1)
 
Note: cpu costing is off
 
32 rows selected.
 
SQL> 

Этот селект отрабатывает за 1880 сек.

А вот такой вариант уже за 406 сек.
SQL> 
SQL> explain plan for
  2  Select  /*+ parallel (n 2)*/ count(*)
  from f_deal_new  n
 where trunc(n.date_lst_mntd) >= to_date('01.07.2007', 'DD.MM.YYYY')
   and trunc(n.date_lst_mntd) <= to_date('31.07.2007', 'DD.MM.YYYY')
   and n.deal_mod_desc = 'YWZ'
   and n.st_hst = 'Y'
   and n.oper_type <> 'A5'
   and not exists (select /*+ parallel (d 2)*/ 1
          from f_deal  partition(p_st_hst_y) d
         where n.deal_id = d.deal_id
           and n.oper_type = d.oper_type
           and n.date_lst_mntd = d.date_lst_mntd
           and n.st_hst = d.st_hst
           );  3    4    5    6    7    8    9   10   11   12   13   14   15  
 
Explained.
 
SQL> 
SQL> select * from table (sys.dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
 
-----------------------------------------------------------------------------------------------------------------
| Id  | Operation            |  Name       | Rows  | Bytes | Cost  | Pstart| Pstop |  TQ    |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     1 |    96 | 49459 |       |       |        |      |            |
|   1 |  SORT AGGREGATE      |             |     1 |    96 |       |       |       |        |      |            |
|   2 |   SORT AGGREGATE     |             |     1 |    96 |       |       |       | 08,02  | P->S | QC (RAND)  |
|*  3 |    HASH JOIN ANTI    |             |     1 |    96 | 49459 |       |       | 08,02  | PCWP |            |
|*  4 |     TABLE ACCESS FULL| F_DEAL_NEW  | 92119 |  4767K| 28055 |     2 |     2 | 08,00  | P->P | HASH       |
|   5 |     TABLE ACCESS FULL| F_DEAL      |    49M|  2017M| 21404 |     2 |     2 | 08,01  | P->P | HASH       |
-----------------------------------------------------------------------------------------------------------------
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   3 - access("N"."DEAL_ID"="D"."DEAL_ID" AND "N"."OPER_TYPE"="D"."OPER_TYPE" AND
              "N"."DATE_LST_MNTD"="D"."DATE_LST_MNTD" AND "N"."ST_HST"="D"."ST_HST")
   4 - filter(TRUNC("N"."DATE_LST_MNTD")>=TO_DATE(' 2007-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              TRUNC("N"."DATE_LST_MNTD")<=TO_DATE(' 2007-07-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "N"."DEAL_MOD_DESC"='YWZ' AND "N"."OPER_TYPE"<>'A5')
 
Note: cpu costing is off
 
22 rows selected.
 
SQL> 

Всебы хорошо, да только 2-ой вариант не самый лучший, т.к. он производит фулскан партиции в 11Гб и 18Гб. А таких запросов около 20. Я пытался объеденить все даты в один единый запрос, но после того как сессия закончила чтение файлов в v$session_longops появились сведения о HASH JOIN - он "обещал" закончить через 200 000 с лишним секунд (
28 апр 08, 11:07    [5603075]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
_мухомор
Guest
Раз таблицы идентичны по структуре, нужно:
посмотреть планы выполнения запроса к таблицам f_deal и к f_deal_new. Выяснить, по какой причине они отличаются (раз старый план выполнения запроса устаивал).
Посмотрите еще на V$PGA_TARGET_ADVICE - не происходит ли переполнение; возможно, нужно увеличить pga_aggregate_target.
28 апр 08, 13:02    [5603699]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
sendal
Guest
padavan
Есть 2 идентичные(по структуре и по индексам) таблицы: f_deal(11Гб) и f_deal_new(19Гб). Таблица f_deal_new просто содержит некоторые "архивные" данные. Была поставлена задача долить эти данные в боевую таблицу f_deal. При попытке произвести загрузку появились сильные проблемы со скоростью выполнения запросов. Вот пример одного из подобных "проблемных" запросов:
...... skip .........
 where trunc(n.date_lst_mntd) >= to_date('01.07.2007', 'DD.MM.YYYY')
  and trunc(n.date_lst_mntd) <= to_date('31.07.2007', 'DD.MM.YYYY')
....... skip ..........
Всебы хорошо, да только 2-ой вариант не самый лучший, т.к. он производит фулскан партиции в 11Гб и 18Гб. А таких запросов около 20. Я пытался объеденить все даты в один единый запрос, но после того как сессия закончила чтение файлов в v$session_longops появились сведения о HASH JOIN - он "обещал" закончить через 200 000 с лишним секунд (

А селективность по месяцу по таблице f_deal_new хотя бы ориентировочно какая ?
28 апр 08, 13:17    [5603803]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
padavan
Member [заблокирован]

Откуда:
Сообщений: 4795
sendal
padavan
Есть 2 идентичные(по структуре и по индексам) таблицы: f_deal(11Гб) и f_deal_new(19Гб). Таблица f_deal_new просто содержит некоторые "архивные" данные. Была поставлена задача долить эти данные в боевую таблицу f_deal. При попытке произвести загрузку появились сильные проблемы со скоростью выполнения запросов. Вот пример одного из подобных "проблемных" запросов:
...... skip .........
 where trunc(n.date_lst_mntd) >= to_date('01.07.2007', 'DD.MM.YYYY')
  and trunc(n.date_lst_mntd) <= to_date('31.07.2007', 'DD.MM.YYYY')
....... skip ..........
Всебы хорошо, да только 2-ой вариант не самый лучший, т.к. он производит фулскан партиции в 11Гб и 18Гб. А таких запросов около 20. Я пытался объеденить все даты в один единый запрос, но после того как сессия закончила чтение файлов в v$session_longops появились сведения о HASH JOIN - он "обещал" закончить через 200 000 с лишним секунд (

А селективность по месяцу по таблице f_deal_new хотя бы ориентировочно какая ?
Ну разница с моим условием составляет всего-то 1.286.728 строк
28 апр 08, 14:53    [5604371]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
suPPLer
Member

Откуда: Харків, Україна
Сообщений: 7794
Блог
А в f_deal есть данные, которых нет в f_deal_new (кстати, ирония в названии для таблички с архивными данными - суффикс _new :) )? А то можно create table as select ВСЁ из нужных партиций в f_deal_new по очереди, и exchange partition таблицы f_deal с "новосозданной" таблицей... С отключением/включением ограничений и перестройкой индексов.
28 апр 08, 20:54    [5605868]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
 where trunc(n.date_lst_mntd) >= to_date('01.07.2007', 'DD.MM.YYYY')
  and trunc(n.date_lst_mntd) <= to_date('31.07.2007', 'DD.MM.YYYY')

а у вас индексы есть вообше? например на n.date_lst_mntd?
Если есть, то надо убрать ТРУНК и поставить верхную границу на день больше.
И вообше -- ставить два инклюзив стравнения -- можно нарваться на дабле процессинг.
28 апр 08, 22:14    [5605996]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
а является ли deal_id primary key или нет?
28 апр 08, 22:20    [5606007]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
и ваще:

create index deal_id||oper_type||date||st на обоих таблицах
и заппустить что-нибудь типа

select deal_id||oper_type||date||st
from new
minus
select deal_id||oper_type||date||st
from old
28 апр 08, 22:31    [5606021]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
padavan
Member [заблокирован]

Откуда:
Сообщений: 4795
javajdbc
 where trunc(n.date_lst_mntd) >= to_date('01.07.2007', 'DD.MM.YYYY')
  and trunc(n.date_lst_mntd) <= to_date('31.07.2007', 'DD.MM.YYYY')

а у вас индексы есть вообше? например на n.date_lst_mntd?
Если есть, то надо убрать ТРУНК и поставить верхную границу на день больше.
И вообше -- ставить два инклюзив стравнения -- можно нарваться на дабле процессинг.
Если внимательно глянуть на первый вариант запроса, то можно увидеть индекс. Trunc нужен, чтобы подцепился этот индекс, т.к. я его создавал не просто по полю, а trunc(date_lst_mntd), т.к. в этом поле хранится дата с часами, минутами и секундами, но выборка по этому полю не затрагивает "время".
28 апр 08, 22:38    [5606033]     Ответить | Цитировать Сообщить модератору
 Re: Проблема со скоростью исполнения запроса  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
ok, получается, что по дате было выбрано 350К записей так?
|* 9 | INDEX RANGE SCAN | F_DEAL_NEW_DATE | 343K| | | 916 | 2 | 2 |
потом по типу и статусу осталось 5К, так?
|* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| F_DEAL_NEW | 4606 | 238K| | 29930 | 2 | 2 |
может тогда зарезать таблицу СНАЧАЛА по типу и/или статусу (с наличием индексов на них или даже на обьеденненом индексе),а потом по дате ?

Основной подьем в цене произошел имено на линии 3. Вот может на нем и сконцентрировать поиск по индексу, вместо даты?
28 апр 08, 23:00    [5606069]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить