Я с коллегой разбирали интересный случай, связанный с ожиданием ‘latch: row cache objects’ при выполнении запроса.

По ASH на ожидание ‘latch: row cache objects’ уходило значительная часть времени (до 48%):

Большое количество времени теряется на ожидании ‘latch: row cache objects’ Дополнительно, проанализировав трассировку 10046, выявлена большая ‘не учтённая’ часть времени:

Данные приведённые на рис 1. и рис. 2 взяты от разных сессий, но сути дела это не меняет. Далее выяснилось, что конкуренция ведётся за области словаря данных dc_users и dc_tablespace.

Исходя из доступных описаний dc_users и dc_tablespace, непонятно, для чего понадобилась блокировка(latch) при выполнении оператора select. Далее, была использована утилита perf для анализа вызовов на уровне OS и получена следующая картина:

На основе имеющихся данных была найдена статья ‘12c: эффекты Automatic Dynamic Sampling’.

Где указывалось, что защёлки ‘dc_users’ и ‘dc_tablespace’ могут быть связаны с HJ и багом 13902396. В баге 13902396, в разделе DIAGNOSTIC ANALYSIS есть ‘qerhjFetch’ как на рисунке, и решение на основе HJ.

Смотрим ASH ещё раз:

Теперь проблема выглядит не такой сложной…

Проблема воспроизводится в 11.2.0.4 и 12.1.0.2, обе версии имеют нужные PSU. 

Теперь мы можем попробовать сделать что ни будь с HJ. Я принял решение использовать параметр “_gby_hash_aggregation_enabled = false” на уровне сессии(это задание по расписанию). После применения параметра “_gby_hash_aggregation_enabled = false”, ожидание защёлки исчезло, производительность определённого SQL выражения выросло в 4 раза, с 5тыс выполнений в секунду до 20тыс выполнений в секунду.