Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
pectopatop
Member

Откуда:
Сообщений: 765
Подскажите, плиз, куда копать.
Имеется большая таблица (Приемник), в нее из другой большой таблицы (Источника), после некоторого преобразования, merge-аться данные (~10% вставляется, ~90% апдейтится).
Сделано это в параллельных сессиях, т.е. параллельные сессии хватают куски Источника (каждый свой кусок, деление по id идет), вываливают куски в global temporary table, преобразуют немного данные, и merge-ат свои части в большой Приемник.
Обычно все сессии приходят к моменту merge примерно в одно время.

Когда сессий было 4-5 блокировок не было.
Когда таблицы подросли и сессий стало с десяток - стали появляться блокировки сессий между собой (например из 10: 4 merge-ат, 6 ждут).
Когда таблицы еще подросли и сессий стало под сотню - блокировки уже стали навязчивым кошмаром (например из 100 сессий: 5 merge-ат, 95 ждут).

Блокировки везде на уровне строки (update), наборы данных у сессий разные.
Правильно ли я понимаю, что тут дело в количество дисков на сервере? Что-либо с выделением сегментом для вставляемых строк?

К сожалению, наблюдать процесс в живую весьма затруднительно. В основном только по логам.
16 фев 12, 09:43    [12100597]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Для начала надо посмотреть на события ожидания, т.к. блокировки бывают разные. Может они апдейтят одни и те же строки... Тогда enq: tx row lock contention. А может они лезут в один блок, тогда может enq: TX - allocate ITL entry. Ты же знаешь про блоки, ITL ? Про parallel execution наконец чтоб не извращаться с сессиями.
16 фев 12, 10:04    [12100695]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
ice_79
Member

Откуда: Тула
Сообщений: 35
А может дело в реализации самого MERGE в СУБД?.
Я как то отказался от использования MERGE потому как была аналогичная проблема - две сессии, (гарантированно разные наборы данных) и блокировки.

Причем т.к. для изменения выходной таблицы использовался не только MERGE, то одна из сессий падала с deadlock-ом.

Логика была примерно такая:
INSERT INTO TBL ...
MERGE INTO TBL ...

INSERT был долгий, MERGE короткий. INSERT-ы выполнялись параллельно отлично, потом MERGE одной из сессий начинал ждать получения блокировки (его блокировала вторая сессия, где шел INSERT, хотя по человеческой логике записи не пересекались и даже были в разных секциях), как только вторая сессия доходила до MERGE - она дохла.

Так что мое ИМХО, что MERGE не подходит для параллельного изменения данных одной таблицы в разных сессиях, т.к. при MERGE СУБД не может "корректно" (т.е. как предполагает человек) определить перечень записей для блокировки.

P.S. Может преобразования делать в разных сессиях, а MERGE - один общий?
16 фев 12, 10:29    [12100852]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
ice_79
Member

Откуда: Тула
Сообщений: 35
А может дело в реализации самого MERGE в СУБД?.
Я как то отказался от использования MERGE потому как была аналогичная проблема - две сессии, (гарантированно разные наборы данных) и блокировки.

Причем т.к. для изменения выходной таблицы использовался не только MERGE, то одна из сессий падала с deadlock-ом.

Логика была примерно такая:
INSERT INTO TBL ...
MERGE INTO TBL ...

INSERT был долгий, MERGE короткий. INSERT-ы выполнялись параллельно отлично, потом MERGE одной из сессий начинал ждать получения блокировки (его блокировала вторая сессия, где шел INSERT, хотя по человеческой логике записи не пересекались и даже были в разных секциях), как только вторая сессия доходила до MERGE - она дохла.

Так что мое ИМХО, что MERGE не подходит для параллельного изменения данных одной таблицы в разных сессиях, т.к. при MERGE СУБД не может "корректно" (т.е. как предполагает человек) определить перечень записей для блокировки.

P.S. Может преобразования делать в разных сессиях, а MERGE - один общий?
16 фев 12, 10:33    [12100891]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
pectopatop
Member

Откуда:
Сообщений: 765
wurdu
Для начала надо посмотреть на события ожидания, т.к. блокировки бывают разные. Может они апдейтят одни и те же строки... Тогда enq: tx row lock contention. А может они лезут в один блок, тогда может enq: TX - allocate ITL entry. Ты же знаешь про блоки, ITL ? Про parallel execution наконец чтоб не извращаться с сессиями.

Спасибо.
Действительно, ожидания = "enq: TX - allocate ITL entry".
Т.е. получается сущестующий механизм нельзя никак заставить работать без блокировок (если одновременно merge сессий идут) ?

ice_79
P.S. Может преобразования делать в разных сессиях, а MERGE - один общий?

Дык параллельные сессии (100 штук) - работают же с global temporary table, каждый со своей материализацией, одной таблицы.
Merge один общий - это из одной общей таблицы же :) (в которую, если опять же вставлять предварительно, то всеми параллельно ))))
16 фев 12, 13:57    [12102963]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
pectopatop
Member

Откуда:
Сообщений: 765
Если только заранее не раскусывать таблицу-Приемник по блокам, и не раздавать сессиям соответствующие куски Источника...
?
Но это больно гиморно по выч.соображениям
16 фев 12, 13:59    [12102981]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
pectopatop
Если только заранее не раскусывать таблицу-Приемник по блокам, и не раздавать сессиям соответствующие куски Источника...
?
Но это больно гиморно по выч.соображениям

партишенинг
16 фев 12, 14:05    [12103033]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
pectopatop
Если только заранее не раскусывать таблицу-Приемник по блокам, и не раздавать сессиям соответствующие куски Источника...
?
Но это больно гиморно по выч.соображениям
Почему нельзя использовать /*+ parallel */ ?
16 фев 12, 14:12    [12103104]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
pectopatop
wurdu
Для начала надо посмотреть на события ожидания, т.к. блокировки бывают разные. Может они апдейтят одни и те же строки... Тогда enq: tx row lock contention. А может они лезут в один блок, тогда может enq: TX - allocate ITL entry. Ты же знаешь про блоки, ITL ? Про parallel execution наконец чтоб не извращаться с сессиями.

Спасибо.
Действительно, ожидания = "enq: TX - allocate ITL entry".


Гляньте сюда
И погулите другие темы по гарячим блокам.

Когда вы их найдете , вы увидите ( инфа 100 99%),
что гарячие конкурентные блоки у вас в индексах таблицы приемника.
16 фев 12, 14:55    [12103448]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
ДохтаР
pectopatop
пропущено...

Спасибо.
Действительно, ожидания = "enq: TX - allocate ITL entry".


Гляньте сюда
И погулите другие темы по гарячим блокам.

Когда вы их найдете , вы увидите ( инфа 100 99%),
что гарячие конкурентные блоки у вас в индексах таблицы приемника.
С горячими блоками иногда связывают проблему с cache buffer chains / buffer busy waits. Но вот "enq: TX - allocate ITL entry" это проблема совсем иного плана и никак не связана с кол-вом чтений буфера, а вполне предсказуема для алгоритма который используется у автора. Обычно лечится увеличением initrans, но в данном случае я бы не стал.
16 фев 12, 15:52    [12103895]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
wurdu
ДохтаР
пропущено...


Гляньте сюда
И погулите другие темы по гарячим блокам.

Когда вы их найдете , вы увидите ( инфа 100 99%),
что гарячие конкурентные блоки у вас в индексах таблицы приемника.
С горячими блоками иногда связывают проблему с cache buffer chains / buffer busy waits. Но вот "enq: TX - allocate ITL entry" это проблема совсем иного плана и никак не связана с кол-вом чтений буфера,


Возможно я не так сформулировал суть моей мысли.

wurdu
а вполне предсказуема для алгоритма который используется у автора.


Согласен, предсказуема.

Я могу предсказать следующий сценарий.
Количество паралельных транзакций и колчество изменений пересекаются
на ограниченном количестве конкурентных блоков .
Нужно вычислить на каком обьекте возникает это пересечение.

Какой евент мы получим enq: TX - allocate ITL entry или buffer busy waits не суть важно причина тут
ИМХО одна.
Толкотня множества сессий вокруг ограниченного количества блоков.



wurdu
Обычно лечится увеличением initrans, но в данном случае я бы не стал.


Самый очевидное ИМХО средство
сократить количесто изменяемых строк одной транзакцией. (меньше порции и чаще коммитить).

Как только уйдем от текущего эвента, и слотов станет достаточно,
с очень большой вероятностью получим buffer busy waits,
без кардинального прироста в производительности.
Так как с ростом обьемов количество сессий у ТС постоянно растет .

Проблему нужно решать в корне.
Корень ,как я его вижу, конкуренция сессий на уровне блоков индекса.
Или как варинат кардинальное увеличение длины записей при апдейте с последующим row chaining.
16 фев 12, 17:23    [12104895]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки в параллельных merge (разные наборы данных) ?  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
ДохтаР
Или как варинат кардинальное увеличение длины записей при апдейте с последующим row chaining.


Правильнее даже сказать не row chaining а Row Migration.

Пруф

автор
Index Read will cause additional IO's on migrated rows

When we Index Read into a table, then a migrated row will cause additional IO's. That is because the index will tell us «goto file X, block Y, slot Z to find this row». But when we get there we find a message that says «well, really goto file A, block B, slot C to find this row». We have to do another IO (logical or physical) to find the row.


Поведение мною досконально не изучено, но я ИМХО подозреваю,
что сессии могут толкаться вокруг блоков содержащих большое
количество Forward Address.
16 фев 12, 17:46    [12105114]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить