21.08.2007 11:57
orabin
 
Просто по году?
Какие индексы лучше сделать глобально индексированными,
а какие сделать локально индексированными?

Какие еще таблица партицированы?
23.08.2007 12:07
orabin
 
вот думаю если оставлять все остальные индексы локальными безпрефиксными не слетят ли у меня запросы?
23.08.2007 13:54
OlegON
 
Я просто еще не делал, жду нового сервака для 9i и тогда буду возиться... Ты пиши, потом кто-то еще пойдет... Что касается запросов, то есть с подсказками на конкретный индекс...
24.08.2007 08:35
reddevil
 
Цитата:
OlegON есть с подсказками на конкретный индекс...
Надуманная проблема у автора там индексов то полторы штуки один из них из одного поля DATE, планы даже если и сьедут, то их надо корректировать параметрами чтобы правильно выбырался фуллскан на достаточно большрм периоде отчета. А учитывая что таблицы как бы Read Only то даже не знаю что здесь по поводу глобальных и локальных сказать если честно. Но я еще делаю листовую подсекцию по типу документа.
24.08.2007 09:19
orabin
 
Ну хорошо сделали вы партицирование по FFMAPREP
Приведу свои мысли
есть индексы

ffmaprep_saledate ( saledate ASC )
Понятно дело локальным префиксным битмапчатым

ffmaprep_locto ( salelocationto ASC, saledate ASC )
ffmaprep_locfrom (salelocationfrom ASC, saledate ASC )
Назначение этих двух индексов непонятно
Зачем толкать вперед заведомо низкоселективное поле
такое ощущение что их надо поменять местами....вопрос
По идее можно оставить битмапчатым и вообще не партицировать

ffmaprep_article (article )
локальный безпрефиксный или уж оставить неразделенный, в приципе даже на битмап тянуть будет

ffmaprep_doc ( saleid, saletype, salespecitem)
наверное лучше партицировать локально ибо может разростись
24.08.2007 09:43
reddevil
 
ffmaprep_locto ( salelocationto ASC, saledate ASC )
ffmaprep_locfrom (salelocationfrom ASC, saledate ASC )
ffmaprep_article (article )
это все вобще дропнуть нафик чтоб на пересоздание время не тратить, пользы от них 0.
И я не могу понять где тут у вас префикс ( saledate ASC ) ?
и почему он должен быть "битмапчатым"?
24.08.2007 10:05
orabin
 
>>ffmaprep_article (article )
>>это все вобще дропнуть нафик чтоб на пересоздание время не тратить, >>пользы от них 0.
Вы точно уверены что их можно дропнуть?
Вы на рабочей базе их дропнули? Все корректно работает? Расчет себестоимости наверное быстрей считается :)
Особые сомнения вызывает ffmaprep_article он часто РЕАЛЬНО используется

>> И я не могу понять где тут у вас префикс ( saledate ASC )
>>и почему он должен быть "битмапчатым"?[/quote]
да префикс saledate хочу разбить по годам, а может даже и кварталам
битпамчатый потому на моей базе на 15000000 строк таблицы по этому полю distinct_key=650
24.08.2007 10:21
reddevil
 
1. "Вы на рабочей базе их дропнули? Все корректно работает? Расчет себестоимости наверное быстрей считается "- да на ЦО в 200гиг, загрузку естественно происходит быстрей и место не занимает лишнева.

2. "Особые сомнения вызывает ffmaprep_article он часто РЕАЛЬНО используется." Хоть 1 неодноразовый запрос где он используется?

3. "да префикс saledate хочу разбить по годам, а может даже и кварталам" - что в вашем понимании "префикс" применительно к индексу?

4. "битпамчатый потому на моей базе на 15000000 строк таблицы по этому полю distinct_key=650" - теоритически согласен, а вообще стоит попорбовать и сравнить.
28.08.2007 17:49
OlegON
 
Хы, какая прелесть оказывается...
Цитата:
Обычный
SEGMENT_NAME Size in MB
------------------------------ ----------
FFMAPREP 2010.125
FFMAPREP_SALEDATE 273

Bitmap
SEGMENT_NAME Size in MB
------------------------------ ----------
FFMAPREP 2010.125
FFMAPREP_SALEDATE 40
28.08.2007 19:23
deucel
 
Цитата:
reddevil а вообще стоит попорбовать и сравнить.
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production

индекс был с компрессией

Код:
INDEX                                             BITMAP
                                    |
SEGMENT_NAME         Size in MB     |         Size in MB
-------------------- ----------     |         ----------
FFMAPREP                  14975     |              14975
FFMAPREP_SALEDATE          2688     |                544
                                    |
INDEX_NAME         CLUSTERING_FACTOR|  CLUSTERING_FACTOR
------------------ -----------------|  -----------------
FFMAPREP_SALEDATE          141795296|              68241
                                    |
--------------------------------------------------------
запрос с одной датой                |
                                    |
INDEX (RANGE SCAN)                  |BITMAP INDEX (SINGLE VALUE)
Cost=23741                          |Cost=6216
256246  consistent gets             |237042  consistent gets
233102  physical reads              |125460  physical reads
------------------------------------|-------------------
запрос с диапазоном дат             |
                                    |
TABLE ACCESS (FULL)                 |BITMAP INDEX (RANGE SCAN)
Cost=37008                          |Cost=16626
1013794  consistent gets            |692106  consistent gets
915871  physical reads              |603610  physical reads
*33
Вложения
Тип файла: txt FFMAPREP_result.txt (5.4 Кб, 212 просмотров)
Часовой пояс GMT +3, время: 19:43.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.