Тонкая настройка запроса оракула с конвейерной функцией

Question

У меня есть запрос (который дает отчет Oracle Application Express), о котором мне говорили наши пользователи, выполнял «медленно» или с неприемлемой скоростью (ему не было дано фактическое время загрузки для страница и запрос - единственное, что есть на странице).

Запрос включает в себя множество таблиц и фактически ссылается на конвейерную функцию, которая идентифицирует зарегистрированных пользователей на нашем сайте и возвращает пользовательскую «таблицу» записей, на которые у них есть разрешение, на основе специальной схемы безопасности, которую мы имеем.

Мой главный вопрос касается кэширования запросов Oracle и того, как они могут быть затронуты нашей установкой.

Когда я взял запрос с веб-страницы и запустил его в Sql Developer (и вручную указал идентификатор пользователя, чтобы имитировать зарегистрированного пользователя на веб-сайте), производительность от 71 секунды до 19 секунд до 0,5 секунд. Очевидно, что Oracle использует свой механизм кэширования для ускорения последующих запусков.

Как это влияет ?:

1. Тот факт, что разные пользователи будут получать различные таблицы из функции трубы подкладке (все те же столбцы, только разное количество строк и значений в строки). Подвергается ли облицовке труб кеширование от работы? Я вижу только кэширование, потому что я запускаю очень изолированный тест?
2. Далее - кеширование легко зависит от количества людей, использующих систему? Я не уверен, как «много» может получить кеширование. Поэтому, если у нас есть 50 одновременных пользователей, которые обращаются к различным частям веб-сайта, которые загружают разные запросы в течение всего дня, возможно ли, что оракул не сможет кэшировать многие/любые из них, потому что он постоянно видит другой запрос для запросы?

Извините, мой вопрос не очень технический.

Я разработчик, которого попросили помочь в этом, казалось бы, вопросе DBA.

Кроме того, это сложно, потому что я не могу определить, что такое фактическое время загрузки, поскольку наши пользователи не сообщают об этом уровне детализации.

Любые мысли о:

• как я могу определить, является ли этот запрос на самом деле медленно?
• Какое среднее время обработки будет?
• и как продолжить тонкую настройку, если это проблема?

Спасибо!

Answer 1

Не похоже, что это имеет какое-либо отношение к APEX, конвейерным функциям таблицы или кешированию запросов. Похоже, вы описываете эффекты простого статического кэширования данных (скорее всего, на уровне базы данных, но потенциально на уровнях операционной системы и дисковой подсистемы).

В качестве основного обзора данные хранятся в строках, строки хранятся в блоках (чаще всего 8 кб), блоки хранятся в экстентах (как правило, несколько МБ), а экстенты свертываются до сегментов (т. е. таблицы). Oracle поддерживает буферный кеш, в котором хранятся наиболее недавно обработанные блоки.Когда вы запускаете запрос, Oracle вычисляет, какие блоки нужно читать, чтобы получить ваши данные (это план запроса). Затем он смотрит, находятся ли эти блоки в буферном кеше или их нужно читать с диска. Очевидно, чтение блока из кеша намного эффективнее, чем чтение его с диска, поскольку оперативная память намного быстрее, чем диск. Если вы запускаете один и тот же запрос с одним и тем же набором значений переменной привязки несколько раз подряд, вы будете получать доступ к одному и тому же набору блоков каждый раз, но все больше и больше блоков, которые вам нужны, будут находиться в кеше. Таким образом, вы обычно ожидали, что второй и третий раз, когда вы вызовете запрос, вы увидите более высокую производительность.

Если вы запустили запрос с другим набором значений переменной привязки, то если второй набор значений переменной привязки заставляет Oracle обращаться ко многим из тех же блоков, эти исполнения будут полезны из данных, которые были предварительно сохранены в кэше. В противном случае вы вернетесь к квадрату 1, потенциально прочитав все данные, которые вам нужны с диска. Скорее всего, вы увидите комбинацию из двух.

Помните также, что это не просто Oracle, который кэширует данные. Часто операционная система будет кэшировать наиболее активные части базовых файлов данных Oracle. И подсистема ввода-вывода будет кэшировать и недавно полученные данные. Поэтому, даже если Oracle думает, что ему нужно выйти, чтобы извлечь блок, потому что он не находится в буферном кеше базы данных, файловая система или подсистема ввода-вывода могут кэшировать эти данные, чтобы она не требовала фактического физического считывания диск. Эти другие кэши ведут себя аналогичным образом, когда выполнение одного и того же запроса несколько раз подряд приводит к тому, что кеш будет «теплым» и улучшит производительность последующих прогонов.