Запрос выполняется медленно в первый раз, но быстро во второй / третий раз - PullRequest
Новая
       10

Запрос выполняется медленно в первый раз, но быстро во второй / третий раз

2 голосов
/ 04 марта 2020

Мы видим очень странное условие в запросе Oracle. Приведенный ниже запрос 

SELECT e.C1, MAX (e.Some) 
FROM MyTable e
WHERE e.Code = :Code
GROUP BY E.C1
ORDER BY MAX (e.Some)

Обратите внимание, что таблица содержит около 5 миллионов записей, а код является первичным ключом.

При первой попытке он возвращает значение в течение 60/70 секунды, но после что он возвращает результат через 500 миллисекунд.

Есть ли какой-либо сниффинг параметра в Oracle или мы можем иметь OPTION (RECOMPILE) в Oracle?

Ответы [ 2 ]

1 голос
/ 07 марта 2020

Существует несколько причин, по которым запрос Oracle может ускориться при втором или третьем выполнении:

  1. Буферный кэш - Oracle поместит часто используемые таблицы и индексные блоки в памяти. Самый простой способ проверить это - запустить запрос в SQL* Plus несколько раз после включения set autotrace on. Если значение для «физического чтения» исчезает после первого запуска, то кеширование вызвало разницу. Но кэширование также может происходить на уровне хранилища или операционной системы.
  2. Построение медленного анализа / выполнения - В некоторых редких случаях Oracle может потребоваться длительное время для создания первоначального плана выполнения , Это может быть особенно верно, если используется динамическая выборка c, и Oracle будет считывать часть таблицы, чтобы компенсировать плохую статистику оптимизатора. Одним из способов решения этой проблемы является поиск других системных запросов, которые выполняются одновременно с вашим запросом. Другой распространенной причиной этого является плохая статистика системы или фиксированных объектов, что означает, что Oracle может быть сложно собирать запросы для проверки таких вещей, как привилегии.
  3. Обратная связь по количеству элементов (11g) / Обратная связь по статистике ( 12c +) - Сравнивая ожидаемый кардинал с фактическим кардиналом, оптимизатор может учиться на своих ошибках. У того же SQL_ID есть другой PLAN_HASH_VALUE в GV $ SQL? Если это так, план выполнения со временем меняется.
  4. Кэш результатов - Oracle Сервер и клиент могут сохранять результаты запросов. Этот тип кэширования на самом деле гораздо реже, чем предполагают люди, потому что на практике буферный кеш более полезен - зачем хранить один конкретный c результат в памяти, когда вы можете хранить блоки данных, которые могут обслуживать несколько запросов?
0 голосов
/ 05 марта 2020

Возможно, не используется индекс первичного ключа. Попробуй объясни план проверить. Попробуйте использовать базу правил для принудительного использования индекса: 

select /*+ RULE */ from ...

Также попросите администратора баз данных выполнить анализ таблиц для обновления статистики.

...