бывает, что DML работает как-то дольше обычного

протохипстер с экзадатой
Дата: 20.10.2015 19:59:30
приветствую.

версия:
+

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production


столкнулся с такой проблемой, что время выполнения некоторых однотипных DML операторов значительно выше их средней по больнице

сразу пример, приложение в какой-то момент времени решает 50 раз выполнить оператор(меняя бинды)
лог этого приложения показывает такую картинку

+


......
UPDATE CUSTOMER_BALANCE SET
MOD_NUM = MOD_NUM + 1,
UPDATED_USER = :1,
CHANGED_DATE = :2,
AMOUNT_SPENT = AMOUNT_SPENT + :3
WHERE
REC_ID = :4
DBSQLLogger Bind variable 1: 5
DBSQLLogger Bind variable 2: 10/20/2015 09:30:27
DBSQLLogger Bind variable 3: 170
DBSQLLogger Bind variable 4: 76534

***** SQL Statement Write Time: 0.010 seconds *****

UPDATE CUSTOMER_BALANCE SET
MOD_NUM = MOD_NUM + 1,
UPDATED_USER = :1,
CHANGED_DATE = :2,
AMOUNT_SPENT = AMOUNT_SPENT + :3
WHERE
REC_ID = :4
DBSQLLogger Bind variable 1: 5
DBSQLLogger Bind variable 2: 10/20/2015 09:30:27
DBSQLLogger Bind variable 3: 200
DBSQLLogger Bind variable 4: 76535

***** SQL Statement Write Time: 0.947 seconds *****

UPDATE CUSTOMER_BALANCE SET
MOD_NUM = MOD_NUM + 1,
UPDATED_USER = :1,
CHANGED_DATE = :2,
AMOUNT_SPENT = AMOUNT_SPENT + :3
WHERE
REC_ID = :4
DBSQLLogger Bind variable 1: 5
DBSQLLogger Bind variable 2: 10/20/2015 09:30:27
DBSQLLogger Bind variable 3: 80
DBSQLLogger Bind variable 4: 76536

***** SQL Statement Write Time: 0.003 seconds *****
......


REC_ID - primary key
по 4ем изменяемым полям индексов нет
триггеров нет
таблица партиционирована по полю, которое тут не представлено(некий хеш от номера счета), но все изменяемые строки в одной партиции
все операции выполняются последовательно
за исключением одной представленной, время выполнения каждой из 49и операций не превышает 0.012 секунды
таблица с ее индексами весит на текущий момент 146 Gb



помогите, пожалуйста, понять, откуда всплывает такое аномальное и выделяющееся на фоне остальных время выполнения

дополнительные переменные:
подобное поведение наблюдается на операциях обновления и инсерта, т.е. бывает так, что инсерт(все так же с биндами) работает 0.012 секунды, а тут бац и 0.650 секунд
подобное поведение наблюдается не только на этой таблице
не все таблицы где наблюдается это поведение побиты на партиции, есть и обычные в виде кучки
есть ряд явных косвенных причин, по которым я считаю что дело не в блокировках, но не могу быть уверенным на 100%
на тестовых средах(бд там в десятки раз меньше) повторить это поведение не получается

буду рад выслушать любые посылы в сторону того как и куда мне в этой ситуации копать, что бы добраться до истины
Elic
Дата: 20.10.2015 20:41:50
протохипстер с экзадатой
что бы добраться до истины
К экзадатам нынче пускают владеющих логами приложения, но не слышавших о трассировке сессии?
протохипстер с экзадатой
Дата: 20.10.2015 21:15:09
Elic
протохипстер с экзадатой
что бы добраться до истины
К экзадатам нынче пускают владеющих логами приложения, но не слышавших о трассировке сессии?


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

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

Elic, "вали снимай 10053, потом поговорим" - это для меня было бы достаточным ответом, но может есть шансы разобраться без этого?
Elic
Дата: 20.10.2015 21:39:33
протохипстер с экзадатой
"вали снимай 10053, потом поговорим"
В целом, да, если иметь в виду правильное число.
протохипстер с экзадатой
нет, не пускают. этим занимаются специально обученные люди.
Отсутствие взаимодействия с ними - путь в никуда. Нет аргументированной обратной связи - нет проблем.
AlexFF__|
Дата: 20.10.2015 22:16:42
протохипстер с экзадатой,

Решать проблемы с производительностью, иметь для этого доступ к необходимым инструментам и, в конце концов, отвечать за это должен один и тот же человек (круг лиц).
Если доступ имеют специально обученные люди, то пусть они тут спрашивают, что делать )
flexgen
Дата: 20.10.2015 22:59:23
протохипстер с экзадатой
приветствую.

версия:
+

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production


столкнулся с такой проблемой, что время выполнения некоторых однотипных DML операторов значительно выше их средней по больнице



А версия bundle patch какая? С тех.поддержкой общался?
ora601
Дата: 21.10.2015 10:18:58
протохипстер с экзадатой
но может есть шансы разобраться без этого?

Ну есть еще sql_monitor c хинтом /*+MONITOR*/ который покажет все статистики и ожидания,
AWR, планы с рантайм статистиками через хинт gather_plan_statistics/statistics level all или просто планы выполнения.

ЗЫ. забавляет сообщение SQL Statement Write Time: 0.947 seconds, тоесть execution time не считаеться :)
AlexFF__|
Дата: 21.10.2015 10:31:50
ora601
Ну есть еще sql_monitor c хинтом /*+MONITOR*/ который покажет все статистики и ожидания,
AWR, планы с рантайм статистиками через хинт gather_plan_statistics/statistics level all или просто планы выполнения.

Хорошие инструменты.
Можешь еще подсказать, как с помощью всего этого можно получить статистики и ожидания конкретного выполнения нужного запроса?
ora601
Дата: 21.10.2015 10:57:39
AlexFF__|,

Ты что по буквам читаешь ?

Первое предложение для тебя.
jan2ary
Дата: 21.10.2015 11:04:07
AlexFF__|,

v$sql_monitor: SQL_EXEC_ID, SQL_EXEC_START, ...
Пойдет?