ReSQL.ru
     
powered by simpleCommunicator - 2.0.44     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Ход мыслей оптимизатора
9 сообщений из 9, страница 1 из 1
Ход мыслей оптимизатора
    #32053820
lh@work
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lh@work
Гость
Здравствуйте, уважаемые!
Есть запрос, крайне странно оптимизируемый оптимизатором. Если это грабли, лежащие рядом -- просветите, пожалуйста....
Исходные данные:
Oracle8i Enterprise Edition Release 8.1.7.3.0 - Production
Linux RedHat 6.2 kernel 2.2.16

CREATE TABLE plog_43 (eventtime date not null,
page varchar2(250),
ip number(12),
cookie varchar2(100))
Таблица секционирована по eventtime: один день = 1 секция.
По столбцу page создан LOCAL BITMAP-индекс
Распределение значений в столбце page такое:
'www.abc.ru' 10 записей
'www.abc.ru/test' 1454 записей
Для запроса
SELECT page, COUNT(*) FROM plog_43
WHERE eventtime>=TO_DATE('19/09/2002', 'DD/MM/YYYY') AND eventtime<TO_DATE('20/09/2002', 'DD/MM/YYYY') and page='www.abc.ru'
На соответствующую секцию таблицы (и на всю таблицу целиком) напускался ANALYZE (ALALYZE TABLE ... FOR ALL INDEXED COLUMNS COMPUTE STATISTICS). Когда это не дало результатов, ANALYZE .. COMPUTE STATISTICS был напущен на индекс и на столбец персонально.
По неясной причине оптимизатор не хочет использовать bitmap-индекс (план выполнения такой:)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
 --------------------------------------------------------------------------------
 
| Operation                 |  Name    |  Rows | Bytes|  Cost  | Pstart| Pstop |
 --------------------------------------------------------------------------------
 
| SELECT STATEMENT          |          |      1  |    41  |       2  |       |       |
|  SORT AGGREGATE           |          |      1  |    41  |        |       |       |
|   TABLE ACCESS FULL       |PLOG_43   |      1  |    41  |       2  |      5  |      5  |
--------------------------------------------------------------------------------

В трассировочном файле (event 10053) -- магические фразы
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
Table stats    Table: PLOG_43   Alias: PLOG_43
  PARTITION [ 4 ]  (NOT ANALYZED) ::   CDN:  1144   NBLKS:   14   TABLE_SCAN_CST:  2   AVG_ROW_LEN:
   100 
  TOTAL ::  (NOT ANALYZED)    CDN:  1144   NBLKS:   14   TABLE_SCAN_CST:  2   AVG_ROW_LEN:   100 


******** Bitmap access path rejected ********
Cost:  3   Selectivity:  0 
Not believed to be index-only.


Всячески благодарю за умные ответы.
С уважением, Наталия Мирочник
...
Рейтинг: 0 / 0
27.09.2002, 18:44
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32053955
vskv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vskv
Участник
Тут уже обсуждались "оссобенности национальной охоты на индексы по столбцам VARCHAR". Это раз.

Потом тебе же ясно говорят, что у твоего индекса стоимость не оправдывает себя:
Cost: 3 Selectivity: 0

Как следствие вопрос: а почему BITMAP?

И финальный аргумент -- отсортировать 14 блоков, это действительно дёшево... Вот если бы 1000, это уже другой разговор.
...
Рейтинг: 0 / 0
29.09.2002, 19:45
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32053996
lh@work
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lh@work
Гость
для vskv:
1. BITMAP-индекс -- потому, что количество строк большое, а уникальных значений мало. Если верить документации, то для столбцов с низкой кардинальностью битовый индекс очень даже подходит.
2. правильно ли я понимаю, что если в таблице будет на несколько порядков больше блоков, чем в индексе, то индекс будет использоваться?
...
Рейтинг: 0 / 0
30.09.2002, 10:13
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32054221
vskv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vskv
Участник
Боюсь оказаться неправым, но, по-моему, для значений
'www.abc.ru' и 'www.abc.ru/test' значение bitmap окажется одинаковым. Что гласит статистика по индексу?

А насчёт числа блоков -- имеется ввиду стоимость мультиблочного доступа к таблице с последующей сортировкой, по сравнению со стоимостью дёрганья индекса, а потом таблицы.

Кстати, а почему не пробуются варианты с индексом page+eventtime?
...
Рейтинг: 0 / 0
30.09.2002, 22:00
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32054595
lh@work
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lh@work
Гость
Варианты с индексом page+eventtime пробовались еще давно, и такой индекс Oracle начинает использовать. а есть ли смысл индексировать по двум полям, одно из которых с высокой, а другое - с низкой кардинальностью? индекс будет очень толстым, а это неправильно.

В общем, загадочно.

Статистика по столбцу (USER_PART_HISTOGRAMS)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 1   select BUCKET_NUMBER, ENDPOINT_VALUE, ENDPOINT_ACTUAL_VALUE
   2      from user_part_histograms
   3     where table_name='PLOG_43'
   4     and partition_name='LOG_2002_09_20_043'
   5 *  and column_name='PAGE'
SQL> /

BUCKET_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE
 ------------- -------------- ----------------------------------------
 
             8       6 .2031E+ 35  www.abc.ru/
          1674       6 .2031E+ 35  www.abc.ru/test
Статистика по индексу
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
   1   select status, BLEVEL, LEAF_BLOCKS, DISTINCT_KEYS, NUM_ROWS, LAST_ANALYZED
   2     from user_ind_partitions
   3     where index_name='PI_PG_43'
   4 *   and partition_name='LOG_2002_09_20_043'
SQL> /

STATUS       BLEVEL LEAF_BLOCKS DISTINCT_KEYS   NUM_ROWS LAST_ANAL
 -------- ---------- ----------- ------------- ---------- ---------
 
USABLE             0             1               2            2   01 -OCT- 02


С уважением, Наталия
...
Рейтинг: 0 / 0
01.10.2002, 18:21
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32054647
vskv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vskv
Участник
Ну и? Ну получил оптимизатор на входе, что есть индекс с ну очень низкой кардинальностью, которая, по логике, обозначает -- если будете дёргать индекс, то потом всё равно придётся почти всю таблицу прочесать...
Вот он и отказывается.

А про составной индекс -- смотря, что вы выбирать в таблице будете?
Я тут пару недель назад доказал, что в одном индексе на первом месте должно стоять поле с самой низкой селективностью, а с самой высокой (как раз дата+время) -- на последнем. А всё потому, что выборка идёт исключительно с помощью range scan с использованием точных значений ведущих полей и интервала по дате/времени...
...
Рейтинг: 0 / 0
02.10.2002, 02:30
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32054650
vskv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vskv
Участник
... доказал нашим кодировщикам, что ...
...
Рейтинг: 0 / 0
02.10.2002, 02:39
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32054771
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
2 lh

Здесь что-то не так. Будет время подумаю, у меня похожий случай. Кстати на 8.1.7 после массовой заливки данных сильно вырастает размер bitmap индексов. Никто не сталкивался???
...
Рейтинг: 0 / 0
02.10.2002, 12:03
| Ответить | Цитировать | Написать  
Ход мыслей оптимизатора
    #32054834
lh@work
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lh@work
Гость
2 vsky: что касается BITMAP-индекса на столбцах с низкой кардинальностью: если оптимизато думает так, как ты описал, то в таком случае он не должен использовать и обычный индекс по этому столбцу. В моем же случае все не так: обычный индекс, построенный по столбцу, используется, а BITMAP - нет. Хотя логичнее было бы наоборот.

2 killed: распухания индеков не замечала, поскольку у нас данные сначала заливаются в партицию, потом строится индекс, и больше ничего не удаляется и не изменяется. А после заливки большого кол-ва данных индекс, наверное, должен распухать: в битовой матрице столько столбцов, сколько добавлено строк + потом индекс-дерево перебалансировать придется.

А если сказать индексу после заливки данных REBUILD, он не уменьшится?

С уважением, Наталия
...
Рейтинг: 0 / 0
02.10.2002, 15:01
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Ход мыслей оптимизатора
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&fpage=2840&tid=1993015]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 36ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 63ms
get tp. blocked users:
 2ms
others: 255ms
total:  403ms
созд. / загр.: 403ms
x
x
Закрыть


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