Большое количество курсоров, вызывающих медленный отклик и большую загрузку ЦП - cursor: mutex s

У нас проблема с нашим сервером Oracle. Пару месяцев назад он был обновлен до 11g и работает под управлением сторонней системы. Система работает в течение многих лет (и у нее было несколько других проблем), но это ново: один или два раза в день загрузка ЦП увеличивается, и Cursor Mutex S очень заметен, имея 30 миллионов событий ожидания с момента запуска сервера (что был недавно).

Кажется, что внезапно ряд простых INSERT начал давать проблемы. Мы проверили, что статистика, индексы и т. Д. В порядке - актуальны, имеют правильный размер, место на диске и т. Д. Проблем нет.

Мы выделили одно-единственное SQL-выражение как главную причину. Ряд похожих утверждений порождают аналогичные проблемы, но я остановлюсь на одном. «Промежуточное ПО», выполняющее эту конкретную вставку, одновременно работает на ~ 70 серверах.

Когда мы начали замечать проблемы, у этого оператора было более 10 000 записей в v@sql_shared_cursor. Мы настроили cron-задание, очищающее курсоры каждые пять минут, но это ничего не решает и лишь немного снижает проблему.

Снова глядя на v@sql_shared_cursor, оказывается, что причиной создания множества курсоров является INST_DRTLD_MISMATCH = Y. Это странно, поскольку промежуточное программное обеспечение (которое у нас мало прямого контроля) не вставляет такое количество строк.

Обратились к производителю и спросили, как делают вставки. Они ответили, что делают выбор из таблицы WHERE 1 = 0 чтобы получить структуру столбцов во внутреннем объекте ADODB, который затем заполняется соответствующими данными. Обычно выполняют от 1 до 20 вставок на пр. "партия".

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

Кто-нибудь может предложить понимание:

• Почему это происходит с самого начала?
• Если связано с 11g, то почему это происходит сейчас, через два месяца после обновления?
• Какие еще параметры мне следует рассмотреть, чтобы разобраться в этом?

РЕДАКТИРОВАТЬ: Оказывается, это вполне может быть ошибкой Oracle в Linux. В настоящее время мы тестируем патч, и я сам отправлю ответ через пару дней, если он окажется правдой.

EDIT2: патч не исправил это - и, хотя мы, вероятно, не нашли причину, мы, возможно, облегчили проблему, увеличив количество журналов повторного выполнения. Я все еще надеюсь написать ответ на это в какой-то момент.