Что даст полезного сия информация для тюнинга merge что без нее непонятно?

Действовать как правило лучше скальпелем чем кувалдой.

Здравый смысл подсказывает, что если в обычных условиях всё работает ОК, то в конкретном примере должна быть деталь, которая порождает проблему и эту деталь 99.9% можно определить без callstack.

Например, можно еще проверить компрессию таблицы.
Был ли concurrent сбор статистики или DDL типа alter table, index rebuild, etc.
Можно посмотреть другие детали из ash (sql_exec_id, sql_exec_start, что косвенно может указывать на рестарт, но вряд ли это тот случай).

На версии 11.2 мы сталкивались с тем, что при параллельный DML в subpartitioned table Oracle накладывал TM enqueue in exclusive mode на все подсекции в результате чего либо всё вставало колом либо вообще сыпались дедлоки. Это опять же не этот случай, но намекает что может быть полнейший абсурд и неплохо бы еще раз понаблюдать за блокировками во время выполнения (в ash то попадает только active).

Если есть база для экспериментов, то неплохо бы воспроизвести, потом выполнить без параллельности и еще без sub-partitions. Так путем проб и анализа нащупывается подход который работает приемлемо.
Еще раз: определяется фактор из-за которого проблема с производительностью. Дальнейший вопрос уже как это решать - code fix, patch (или вообще миграция на новую версию), или банально некоторая манипуляция DBA.

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

Можно пойти дальше - дизассемблер в руки и ковырять кишки. Этот парень может много про это рассказать.

xtender,

Саян, а может тебе хватит выступать адвокатом людей и указывать что кому делать?
Ты не заметил как после твоих нравоучений ( 22122317 ) неожиданно пропал -2-, санитар леса ты наш.

Я просто спросил как ему поможет знание callstack в решении этой конкретной проблемы. Про наезды это твои домыслы.

Может ты дашь хотя бы одну ссылку где лично ты описываешь как тебе помог callstack, я с удовольствием почитаю.
Только не надо давать ссылки на описание в духе "наука ради науки", я тоже не раз ковырял сие.

Мне будет абсолютно индифферентно. Чья-то характеристика моего высказываения не влияет на его истинность или ложность.
Конструкция как раз была приведена чтобы адресат обосновал необходимость более общей конструкции, если в ней есть необходимость для его целей (которые мне были не до конца ясны).
Факт кривой копипасты тоже абсолютно очевиден. У меня нет особого ЧСВ и это меня никак не ранит.
Мда... если в том, что у тебя просят одну ссылку видеть наезд это уже просто без комментариев.

Спасибо за предложение на писать на почту, на этом, пожалуй, можно закруглится.
Я думаю твоя позиция про очень здравый правильный системный траблшутинг TX - contention в случае merge понятна, но мне было интересно мнение господина Анохина.

Санёк, спасибо что находишь возможность мне ответить!
Мне по прежнему не совсем понятно какие дальнейшие шаги при таком подходе после получения стека.
Искать ядрёные функции на металинке или еще чего.
Так для чего по фен-шую делать hanganalyze в этом случае?
Для просмотра полного дерева блокировок или callstack или всё сразу?
И главное в какой момент если