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

Трейс полностью выкладывай, прикреплённым файлом.

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

wurdu

Дата: 21.11.2009 01:00:50

latch: cache buffers chains latch contention – a better way for finding the hot block

--Попрошайка--

Дата: 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

Не совсем так. При 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.