powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Cкан партиционированной таблицы медленнее непарциционированной.
47 сообщений из 47, показаны все 2 страниц
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322606
yon_brover
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На первом сервере имеется таблица изменений остатков по счетам за последние 20 лет:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
create table LIM
(
  PRODATE      DATE not null, -- дата остатка
  ACC          VARCHAR2(10) not null, -- номер счёта
  CURRCODE     VARCHAR2(3) not null, -- валюта счёта
  LIM          NUMBER -- остаток по счёту
);



Есть индекс для определения остатка по счёту на дату:

Код: plsql
1.
create unique index LIM on LIM (ACC, CURRCODE, PRODATE);



Запрашиваем дату последнего изменения остатка по счёту:

Код: plsql
1.
select max(prodate) from lim where acc = '014654567 ' and currcode = '000';



Мгновенно выдаётся результат сканированием индекса.
План такой:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
---------------------------------------------------------------------
| Id  | Operation                    | Name | Rows  | Bytes | Cost  |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT             |      |     1 |    23 |     4 |
|   1 |  SORT AGGREGATE              |      |     1 |    23 |       |
|   2 |   FIRST ROW                  |      |     2 |    46 |     4 |
|*  3 |    INDEX RANGE SCAN (MIN/MAX)| LIM  |     2 |    46 |     4 |
---------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("ACC"='014654567 ' AND "CURRCODE"='000')
Note
-----
   - 'PLAN_TABLE' is old version
   - cpu costing is off (consider enabling it)



На втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам.
Один день - одна партиция, в среднем по 100000 строк в день:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create table LIM
(
  PRODATE      DATE not null, -- дата остатка
  ACC          VARCHAR2(10) not null, -- номер счёта
  CURRCODE     VARCHAR2(3) not null, -- валюта счёта
  LIM          NUMBER -- остаток по счёту
)
partition by range (PRODATE)
(
  partition LIM_1997_04_29 values less than (TO_DATE(' 1997-04-30 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')),
  partition LIM_1997_04_30 values less than (TO_DATE(' 1997-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')),
  ...
  partition LIM_2016_10_06 values less than (TO_DATE(' 2016-10-07 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')),
  partition LIM_2016_10_07 values less than (TO_DATE(' 2016-10-08 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
);



Есть локальный индекс для определения остатка по счёту на дату:

Код: plsql
1.
create unique index IX_L_LIM_ACC_CURR_UQ on LIM (ACC, CURRCODE, PRODATE) nologging  local;



Запрашиваем дату последнего изменения остатка по счёту:

Код: plsql
1.
select max(prodate) from lim where acc = '014654567 ' and currcode = '000';



Результат выдаётся только через 1 минуту, т.к. оракл сканирует все партиции и не может сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту.
Когда где-то в самых последних партициях будет найдена последняя дата изменения остатка по счёту, тогда ораклу стоило бы прекращать дальнейшее сканирование локального индекса.
План такой:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| Id  | Operation                     | Name                 | Rows  | Bytes | C
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                      |     1 |    23 | 1
|   1 |  SORT AGGREGATE               |                      |     1 |    23 |
|   2 |   PARTITION RANGE ALL         |                      |     1 |    23 | 1
|   3 |    FIRST ROW                  |                      |     1 |    23 | 1
|*  4 |     INDEX RANGE SCAN (MIN/MAX)| IX_L_LIM_ACC_CURR_UQ |     1 |    23 | 1
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("ACC"='014654567 ' AND "CURRCODE"='000')
Note
-----
   - 'PLAN_TABLE' is old version



Кстати, запрос минимальной даты на втором сервере тоже висит минуту, как и запрос максимальной даты:

Код: plsql
1.
select min(prodate) from lim where acc = '014654567 ' and currcode = '000';



Статистика на втором сервере собирается обычным dbms_stats.gather_table_stats по партициям со стандартными параметрами.

Итак, скан по локальному индексу партиционированной таблицы происходит на несколько порядков медленнее скана по индексу непарциционированной таблицы.
Вопрос, как на втором сервере научить оракл сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту?
(И когда где-то в самых последних партициях будет найдена последняя дата изменения остатка по счёту, тогда ораклу стоило бы прекращать дальнейшее сканирование локального индекса.)
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322615
yon_brover,

а что ты хотел, если у тебя ключ секционирования не участвует в условия запроса? партишн прунинг не работает и приходится сканить каждую секцию индекса секционированной таблицы. и тут, как бы тебе не хотелось, но прочитать надцать маленьких индексов выходит медленнее, чем один большой, так как возникает оверхед по лишнему чтению структур индекса каждой его секции.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322621
yon_broverне может сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту.это с какого перепугу и на каких таких "подсказках" от тебя в виде констрейнтов, схемы секционирования и т.д. оракл должен был понять такое? где и чем ты ему гарантируешь, что всё оно будет именно так, как ты сказал, а не как-то по другому? лично я бы тебе на слово не поверил. собственно, оракл поступил также.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322680
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yon_broverНа втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам.
Один день - одна партиция
365*20=7300 секций, у Вас, видимо, какая-то особенная редакция oracle - обычный EE не позволяет больше 1000 создавать (3 года при посуточной нарезке).
По сути вопроса - поскольку старые данные не удаляете, то просто замените индекс на глобальный и будет счастье.
Из минусов - с очевидностью старые секции объединяются в более крупные, чтобы нарезать новые суточные секции.
Эта операция станет дороже за счет необходимости обновлять глобальный индекс.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322688
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - Эхэто с какого перепугу и на каких таких "подсказках" от тебя в виде констрейнтов, схемы секционирования и т.д. оракл должен был понять такое? где и чем ты ему гарантируешь, что всё оно будет именно так, как ты сказал, а не как-то по другому? лично я бы тебе на слово не поверил. собственно, оракл поступил также.
Ну не надо так категорично. Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца.
yon_brover...
Результат выдаётся только через 1 минуту, т.к. оракл сканирует все партиции и не может сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту
...
Вы по своему плану не определите, все партиции сканировались или не все.
И в каком порядке.
Всегда в таком случае смотрите Pstart и Pstop и включите пошаговую статистику.

Так что приводите версию и полный план с пошаговой статистикой выполнения.
Или, если вам лень, просто делаете индекс глобальным, как показали выше.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322696
Maxim Demenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

Почему только 1000 ?

Best regards

Maxim
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322701
K790
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

авторобычный EE не позволяет больше 1000 создавать
это где такое написано?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322702
Maxim Demenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexFF__|Ну не надо так категорично. Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца.


Но подобная оптимизация была введена с 11.1.0.6, версия ТС пока не озвучена. И я не уверен что она работает в случае доступа по индеху.

Best regards

Maxim
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322703
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymousyon_broverНа втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам.
Один день - одна партиция
365*20=7300 секций, у Вас, видимо, какая-то особенная редакция oracle - обычный EE не позволяет больше 1000 создавать (3 года при посуточной нарезке).
По сути вопроса - поскольку старые данные не удаляете, то просто замените индекс на глобальный и будет счастье.
Из минусов - с очевидностью старые секции объединяются в более крупные, чтобы нарезать новые суточные секции.
Эта операция станет дороже за счет необходимости обновлять глобальный индекс.

А что я сделал не так ?

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.2.0 Production on Fri Oct 7 12:50:42 2016

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select  table_name ,  count(*)  from  dba_tab_partitions  group by table_name    having count(*) >1000; 

TABLE_NAME                       COUNT(*)
------------------------------ ----------
XXX_COYYY                           4172
SYSAUD$                              1103
ZZZZ_KEEPER                          3278
WERT                                 5301
MMNBV                                2897
ASD_LOG                              4172

7 rows selected.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322708
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
K790авторобычный EE не позволяет больше 1000 создавать
это где такое написано?
Ну вообще в logical database limits, а что?
https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322712
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kА что я сделал не так ?
Эээ... забыли забыли включить в группировку владельца?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322713
AlexFF__| Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца.
с куя ли при секционировании по prodate и при запросе вида:
select max(prodate) from lim where acc = '014654567 ' and currcode = '000' ;
сканирование должно идти с конца секций? в каком месте написано и гарантируется серверу, что строки со значением acc = '014654567 ' and currcode = '000' лежат именно в последней секции, а не в первой, или не где-то в середине, если секции нарезаны по prodate?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322714
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymousK790пропущено...

это где такое написано?
Ну вообще в logical database limits, а что?
https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm

1024K - 1
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322715
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim DemenkoAlexFF__|Ну не надо так категорично. Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца.


Но подобная оптимизация была введена с 11.1.0.6, версия ТС пока не озвучена. И я не уверен что она работает в случае доступа по индеху.

Best regards

Maxim
Поэтому и спрашиваю версию.
А по индексу все-таки должно работать. Можно даже тест сделать. Потом )
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322716
Maxim Demenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

Так там 1024K - 1

Best regards

Maxim
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322719
K790
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousK790пропущено...

это где такое написано?
Ну вообще в logical database limits, а что?
https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm

= 1 024 K, насколько я понимаю это к тысячам кило, т.е. миллион как минимум. -1 только не пойму, что это и почему именно -1 :)
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322721
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - ЭхAlexFF__| Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца.
с куя ли при секционировании по prodate и при запросе вида:
select max(prodate) from lim where acc = '014654567 ' and currcode = '000' ;
сканирование должно идти с конца секций? в каком месте написано и гарантируется серверу, что строки со значением acc = '014654567 ' and currcode = '000' лежат именно в последней секции, а не в первой, или не где-то в середине, если секции нарезаны по prodate?
Потому что сканируя с конца, можно остановиться, найдя первую запись =)
Неужели это в голову не приходит?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322722
K790
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
K790,

хотя есть подозрение, что за минусом первой партиции.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322723
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0k1024K - 1
Шит. Бывает же. А мы как в анекдоте - до сих пор паровозы под откос пускаем...
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322724
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
K790andrey_anonymousпропущено...

Ну вообще в logical database limits, а что?
https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm

= 1 024 K, насколько я понимаю это к тысячам кило, т.е. миллион как минимум. -1 только не пойму, что это и почему именно -1 :)

потому, что люди считают начиная с единицы , а компьютеры начиная с нуля...
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322728
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymousд0kА что я сделал не так ?
Эээ... забыли забыли включить в группировку владельца?

согласен

но всервно больше 1000
Код: plsql
1.
2.
3.
4.
5.
select  max (cnt ) from (select  table_owner,  table_name ,  count(*) cnt   from  dba_tab_partitions  group by table_name , table_owner    having count(*) >1000);

  MAX(CNT)
----------
      3297
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322730
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Быстренько, по структуре ТС:

Создаем таблицу с 99 дневными партициями + индекс
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create table LIM
(
  PRODATE      DATE not null,
  ACC          VARCHAR2(10) not null,
  CURRCODE     VARCHAR2(3) not null,
  LIM          NUMBER
)
partition by range (PRODATE)
(
  partition P_1 values less than ( date '2016-01-02' ),
  ...
  partition P_99 values less than ( date '2016-04-09' )
);

create unique index IDX_LIM on LIM (ACC, CURRCODE, PRODATE) local;




Вставляем в каждую партицию по 10 записей так, чтобы в последней не было таких, что удовлетворяют условию запроса
Код: plsql
1.
2.
insert into LIM
  select date '2016-01-01' + rownum/10, case when date '2016-01-01' + rownum/10 < date '2016-04-08' then mod(rownum, 10) else 100 end, '000', rownum from dual connect by rownum < 990;



Код: plsql
1.
2.
select max(prodate) from T_TEST where acc = '5' and currcode = '000';
07.04.2016 12:00:00


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name       | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | Pstart| Pstop | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |            |      1 |        |       |     1 (100)|          |       |       |      1 |00:00:00.01 |       2 |
|   1 |  SORT AGGREGATE               |            |      1 |      1 |    19 |            |          |       |       |      1 |00:00:00.01 |       2 |
|   2 |   FIRST ROW                   |            |      1 |      1 |    19 |     1   (0)| 00:00:01 |       |       |      1 |00:00:00.01 |       2 |
|   3 |    PARTITION RANGE ALL        |            |      1 |      1 |    19 |     1   (0)| 00:00:01 |    99 |     1 |      1 |00:00:00.01 |       2 |
|*  4 |     INDEX RANGE SCAN (MIN/MAX)| IDX_LIM    |      2 |      1 |    19 |     1   (0)| 00:00:01 |    99 |     1 |      1 |00:00:00.01 |       2 |
------------------------------------------------------------------------------------------------------------------------------------------------------
 
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322739
Ханч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yon_brover,

Покаж план этого запроса (и время выполнения):

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select
prodate
from
(
select /*+ index_rs_desc(lim IX_L_LIM_ACC_CURR_UQ) */ 
prodate 
from 
lim 
where 
acc = '014654567 ' and currcode = '000' 
order by prodate desc
) where rownum<=1
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322741
Maxim Demenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexFF__|,

да, у меня та же картина , походу работает.

Best regards

Maxim
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322745
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Demenkoда, у меня та же картина , походу работает.
Но ТС рекомендация прежняя - создать глобальный (можно секционированный по hash от ACC) индекс.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322751
Maxim Demenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

С таким количеством партитиций (хотя это еще по божески), я бы начал смотреть в ASH (если доступен), на что время уходит, не исключено, что сам запрос может парсится приличное время, а исполняется довольно быстро. Ну в любом случае, можно было бы определить на что уходит время.

Best regards

Maxim
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322758
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Demenkoне исключено, что сам запрос может парсится приличное время, а исполняется довольно быстро.
Запрос к единственной таблице с единственным индексом - и минуту парсится?
Что-то сомневаюсь.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322763
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Фухх :)....
У меня на локальных индексах все нормально ....

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
SQL> explain plan for (select max(time)  from xxxx.xxx);

Explained.

Elapsed: 00:00:00.03
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 727408685
[FIXED]
-------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               |     1 |     8 |  4012   (1)| 00:00:49 |       |       |
|   1 |  SORT AGGREGATE             |               |     1 |     8 |            |          |       |       |
|   2 |   PARTITION RANGE ALL       |               |     1 |     8 |  4012   (1)| 00:00:49 |     1 |  2004 |
|   3 |    INDEX FULL SCAN (MIN/MAX)| IDX_xxx_TIME |     1 |     8 |  4012   (1)| 00:00:49 |     1 |  2004 |
-------------------------------------------------------------------------------------------------------------

[/FIXED]10 rows selected.

Elapsed: 00:00:00.02
SQL> select max(time)  from xxxx.xxx;

MAX(TIME)
---------
07-OCT-16

Elapsed: 00:00:00.02
SQL> select min(time)  from xxxx.xxx;

MIN(TIME)
---------
07-APR-11

Elapsed: 00:00:00.03

SQL> select count(*) from   dba_ind_partitions where  index_owner='xxxx' and  index_name='IDX_xxx_TIME' ;

  COUNT(*)
----------
      2004

Elapsed: 00:00:00.10
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322767
AlexFF__|,

Ещё раз. Мы ищем не просто максимальное значение поля-ключа секционирования во всей таблице. Мы ищем максимум этого поля для строк, удовлетворяющих доп.условию acc = '014654567 ' and currcode = '000' ;по полям, не входящим в ключ секционирования. Лично я даже не могу дать гарантии, что строки лежат в одной секции. Откуда есть уверенность, что они будут именно в последней секции? Может оказаться, что строки со значениями acc = '014654567 ' and currcode = '000'; есть вообще только в первой секции. Какой профит я получу, сканируя секции в обратном порядке?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322774
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - ЭхКакой профит я получу, сканируя секции в обратном порядке?Что как только они появятся в данной секции, именно там будет максимальная дата. Нет?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322775
Maxim Demenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

При очень большом количестве партиций (в таблице и в индехе) - хотя конечно понятие "очень большое" зависит от конкретной системы - возможны довольно серьезные проблемы с library cache / rowcache, особенно если система довольно нагружена.

Best regards

Maxim
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322832
yon_brover
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, забыл указать версию:

Код: plsql
1.
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi.



Спасибо, Ханч.

Вариант

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
select prodate
  from (select /*+ index_desc(lim IX_L_LIM_ACC_CURR_UQ) */
         prodate
          from dwh.lim
         where acc = '014654567 '
           and currcode = '000'
         order by prodate desc)
 where rownum <= 1;



отрабатывает мгновенно.

План у него такой:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| Id  | Operation                      | Name                 | Rows  | Bytes |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                      |     1 |     9 |
|*  1 |  COUNT STOPKEY                 |                      |       |       |
|   2 |   PARTITION RANGE ALL          |                      |    64 |   576 |
|   3 |    VIEW                        |                      |    64 |   576 |
|*  4 |     INDEX RANGE SCAN DESCENDING| IX_L_LIM_ACC_CURR_UQ |    64 |  1472 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(ROWNUM<=1)
   4 - access("ACC"='014654568 ' AND "CURRCODE"='000')
Note
-----
   - 'PLAN_TABLE' is old version
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322841
Charles Weyland
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
партицировали-партицировали, да не выпартицировали.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322847
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - Эх Какой профит я получу, сканируя секции в обратном порядке?
Ну тут все просто - условие останова. Если результат max() найден в секции n, то в секцию n-1 можно не заглячдывать.

Правда имеет смысл только для min/max, для других функций, например avg, конечно нет.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322859
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
д0kФухх :)....
У меня на локальных индексах все нормально ....


Но по праймари ключу - жопа....


Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
SQL> explain plan for (select count(*)   from xxxx.xxx);

Explained.

Elapsed: 00:00:00.04
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2893698907

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name        | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |             |     1 |  2594K  (2)| 08:38:56 |       |       |
|   1 |  SORT AGGREGATE        |             |     1 |            |          |       |       |
|   2 |   PARTITION RANGE ALL  |             |  2929M|  2594K  (2)| 08:38:56 |     1 |  2004 |
|   3 |    INDEX FAST FULL SCAN| IDX_xxx_ID |  2929M|  2594K  (2)| 08:38:56 |     1 |  2004 |
----------------------------------------------------------------------------------------------

10 rows selected.

Elapsed: 00:00:00.02
SQL> select count(*) from  xxxx.xxx ;

  COUNT(*)
----------
1.6203E+10

Elapsed: 01:05:13.12



индекс по 16 млрд записям сканировался больше часа.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322892
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kиндекс по 16 млрд записям сканировался больше часа.
Parallel не?
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322911
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymousд0kиндекс по 16 млрд записям сканировался больше часа.
Parallel не?

Не, паралелью я бы уложил пользователей по ВВ.

вот интересно , план тот же
а резульат кардинально другой ...
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
SQL> explain plan for (select max(id)   from xxx.xxx);

Explained.

Elapsed: 00:00:00.05
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2769239955

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |     1 |     7 |     3   (0)| 00:00:01 |       |       |
|   1 |  PARTITION RANGE ALL        |             |     1 |     7 |            |          |  2004 |     1 |
|   2 |   SORT AGGREGATE            |             |     1 |     7 |            |          |       |       |
|   3 |    INDEX FULL SCAN (MIN/MAX)| IDX_xxx_ID |     1 |     7 |     3   (0)| 00:00:01 |  2004 |     1 |
-----------------------------------------------------------------------------------------------------------

10 rows selected.

Elapsed: 00:00:00.33
SQL> select max(id) from  xxx.xxx ;

   MAX(ID)
----------
2.0801E+10

Elapsed: 00:00:00.00
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322917
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kвот интересно , план тот же
Не, не тот же план - см. внимательнее :)
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322919
Desert_Nomad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
М-даа, знакомо, знакомо.

Сразу ведь предложили - или глобальный индекс, или dynamic-ом перебирать партиции, генерируя имя на основании искомой даты ;-)
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322928
krokodaktil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Если без глобального индекса, то можно сделать некий гибридный вариант:
Все это дело обернуть в функцию, которая генерирует и выполняет дайнамик запросы в количестве N штук начиная с последней партиции. Каждый такой запрос будет выполняться милисекунды по локальному индексу. Ну а если за N итераций искомого не нашли - запускать запрос по всем партициям.
Но все равно основу механизма вам уже описывали...
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322931
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Desert_Nomaddynamic-ом перебирать партиции, генерируя имя на основании искомой даты ;-)krokodaktilгенерирует и выполняет дайнамик запросы в количестве N штук начиная с последней партиции. 19497465
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322941
krokodaktil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Elic 19497465
ИИИИ????
Спасибо за пруф на синтаксис селекта с указание партиции как в явном виде, так и по значению ключа партицирования. Сам знал, но повторить никогда не помешает. :)
А теперь можно пруф на то, где в постановке задачи написано, что известно, в какой партиции(или на какую дату) есть значение отвечающее WHERE?
Не в каждой партиции есть искомое значение.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322946
Desert_Nomad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Elic, спасибо, конечно, за пруф, но тут нет задачи узнать имя партиции.

От чего исходим:
"На втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам.
Один день - одна партиция...".

Тут люди хотят организовать поиск с последних партиций принудительно.
Решение в лоб - брать предположительные дни, начиная с последнего, и опрашивать соответствующие партиции на предмет нашли/не нашли.
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39322951
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
krokodaktilА теперь можно пруф на то, где в постановке задачи написано, что известно, в какой партиции(или на какую дату) есть значение отвечающее WHERE?
Не в каждой партиции есть искомое значение.Это ты у себя спрашиваешь? Я лишь про то, что незачем нетривиально динамить при наличии статического синтаксиса.
yon_broverОдин день - одна партиция
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39323003
A.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.
Гость
Ну как, разобрались, что партиции сканируются в нужном порядке как минимум с 10g?

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

select /*+ index(t) */ max(prodate) from lim t where acc = '014654567 ' and currcode = '000'

Plan hash value: 4241235387

------------------------------------------------------------------------------
| Id  | Operation                     | Name                 | Pstart| Pstop |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                      |       |       |
|   1 |  SORT AGGREGATE               |                      |       |       |
|   2 |   FIRST ROW                   |                      |       |       |
|   3 |    PARTITION RANGE ALL        |                      |     4 |     1 |
|   4 |     INDEX RANGE SCAN (MIN/MAX)| IX_L_LIM_ACC_CURR_UQ |     4 |     1 |
------------------------------------------------------------------------------



select /*+ index(t) */ min(prodate) from lim t where acc = '014654567 ' and currcode = '000'

Plan hash value: 4241235387

------------------------------------------------------------------------------
| Id  | Operation                     | Name                 | Pstart| Pstop |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                      |       |       |
|   1 |  SORT AGGREGATE               |                      |       |       |
|   2 |   FIRST ROW                   |                      |       |       |
|   3 |    PARTITION RANGE ALL        |                      |     1 |     4 |
|   4 |     INDEX RANGE SCAN (MIN/MAX)| IX_L_LIM_ACC_CURR_UQ |     1 |     4 |
------------------------------------------------------------------------------
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39323127
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
yon_brover,

трассу 10053 приложи и экспортни всю статистику по таблице

зы. и дропни таблицу PLAN_TABLE
...
Рейтинг: 0 / 0
Cкан партиционированной таблицы медленнее непарциционированной.
    #39323606
krokodaktil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Elic,

А я про то, что нечего пытаться на 10g пытаться руководствоваться синтаксисом для 11-го оракла
...
Рейтинг: 0 / 0
47 сообщений из 47, показаны все 2 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Cкан партиционированной таблицы медленнее непарциционированной.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]