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

Откуда:
Сообщений: 6
Добрый день!

Эффективность KEEP пула сомнения не вызывает, но RECYCLE? Некоторые источники описывают этот пул как напрасное расходование памяти.

Посоветуйте, пожалуйста, в каких случаях можно использовать RECYCLE POOL.
2 июн 08, 12:20    [5746112]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
ы!
Guest
alex_kaz

Посоветуйте, пожалуйста, в каких случаях можно использовать RECYCLE POOL.

ИМХО - блоб, когда в нём не хранятся элементы интерфейса.
2 июн 08, 12:46    [5746290]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
Балшой таблиц с балшим индексом.
Данные из балшой таблиц выбираются через балшой индекс вразброс, то бишь постоянно читаются разные блоки. При этом невелика вероятность, что только что прочитанные блоки, ораклу понадобятся в обозримом будущем. А эти блоки забивают кеш и вытесняют оттуда полезные блоки.
Возможно, окажется полезным поместить этот таблиц с индексом в RECYCLE POOL.

--
Все выше написанное является моим личным нескромным мнением и может не совпадать с официальной позицией корпорации Oracle
2 июн 08, 13:12    [5746446]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
ы!
alex_kaz

Посоветуйте, пожалуйста, в каких случаях можно использовать RECYCLE POOL.

ИМХО - блоб, когда в нём не хранятся элементы интерфейса.

RECYCLE - пул под таблицы, по которым раз в час делают FULL SCAN и не делают активного индексного доступа. Блоки таких таблиц хранить в памяти - зло. Поэтому его стоит делать настолько маленьким, насколько возможно.
Если такие ситуации присутствуют - RECYCLE POOL может помочь. Если нет - то и фиг бы с ним.
2 июн 08, 13:16    [5746467]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
alex_kaz
Member

Откуда:
Сообщений: 6
Юный падаван
Балшой таблиц с балшим индексом.
Данные из балшой таблиц выбираются через балшой индекс вразброс, то бишь постоянно читаются разные блоки. При этом невелика вероятность, что только что прочитанные блоки, ораклу понадобятся в обозримом будущем. А эти блоки забивают кеш и вытесняют оттуда полезные блоки.
Возможно, окажется полезным поместить этот таблиц с индексом в RECYCLE POOL.

--
Все выше написанное является моим личным нескромным мнением и может не совпадать с официальной позицией корпорации Oracle


Тогда из каких соображений выбирать размер RECYCLE POOL? Какое должно быть идеальное соотношение между размером кэша и размером таблиц, расположенных в нем?
2 июн 08, 13:18    [5746488]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
RA\/EN
RECYCLE - пул под таблицы, по которым раз в час делают FULL SCAN и не делают активного индексного доступа. Блоки таких таблиц хранить в памяти - зло. Поэтому его стоит делать настолько маленьким, насколько возможно.
Если такие ситуации присутствуют - RECYCLE POOL может помочь. Если нет - то и фиг бы с ним.


Пад столом

з.ы. рассказать, как читаются блоки большой таблицы при FULL SCAN, если у таблицы нет опции cache, или сам догадаешься?
2 июн 08, 13:21    [5746503]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
ы!
Guest
Юный падаван

з.ы. рассказать, как читаются блоки большой таблицы при FULL SCAN, если у таблицы нет опции cache, или сам догадаешься?

Расскажи расскажи. Не забудь, что при фул скане всё равно все блоки идут через тот же буферный кэш.
Так что они точно так же вытесняют то, что там уже есть.
зы: Приписку свою не забудь.
2 июн 08, 13:44    [5746656]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
Юный падаван


Пад столом

з.ы. рассказать, как читаются блоки большой таблицы при FULL SCAN, если у таблицы нет опции cache, или сам догадаешься?

Как выберешься оттуда, расскажи. Про cache на досуге догадаюсь, думаю, а пока жду с нетерпением, как блоки читаются...
2 июн 08, 13:51    [5746728]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
ы!
Юный падаван

з.ы. рассказать, как читаются блоки большой таблицы при FULL SCAN, если у таблицы нет опции cache, или сам догадаешься?

Расскажи расскажи. Не забудь, что при фул скане всё равно все блоки идут через тот же буферный кэш.
Так что они точно так же вытесняют то, что там уже есть.
зы: Приписку свою не забудь.

Еще один "знаток"

Не уверен, что осилишь, но пропробуй :)

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production

SQL> select table_name, buffer_pool from dba_tables where table_name='TEST';

TABLE_NAME                     BUFFER_
------------------------------ -------
TEST                           DEFAULT

SQL> alter session set events '10046 trace name context forever, level 1';

Session altered.

SQL> select /* 1 */ count(*) from test;

  COUNT(*)
----------
     94816

SQL> select /* 2 */ count(*) from test;

  COUNT(*)
----------
     94816

10046
PARSING IN CURSOR #1 len=33 dep=0 uid=21 oct=3 lid=21 tim=10260492388 hv=922791656 ad='693e44a8'
select /* 1 */ count(*) from test
END OF STMT
PARSE #1:c=0,e=142,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=10260492376
EXEC #1:c=0,e=114,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=10260497074
FETCH #1:c=46875,e=265737,p=1151,cr=1155,cu=0,mis=0,r=1,dep=0,og=4,tim=10260763644
FETCH #1:c=0,e=4,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=10260765336
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE '
STAT #1 id=2 cnt=94816 pid=1 pos=1 obj=6018 op='TABLE ACCESS FULL OBJ#(6018) '
=====================
PARSING IN CURSOR #1 len=33 dep=0 uid=21 oct=3 lid=21 tim=10264022140 hv=643487622 ad='693e3244'
select /* 2 */ count(*) from test
END OF STMT
PARSE #1:c=0,e=157,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=10264022129
EXEC #1:c=0,e=98,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=10264025887
FETCH #1:c=62500,e=275527,p=1151,cr=1155,cu=0,mis=0,r=1,dep=0,og=4,tim=10264302279
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=10264303909
XCTEND rlbk=0, rd_only=1
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE '
STAT #1 id=2 cnt=94816 pid=1 pos=1 obj=6018 op='TABLE ACCESS FULL OBJ#(6018) '


з.ы. и это, курить завязывай - остатки мозгов прокуришь ;-)

ну и спешиал фо ю
--
Все выше написанное является моим личным нескромным мнением и может не совпадать с мнением местных "знатоков"
2 июн 08, 22:23    [5749626]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
RA\/EN
Как выберешься оттуда, расскажи. Про cache на досуге догадаюсь, думаю, а пока жду с нетерпением, как блоки читаются...

Честно говоря, был о тебе лучшего мнения :)

Попробуй почитать на досуге про lru/mru, механизм touch, куда читаются блоки при fullscan некешированной большой таблицы, async_io и т.д.
2 июн 08, 22:27    [5749633]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
Ну и вопрос "знатокам" на засыпку от зрителей:

"Вот у нас буфер кеш 100М, решили мы сделать fullscan некешированной таблицы в 150М, что у нас весь буфер кеш забьется блоками таблицы?"

з.ы. вопрос риторический можно не отвечать ;-)
2 июн 08, 22:30    [5749642]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
alex_kaz
Тогда из каких соображений выбирать размер RECYCLE POOL? Какое должно быть идеальное соотношение между размером кэша и размером таблиц, расположенных в нем?

Сколько не жалко, исходя из того, что в общем случае чем меньше, тем лучше (у нас нет задачи хранить эти блоки).
Думать о соотношении здесь особо нет смысла, имхо.
2 июн 08, 22:33    [5749649]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Fucker
Member [заблокирован]

Откуда:
Сообщений: 1525
Юный падаван
Балшой таблиц с балшим индексом.
Данные из балшой таблиц выбираются через балшой индекс вразброс, то бишь постоянно читаются разные блоки. При этом невелика вероятность, что только что прочитанные блоки, ораклу понадобятся в обозримом будущем. А эти блоки забивают кеш и вытесняют оттуда полезные блоки.
Фразой "эти блоки забивают кеш и вытесняют оттуда полезные блоки" ты явно показал, что ты ни хрена не понимаешь, что такое touch count, для чего и как он используется Ораклом.

Этот показатель у свежепрочитанного блока будет ведь заведомо ниже, нежели у "полезного".
Посмотри, чему будут равны x$bh.tch для твоих "экспериментов" и много ли будет значений, отличных от 0.
Юный падаван
Все выше написанное является моим личным нескромным мнением и может не совпадать с официальной позицией корпорации Oracle
Оно не только не совпадает с официальной позицией Оракле, оно также не имеет ничего общего с реальной действительностью.
Юный падаван
з.ы. рассказать, как читаются блоки большой таблицы при FULL SCAN, если у таблицы нет опции cache, или сам догадаешься?
Нет, спасибо, не надо. Ты уже показал свою полную импотентность в Оракловой тематике...
Я так понимаю, мое предсказание насчет хЕрурга сбылось?
3 июн 08, 02:10    [5749903]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Сргей
Member

Откуда:
Сообщений: 3
Глянь те тему, дайте совет как бы ва стали решать проблему ?
Как организовать инкрементное поля по блокам в запросе
3 июн 08, 02:17    [5749905]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Fucker
Member [заблокирован]

Откуда:
Сообщений: 1525
Юный падаван
10046

select /* 1 */ count(*) from test
FETCH #1:c=46875,e=265737,p=1151,cr=1155,cu=0,mis=0,r=1,dep=0,og=4,tim=10260763644
=====================
select /* 2 */ count(*) from test
FETCH #1:c=62500,e=275527,p=1151,cr=1155,cu=0,mis=0,r=1,dep=0,og=4,tim=10264302279


з.ы. и это, курить завязывай - остатки мозгов прокуришь ;-)

ну и спешиал фо ю
--
Все выше написанное является моим личным нескромным мнением и может не совпадать с мнением местных "знатоков"

В данном контексте трассировка этих двух запросов не несет никакой полезной информации.
В том, что в первом и во втором случае количество чтений было равно, ничего удивительного нет...

Если бы ты действительно разбирался в теме, в которую полез не подумав, то ты бы привел, как минимум, пару запросов из x$bh.
Заинтересовался бы количеством буферов, занятых прочитанными блоками сканируемой таблицы.
Возможно даже связал бы это количество с настройками экземпляра.

А пораскинув остатками мозгов, возможно даже сделал бы на самом деле полезный в данном контексте тестик:
посмотрел бы, как меняется поведение кеширования в зависимости от того, какой пул назначили читаемой табличке.

Я даже не требую, чтобы ты ответил на принципиальный вопрос:
а собственно, чем кроме названий различаются между собой KEEP, RECYCLE и DEFAULT POOL?
И корректна ли фраза, что все эти пулы работают по одному и тому же алгоритму?
3 июн 08, 02:27    [5749910]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
Fucker
Юный падаван
ы!
Расскажи расскажи. Не забудь, что при фул скане всё равно все блоки идут через тот же буферный кэш.
Так что они точно так же вытесняют то, что там уже есть.
зы: Приписку свою не забудь.
10046

select /* 1 */ count(*) from test
FETCH #1:c=46875,e=265737,p=1151,cr=1155,cu=0,mis=0,r=1,dep=0,og=4,tim=10260763644
=====================
select /* 2 */ count(*) from test
FETCH #1:c=62500,e=275527,p=1151,cr=1155,cu=0,mis=0,r=1,dep=0,og=4,tim=10264302279

В данном контексте трассировка этих двух запросов не несет никакой полезной информации.
В том, что в первом и во втором случае количество чтений было равно, ничего удивительного нет...

Если бы ты действительно разбирался в теме, в которую полез не подумав, то ты бы привел, как минимум, пару запросов из x$bh.
Заинтересовался бы количеством буферов, занятых прочитанными блоками сканируемой таблицы.
Возможно даже связал бы это количество с настройками экземпляра.

А пораскинув остатками мозгов, возможно даже сделал бы на самом деле полезный в данном контексте тестик:
посмотрел бы, как меняется поведение кеширования в зависимости от того, какой пул назначили читаемой табличке.

Позволю себе напомнить тебе контекст темы - он был, что при фуллскане раз в час блоки остаются в кеше, поэтому такую таблицу нужно помещать в recycle, а не default пул, ну и еще была фраза, что эти блоки вымывают другие из кеша. В этом контексте пример показателен, если ты не осилил его смысл - то это проблемы негров, а они как известно мало кого интересуют ;-)
По поводу "остатков мозгов", "разбирался в теме" и кучи умных слов, так это все пока кроме слов ничем не подкреплено, разве что ссылками на удав

Раз уж ты влез в тему, и начал меня поливать, я так понимаю, ты согласен с Raven'ом ? ;-)
3 июн 08, 08:53    [5750082]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Сына
Member

Откуда:
Сообщений: 804
Fucker
Я даже не требую, чтобы ты ответил на принципиальный вопрос:
а собственно, чем кроме названий различаются между собой KEEP, RECYCLE и DEFAULT POOL?
И корректна ли фраза, что все эти пулы работают по одному и тому же алгоритму?

Ставлю на то, что алгоритм один. Различаются параметры, используемые в этом алгоритме.
3 июн 08, 10:25    [5750501]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Fucker
Member [заблокирован]

Откуда:
Сообщений: 1525
Сына
Fucker
Я даже не требую, чтобы ты ответил на принципиальный вопрос:
а собственно, чем кроме названий различаются между собой KEEP, RECYCLE и DEFAULT POOL?
И корректна ли фраза, что все эти пулы работают по одному и тому же алгоритму?

Ставлю на то, что алгоритм один. Различаются параметры, используемые в этом алгоритме.
угу, _db_percent_hot%
3 июн 08, 10:37    [5750562]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
.....
Member

Откуда:
Сообщений: 473
Юный падаван
....


ОФФ ты, это юный малдаван, завязывай уже ораклу мучить, пока класть плитку.
3 июн 08, 11:41    [5750976]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
Юный падаван

Позволю себе напомнить тебе контекст темы - он был, что при фуллскане раз в час блоки остаются в кеше, поэтому такую таблицу нужно помещать в recycle, а не default пул, ну и еще была фраза, что эти блоки вымывают другие из кеша. В этом контексте пример показателен, если ты не осилил его смысл - то это проблемы негров, а они как известно мало кого интересуют ;-)
По поводу "остатков мозгов", "разбирался в теме" и кучи умных слов, так это все пока кроме слов ничем не подкреплено, разве что ссылками на удав

Раз уж ты влез в тему, и начал меня поливать, я так понимаю, ты согласен с Raven'ом ? ;-)


Я в курсе, в какую часть кэша кладутся блоки при многоблочном чтении (начиная с 9-ки, в 8-ке, кажется, было все очень тупо). Что они "остаются", я не говорил, а вот то, что они, несмотря на теоретическую идиллию про холодный, как северный полюс, конец LRU, могут отожрать достаточно большой кусок памяти - это факт. И этой памяти можно было бы найти более достойное применение. Думаю (надо подумать/проверить) что при FULL SCAN блоки вполне могут вытеснить из кэша "чужие" блоки.

Еще следует обратить внимание на защелку cache buffers chains, хотя это не есть преимущество именно RECYCLE, а просто отдельного кэша.

А по поводу запихивания в RECYCLE таблиц для индексного доступа - это бабушка надвое сказала. Если у индекса хреновая кластеризация, то может оказаться лучше пожертововать вымыванием блоков из большого DEFAULT, чем многократным чтением одних и тех-же блоков в процессе сканирования таблицы по индексу:
Допустим, у нас в DEFAULT 100 блоков, в RECYCLE = 1 блок (индекс пусть будет вообще в нестандартном размере блока :)
Фактор кластеризации высок, но аггрегированная кластеризация вполне приемлема (т.е. каждая новая запись при IRS в новом блоке, но на 10 подряд идущих значений различных блоков - 5) - это достаточно часто встречающаяся ситуация.
Допустим, надо прочитать 1000 записей из таблицы (она большая).
При чтении через RECYCLE это будет 1000 чтений с диска.
При чтении через DEFAULT это будет 1000*(10/5)=500 чтений с диска. Чтобы вернуть DEFAULT в исходное состояние - еще 100 чтений.
Итого: 1000 чтений с диска через RECYCLE против 600 через DEFAULT (с учетом его гипотетического "полного вымывания", чего, конечно, не произойдет).
3 июн 08, 12:52    [5751615]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Partos
Member

Откуда:
Сообщений: 878
1)
1000*(10/5) <> 500

2)
автор

допустим, у нас в DEFAULT 100 блоков, в RECYCLE = 1 блок (индекс пусть будет вообще в нестандартном размере блока :)



в этом месте голова закипела
3 июн 08, 13:00    [5751706]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Сына
Member

Откуда:
Сообщений: 804
RA\/EN
Еще следует обратить внимание на защелку cache buffers chains, хотя это не есть преимущество именно RECYCLE, а просто отдельного кэша.

Мысль не уловил.
3 июн 08, 13:15    [5751857]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
Сына
RA\/EN
Еще следует обратить внимание на защелку cache buffers chains, хотя это не есть преимущество именно RECYCLE, а просто отдельного кэша.
Мысль не уловил.

Гм... Где-то мне промыли мозг по поводу раздельних наборов латчей на разные пулы. И в тесте вылезло, хотя я в нем, как мне теперь кажется, ошибся - при чтении через DEFAULT и через RECYCLE "левая" нагрузка была разная.
3 июн 08, 14:12    [5752312]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
RA\/EN
Сына
RA\/EN
Еще следует обратить внимание на защелку cache buffers chains, хотя это не есть преимущество именно RECYCLE, а просто отдельного кэша.
Мысль не уловил.

Гм... Где-то мне промыли мозг по поводу раздельних наборов латчей на разные пулы. И в тесте вылезло, хотя я в нем, как мне теперь кажется, ошибся - при чтении через DEFAULT и через RECYCLE "левая" нагрузка была разная.

А Вы случаем cache buffers chains с cache buffers lru chains не путаете?
3 июн 08, 14:14    [5752334]     Ответить | Цитировать Сообщить модератору
 Re: RECYCLE CACHE  [new]
Юный падаван
Member

Откуда: Бомбей
Сообщений: 216
.....
ОФФ ты, это юный малдаван, завязывай уже ораклу мучить, пока класть плитку.

Еще один "знаток", не осиливший тему? ;-)
3 июн 08, 14:17    [5752365]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить