cache buffer chains

тобобетобор
Дата: 20.11.2009 18:52:53
есть тормозящий процесс. снял трассировку с ожиданиями. на первом месте latch free.
в трэйсе записи вида
WAIT #42: nam='latch free' ela= 10680 p1=1672436376 p2=98 p3=0
WAIT #30: nam='latch free' ela= 11281 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 10639 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 11458 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 16012 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 14613 p1=1672503304 p2=98 p3=1
WAIT #30: nam='latch free' ela= 10949 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 18176 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 10853 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 10036 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 10388 p1=1672503304 p2=98 p3=0
WAIT #30: nam='latch free' ela= 10046 p1=1672503304 p2=98 p3=0
копаю дальше:
98="cache buffer chains"
запрос #30 простейший
SELECT ID FROM t1 WHERE A = :B5 AND C = :B4 AND G = :B3 AND L = :B2 AND R = :B1
причем по полям (G, L, R, A) есть уникальный индекс, по которому идет запрос, т.е. оптимизировать нечего...
Вопрос - что нужно сделать чтобы убрать ожидания ? откуда здесь "cache buffer chains" ?
trc
Дата: 20.11.2009 20:19:36
Трейс полностью выкладывай, прикреплённым файлом.
reverse index
Дата: 20.11.2009 22:01:36
индекс в рверсивный переделай (ну если у тебя предикаты только на равенство)
тобобетобор
Дата: 21.11.2009 00:44:42
reverse index
индекс в рверсивный переделай (ну если у тебя предикаты только на равенство)
можно ссылочку - каким образом это может помочь в моем случае ?
тобобетобор
Дата: 21.11.2009 00:46:49
trc
Трейс полностью выкладывай, прикреплённым файлом.
гигабайт ? не, жалко форум засорять. что нужно из трэйса ? я вроде процитировал все что надо...
--Попрошайка--
Дата: 21.11.2009 11:22:52
wurdu
latch: cache buffers chains latch contention – a better way for finding the hot block


ИМХО, сильно укрупненное мнение.

Там же по сути как сделано, если упрощенно. Есть некоторые цепочки блоков, которые по некоторому алгоритму разделены на "кучки" и между собой сцеплены в так называемые цепочки. Сам Oracle работая с кэшем защищает не только конкретные блоки, но и "кучки" блоков (цепочки), делая работу последовательной на столько - на сколько это необходимо для согласованности. Таким образом, отдельно взятый блок и "кучка" блоков (цепочка) - это отдельные ресурсы, которые могут быть популярными либо не популярными по отдельности.

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

А системные ресурсы? Защелка: закрыл-сделал-открыл. Вдруг тут проблема?
wurdu
Дата: 21.11.2009 11:52:26
--Попрошайка--
wurdu
latch: cache buffers chains latch contention – a better way for finding the hot block


ИМХО, сильно укрупненное мнение.

Там же по сути как сделано, если упрощенно. Есть некоторые цепочки блоков, которые по некоторому алгоритму разделены на "кучки" и между собой сцеплены в так называемые цепочки. Сам Oracle работая с кэшем защищает не только конкретные блоки, но и "кучки" блоков (цепочки), делая работу последовательной на столько - на сколько это необходимо для согласованности. Таким образом, отдельно взятый блок и "кучка" блоков (цепочка) - это отдельные ресурсы, которые могут быть популярными либо не популярными по отдельности.
Не совсем так. При SELECT в начале CBCL берется в shared mode, затем находится нужный буфер, после этого происходит апгрэйд CBCL до exclusive mode (вот тут наступает конкуренция), берется buffer pin, отпускается CBCL, читается буфер, опять берется CBCL в exclusive mode (опять конкуренция), отпускается пин, отпускается CBCL.
автор
Например, представим ситуацию, когда самые востребованные блоки (не обязательно "горячие") попали в одну "кучку".
Ну вот такие блоки и называются "горячими" :)
--Попрошайка--
Дата: 21.11.2009 12:29:40
wurdu


автор
Например, представим ситуацию, когда самые востребованные блоки (не обязательно "горячие") попали в одну "кучку".


Ну вот такие блоки и называются "горячими" :)



Это возникает (ИМХО) не из-за того, что блок горячий (то есть, для решения какой-то задачи требуется только этот один несчастный блок, так скажем), а из-за того, что цепочка слишком длинная. Таким образом, в нее могут попасть блоки, которые самые востребованые в контексте определенной работы.

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

wurdu, сама операция "апгрэйд CBCL до exclusive mode" как физически выглядит?
wurdu
Дата: 21.11.2009 12:59:22
--Попрошайка--
wurdu, сама операция "апгрэйд CBCL до exclusive mode" как физически выглядит?
Ну совсем уж физически я не знаю, да и не интересно, пожалуй. Смысл в том, что по крайней мере в 10g для того, чтобы просмотреть hash chain латч берется в shared mode, соответственно другие операции совместимые с shared mode допустимы (т.е. другие просмотры цепочки в shared mode не блокируются). Ну а логически апгрэйд выглядит так, что латч становится в exclusive mode и соответственно остальные уже не могут получить латч и ждут на cache buffer chains.