Есть запрос следующего вида

SELECT /*+FIRST_ROWS(1) INDEX(T18546854 DB1_DOCUMENT_BY_DEPT)*/ T18546854.ID as P18547059,T18546854.PID as P18547064
FROM DB1_DOCUMENT T18546854
WHERE ((T18546854.CLASS=:P1) AND (T18546854.TYPE=:P2) AND (T18546854.DEPARTMENT=:P3)) ORDER BY T18546854.DOC_DATE DESC

Выполняется пол часа, но Database Time показывает гораздо меньше, чем продолжительность.

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

Как это, что это? Разработчик что-то закрыть забыл?

Вставлю крупнее

AlexFF__|,

Что значит не получены, пользователь то не жалуется, что у него что-то не так, более того он вообще этого не видит.

Оговорюсь, что при вызове v$sql_monitor вижу SQL_CHILD_ADDRESS заполнен, пока не поняла куда он ведет в v$sql.

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

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

Разобралась что это было, это цикл, он делает основной запрос, а потом идет по курсору и дозапрашивает данные дополнительными запросами, чтобы сократить разницу между DatabaseTime и Duration надо трассировкой смотреть, что там внутри цикла.
Ну и в первоначальном запросе выбирать поменьше данных, если это какой-нибудь список документов выбирать его ограниченно а неделю например.

Ну и иногда бывает просто обработка данных в цикле, например сохранение в файл.