Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
Подскажите что лучше переместить таблицу в Keep Pool (его при этом надо будет создать отняв часть места из DEFAULT) или установить у нее флажок cache (alter table xxx cache).

Ситуация:
Размер буферного кэша 600МБ
Общий размер данных - несколько ГБ
Размер таблицы 120МБ с возможностью дальнейшего роста.
Обращения к таблице частые, но FULL SCAN (поэтому без доп. мер она в кэш не попадет)

У кого какие есть мнения?
12 сен 07, 15:28    [4657051]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18342
eml78
У кого какие есть мнения?

Поменять дизайн
12 сен 07, 15:34    [4657121]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
tru55
Member

Откуда: СПб
Сообщений: 19790
а почему именно FULL SCAN ? Каждый раз много строк выбирается?
12 сен 07, 15:51    [4657314]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
tru55
а почему именно FULL SCAN ? Каждый раз много строк выбирается?

Строк выбирается мало, но оптимизатор выбирает FULL SCAN из-за условий выборки.

SELECT ...
FROM fd
  INNER JOIN rr
    ON ((fd.cls BETWEEN rr.cls AND rr.clsup) AND (rr.clientid = 8002))
  INNER JOIN fc ON (fd.refFc = fc.ID)
  LEFT OUTER JOIN fr ON (fc.refFr = fr.ID)
WHERE (fd.pindex IN (63, 64, 66, 67, 68, 70, 73, 76)
   AND (fc.pindex IN (63, 64, 66, 67, 68, 70, 73, 76)
   AND ((fc.createdate BETWEEN <DATA1> AND <DATA2>) OR (fc.updatedate BETWEEN <DATA1> AND <DATA2>)
     OR (fd.createdate BETWEEN <DATA1> AND <DATA2>) OR (fd.updatedate BETWEEN <DATA1> AND <DATA2>))
fc заголовок (около 130МБ, 360 тыс. записей)
fd детализация (около 100МБ, 480 тыс. записей)
rr таблица которая служит для ограничения прав на видимость данных по идентификатору клиента (2,5 тыс. записей)
fr - справочник (7,5 тыс. записей)

Добавление индексов по (fc.pindex, fc.createdate) (fc.pindex, fc.updatedate) (fd.pindex, fd.createdate) (fd.pindex, fd.updatedate) приводит к расщеплению выборки на четыре части (вместо FULL SCAN получаем проход по индексу) с последующим union, но только в тех случаях когда диапазон дат дат очень мал (несколько дней). Если диапазон дней 20-30 и более возвращаемся к старому плану с FULL SCAN. Более того, существенного выйгрыша по времени от нового плана (если диапазон дат 5-10 дней мы как правило не получаем).
Поэтому мне кажется стоит поднять таблицу fc в память (а может и fd)
Если кто-то знает как можно оптимизировать запрос - то буду рад выслушать советы...
12 сен 07, 16:31    [4657784]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
G.M.
Member

Откуда:
Сообщений: 342
eml78

Добавление индексов по (fc.pindex, fc.createdate) (fc.pindex, fc.updatedate) (fd.pindex, fd.createdate) (fd.pindex, fd.updatedate) приводит к расщеплению выборки на четыре части (вместо FULL SCAN получаем проход по индексу) с последующим union, но только в тех случаях когда диапазон дат дат очень мал (несколько дней). Если диапазон дней 20-30 и более возвращаемся к старому плану с FULL SCAN. Более того, существенного выйгрыша по времени от нового плана (если диапазон дат 5-10 дней мы как правило не получаем).

Какой диапазон дат охватывает таблица? Равномерно ли распределены по нему данные?
12 сен 07, 17:14    [4658273]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
1-2-3
Guest
Может попробовать list partition?
12 сен 07, 17:18    [4658313]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
G.M.
Какой диапазон дат охватывает таблица? Равномерно ли распределены по нему данные?

Диапазон - с начала года.
Распеределение более-менее равномерное.
12 сен 07, 17:45    [4658577]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
1-2-3
Может попробовать list partition?

А партиции на Standart Edition поддерживаются?

Кстати, а чем все-таки всем так не нравиться решением с запихиванием таблицы в память?
Ну и кончно интересует исходный ворпос: что лучше cache или keep?
12 сен 07, 17:50    [4658613]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
Полугурок
Member [заблокирован]

Откуда: из гурдома
Сообщений: 56
лучше db_file_multiblock_read_count=512, и disk_async_io=true, и filesystemio_options=setall
12 сен 07, 17:53    [4658650]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
Полугурок
лучше db_file_multiblock_read_count=512, и disk_async_io=true, и filesystemio_options=setall

В итоге, судя по доке, по всем остальным таблицам оптимизатор будет делать FULL SCAN чаще чем раньше.
12 сен 07, 18:39    [4658977]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
Полугурок
Member [заблокирован]

Откуда: из гурдома
Сообщений: 56
eml78
Полугурок
лучше db_file_multiblock_read_count=512, и disk_async_io=true, и filesystemio_options=setall

В итоге, судя по доке, по всем остальным таблицам оптимизатор будет делать FULL SCAN чаще чем раньше.
alter session set db_file_multiblock_read_count=512 => select ... => alter session set db_file_multiblock_read_count=8/16/...
12 сен 07, 18:52    [4659068]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
G.M.
Member

Откуда:
Сообщений: 342
eml78
В итоге, судя по доке, по всем остальным таблицам оптимизатор будет делать FULL SCAN чаще чем раньше.

Во-первых, не стоит бояться фуллскана - он не страшный жупел, а всего лишь один из путей доступа к данным, со своими преимуществами и недостатками.
Во-вторых, хотите помочь оптимизатору - соберите системную статистику. Тогда стоимость фуллскана будет вычисляться по реальному (или, по крайней мере, близкому к реальному) значению MBRC.

А с вашим запросом на standart edition особо не развернешься, мда. Последняя попытка - построить индексы по (fd.pindex, fd.cls) и (fc.pindex, fc.ID). Может, основная фильтрация идет по этим полям, тогда, глядишь, и поможет.
12 сен 07, 19:56    [4659357]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
1-2-3
Guest
eml78
1-2-3
Может попробовать list partition?

А партиции на Standart Edition поддерживаются?


Нет, в стандарте нет партиций. Но можно сделать:
- tables for every value
- view
- instead of trigger on view
Так делать приходилось, только несклько в других случаях. Вполне работоспособно.

eml78
Кстати, а чем все-таки всем так не нравиться решением с запихиванием таблицы в память?


Почему же не нравится. Вполне себе решение. Только блоки и так будут лежать в кэше, если надо. Хочется оптимизировать доступ к таблице.

eml78
Ну и кончно интересует исходный ворпос: что лучше cache или keep?

В твоем случае применим keep. Почему - читай доку, там доходчиво все написано.
12 сен 07, 22:55    [4659787]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
1-2-3
Только блоки и так будут лежать в кэше, если надо.

Не будут - при FULL SCAN они будут помещаться в кэш с дргуого конца и тут же вытесняться последующими блоками той же таблицы (проверял на тесте).

1-2-3
В твоем случае применим keep. Почему - читай доку, там доходчиво все написано.

Да вроде как оба решения работают. Доку прочту с удовольствием - только просьба ткнуть по-конкретней (Книжка/раздел), ибо там где я смотрел никаких сопоставлений keep vs cache не было.
13 сен 07, 16:06    [4664022]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
G.M.
Во-первых, не стоит бояться фуллскана - он не страшный жупел

В случае когда такие запросы с FULL SCAN выполняются достаточно часто (а блоки в кэше не остаются) - это уже серьезная проблема катастрофически снижающая производительность.
G.M.
Последняя попытка - построить индексы по (fd.pindex, fd.cls) и (fc.pindex, fc.ID). Может, основная фильтрация идет по этим полям, тогда, глядишь, и поможет.

Опимизатор забивает на эти индексы - сперва объединяет fc и fd, потом фильтр по rr, а потом присоединяет справочник по индексу. План как я уже писал менется только при наличии индексов вида (дата+pindex).
13 сен 07, 16:29    [4664211]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
Змей Равниныч
Member

Откуда: Из тридевятого царства
Сообщений: 284
Вижу явное непонимание, как работают и для чего задумывались обе фичи.
Еще раз предупреждаю
1) если таблица одновременно кем-то меняется, особенно, если изменений немало;
2) со временем она растет в размере
можно только ухудшить ситуацию обоими способами.

Если будет выбран способ "cache", а запросы к таблице будут с достаточно большим интервалом по времени, можно тоже огрести ухудшение в разы.

Все это в сравнении с
"лучше db_file_multiblock_read_count=512, и disk_async_io=true, и filesystemio_options=setall"
13 сен 07, 16:37    [4664265]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
Змей Равниныч
Вижу явное непонимание, как работают и для чего задумывались обе фичи.
Еще раз предупреждаю
1) если таблица одновременно кем-то меняется, особенно, если изменений немало;
2) со временем она растет в размере
можно только ухудшить ситуацию обоими способами.

Если будет выбран способ "cache", а запросы к таблице будут с достаточно большим интервалом по времени, можно тоже огрести ухудшение в разы.

Все это в сравнении с
"лучше db_file_multiblock_read_count=512, и disk_async_io=true, и filesystemio_options=setall"

1)Изменений мало - в основном чтение.
2)В размере растут, но время от времни происходит зачистка, поэтому больше чем 200-250МБ ни fc ни fd скорее всего никогда не станут (по крайней мере в ближайшие несколько лет).
3)Запросы к таблице выполняются часто (тот что приведен в примере - вообще идет пачкой - 4 шт. подряд - там довольно специфично меняются условия, поэтому объединить в один нельзя). Кроме него есть еще куча запросов обращающихся к тем же таблицам fc+fd. Ориентировочно можно считать что 50% select в системе так или иначе обращаются к эти таблицам. И имеено эти таблицы одни из самых больших в нашей схеме (больше них только "служебные", но к ним доступ строго по индексам).

Насчет непонимания - вполне возможно: если нетрудно укажите в чем именно оно заключается, или ссылка в доку (Книжка\раздел).
13 сен 07, 16:53    [4664414]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
G.M.
Member

Откуда:
Сообщений: 342
eml78
В случае когда такие запросы с FULL SCAN выполняются достаточно часто (а блоки в кэше не остаются) - это уже серьезная проблема катастрофически снижающая производительность.

Если в этих запросах фуллскан является быстрейшим путем выборки данных, то в чем проблема-то?
А чтобы блоки оставались в кэше - нужно засунуть их в keep pool

eml78
Опимизатор забивает на эти индексы - сперва объединяет fc и fd, потом фильтр по rr, а потом присоединяет справочник по индексу. План как я уже писал менется только при наличии индексов вида (дата+pindex).

Ну, значит, не судьба.
13 сен 07, 16:53    [4664428]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
G.M.
А чтобы блоки оставались в кэше - нужно засунуть их в keep pool
Т.е. по вашему keep лучше чем установить опцию cache?
А не могли бы вы пояснить почему... (т.к. я пока не вижу особых преимуществ у вараинта с keep).
13 сен 07, 16:58    [4664471]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
Змей Равниныч
Member

Откуда: Из тридевятого царства
Сообщений: 284
eml78
Насчет непонимания - вполне возможно: если нетрудно укажите в чем именно оно заключается, или ссылка в доку (Книжка\раздел).
В доке этого нет. Разжевывать - долго.

Кратко:
1) при выборе размера под keep-пул помним про CR-блоки, которых может быть немало.
2) при установленной опции cache, если блока нет в кэше, перед чтением с диска нужно найти свободный блок - а это обычно не дешево. Без опции cache при FTS и наличии asyns_io используются поочередно 2 группы блоков (без поиска свободных).

В общем - эксперименты. Можно еще подумать о распараллеливании - зависит от числа дисков, числа процев, сложности условий в запросе и т.д. Упс... вспомнил - Oracle SE :(
13 сен 07, 17:02    [4664516]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
eml78
Member

Откуда:
Сообщений: 648
Змей Равниныч
1) при выборе размера под keep-пул помним про CR-блоки, которых может быть немало.
Да, конечно и это как раз тот момент почему мне не очень нравиться keep - придется выделять с большим запасом (во-первых, на CR, во-вторых, на рост таблицы), или постоянно следить - что почти не реально.
Змей Равниныч
2) при установленной опции cache, если блока нет в кэше, перед чтением с диска нужно найти свободный блок - а это обычно не дешево.
Ну поскольку каждый второй запрос в системе обращается к этим таблицам то полностью они никогда вытесняться не будут (ктати они и сейчас без опции cache где-то на 30%-50% висят в кэше).
Змей Равниныч
Без опции cache при FTS и наличии asyns_io используются поочередно 2 группы блоков (без поиска свободных).
disk_asynch_io = TRUE (это установка по умолчанию в 9.2)
Так что это видимо не дает нужного эффекта.
13 сен 07, 17:21    [4664711]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
G.M.
Member

Откуда:
Сообщений: 342
eml78

Т.е. по вашему keep лучше чем установить опцию cache?
А не могли бы вы пояснить почему... (т.к. я пока не вижу особых преимуществ у вараинта с keep).

С опцией cache прочитанные блоки всего лишь помещаются в начало списка LRU и в дальнейшем могут выпасть из буферного кэша. Тогда как из keep pool они не выпадут.
С другой стороны, у вас скорее всего интенсивно используется лишь небольшая часть этих таблиц, содержащая данные за последний месяц-полтора. Поэтому весьма вероятно, что она и без всяких дополнительных телодвижений висит в кэше.
13 сен 07, 18:10    [4665259]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
G.M.
Member

Откуда:
Сообщений: 342
блин, глупость сморозил про "висит в кэше" :((
13 сен 07, 18:12    [4665274]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
tru55
Member

Откуда: СПб
Сообщений: 19790
Тогда как из keep pool они не выпадут

маленькое уточнение - если размер кэша достаточен...
13 сен 07, 18:13    [4665283]     Ответить | Цитировать Сообщить модератору
 Re: Keep vs Cache  [new]
Змей Равниныч
Member

Откуда: Из тридевятого царства
Сообщений: 284
G.M.
С опцией cache прочитанные блоки всего лишь помещаются в начало списка LRU и в дальнейшем могут выпасть из буферного кэша. Тогда как из keep pool они не выпадут.

G.M.
блин, глупость сморозил
:)
13 сен 07, 20:16    [4665822]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить