Причины активного использования дисков при выполнении запроса через rest-api
Такая проблема: есть большое представление, есть запрос из этого представления. Но при запуске в IDE:
SELECT * FROM my_view;
Запрос получает последнюю строку через минуты полторы. Когда через rest-api прошу сервер выполнить похожий запрос:
SELECT * FROM (SELECT * FROM my_view) FETCH FIRST 1000 ROWS ONLY;
Обложку с ограничением накладывает сам сервер. Так вот второй запрос выполняется часов 10. Оба запроса выполнены под одним и тем же юзером. Залез в v$sql посмотреть что-нибудь, что бросится в глаза для этих двух уже выполненных запросов. Так вот, PHYSICAL_WRITE_BYTES (и _REQUESTS) как и PHYSICAL_READ_BYTES (и _REQUESTS) отличается раз в 40-50 (соответственно, у второго больше). Да и во время выполнения часто видел причину ожидания User I/O у второго запроса.
Вопрос: в чем может быть причина? Почему второй запрос активно полез на диски? Может ли быть такое, что второму не хватило кеша, при том, что он зашел под тем же юзером и как это можно проверить?
Ответы (1 шт):
Нужно смотреть планы запроса, возможно через rest api не используется индекс.
Посмотрите ваши реальные планы выполнения через DBMS_XPLAN, например:
SELECT * FROM table (DBMS_XPLAN.DISPLAY_CURSOR('atfwcg8anrykp'));
sql_id найдите в представлении v$sql, например:
select * from v$sql where sql_text like 'SELECT * FROM (SELECT * FROM my_view)%';
Сравните планы выполнения. В медленном плане наверняка либо не используется индекс, либо есть сортировка.
Например, есть баг, в 12.1: При использовании fetch first ... rows only выполняется лишняя сортировка.