Как узнать время выполнения запроса oracle
Обновлено: 04.07.2024
Расследование медленно работающих запросов при использовании СУБД Oracle Database
Иногда расследование проблем производительности приводит к определенному запросу, который выполняется медленно, и не совсем понятно, что делать дальше с таким запросом. В данной статье предлагается способ расследования производительности одного запроса при работе с СУБД Oracle Database.
Работа запроса в любой СУБД состоит из двух частей:
- Выработка плана запроса.
- Исполнение запроса по выработанному плану.
Средства, предоставляемые платформой "1С:Предприятие" не позволяют разделить время выполнения запроса на выработку плана запроса и на время исполнения запроса по выработанному плану. Для того чтобы узнать, какое время тратится на каждую из процедур, необходимо использовать инструменты, предоставляемые СУБД.
Следует отметить, что выработка плана запроса выполняется один раз для совпадающих текстов запросов. Это значит, что текст запроса может быть одним, а значения параметров – разными, при этом запрос будет исполняться по одному и тому же плану. Данный факт может быть полезен для понимания, почему иногда запрос выполняется сначала медленно, а последующие попытки воспроизвести ситуацию приводят к быстрому исполнению запроса.
Для СУБД Oracle Database команда сброса кэша планов запросов выглядит так:
Исполнение данной команды приводит к тому, что все планы запросов будут вырабатываться заново. Выполнение команды на системе с большим количеством работающих пользователей чревато замедлением времени отклика системы (ведь СУБД должна выработать планы запросов для всех запросов), которое со временем возвращается в норму.
Команда сброса кэша полезна для тестовой системы, когда нужно посчитать время выработки плана запроса. После сброса кэша планов запросов, запрос будет исполняться за время равное выработке плана плюс время на исполнение запроса. Когда же план исполнения закеширован в памяти СУБД, время выполнения уходит только на время исполнения запроса, но не на выработку плана исполнения.
Подчеркнем, что если текст SQL-запроса изменяется даже малейшим образом, выработка плана запроса будет сделана заново. В общем случае, затруднительно предсказать при каких изменениях запроса на языке "1С" запрос к СУБД (SQL-запрос) изменится. Поэтому, при изменении запроса на языке "1С" или его параметров не следует предполагать ни то, что SQL-запрос останется идентичным, ни то, что SQL-запрос изменится. В числе прочего, на результирующий SQL-запрос могут влиять параметры сеанса, если их значения используются в запросе, в том числе неявно (в условиях RLS или в общих реквизитах, являющихся разделителями).
Рассмотрим, как использовать средства, предоставляемые СУБД, для анализа работы конкретного запроса. Сначала нам потребуется узнать номер соединения, в котором исполняются запросы. Соединение идентифицируется двумя числами: SID и SERIAL . Получить все соединения, инициированные с процесса rphost.exe , можно следующим запросом:
В работающей информационной базе может быть много соединений, поэтому сначала нужно найти то соединение, в котором будет исполняться интересующий нас запрос или же включить трассировку для всех соединений. Найти одно конкретное соединение, в котором исполняется запрос, при работающих пользователях довольно затруднительно, но если есть база данных, где пользователи не работают и на этой базе можно воспроизвести работу проблемного запроса, то найти соединение обычно труда не составляет. Cервер "1С:Предприятия" открывает два соединения с СУБД Oracle Database, одно из которых используется для выполнения запросов одного пользователя; найти его можно, исполнив любой запрос, а затем обратить внимание на столбец sql_text в представлении v$sql , после чего сопоставить колонки sql_id в представлениях v$sql и v$session . Другими словами, использовать соединение двух представлений.
Если допустимо использование толстого клиента, то можно создать временную таблицу, а менеджер временных таблиц присвоить глобальной переменной - тогда это соединение будет считаться захваченным, и все запросы будут происходить из него. Необходимо отметить два момента:
1) никогда не используйте данный подход в продакшен-системе, поскольку в этом случае производительность ухудшается, а сервер платформы и сервер СУБД начинают тратить больше ресурсов, чем необходимо;
2) соединение, создающее временную таблицу - это не то же соединение, в котором будет использоваться временная таблица (специфика работы платформы с СУБД Oracle Database).
Номер соединения с СУБД также пишется в технологическом журнале, в свойстве dbpid . Но для СУБД Oracle Database нам еще нужно знать серийный номер подключения, а не только номер соединения, поэтому использовать технологический журнал платформы можно как помощь, но не как основной источник информации.
Для включения трассировки запроса по времени выполнения каждого шага можно использовать трассировку 10046. Для включения трассировки по выработке плана запроса можно использовать трассировку 10053. Для включения трассировки нам необходимо знать, какое соединение будет исполнять запрос.
Чтобы включить трассировку для известного соединения с базой данных следует подключиться к базе данных с ролью SYSDBA (это может делать пользователь SYS, например так: sqlplus sys as sysdba ) и выполнить команду ( sid и serial следует заменить идентификаторами соединения):
В утилитах, отличных от sqlplus , команда exec может не поддерживаться. В случае, если утилита не поддерживает установку роли при соединении с БД попробуйте в качестве имени пользователя указать sys as sysdba . Если команда exec не поддерживается - можно использовать такой код:
Для выключения трассировки - 12 следует заменить на 0. Число 12 - обозначает максимальный уровень детализации трассировки 10046. Для трассировки 10053 (трассировка выработки плана исполнения запроса) разницы между разными уровнями трассировки - нет, поэтому проще использовать то же число 12 - для включения, и 0 - для выключения.
Файлы трассировки открываются СУБД и остаются незакрытыми до тех пор, пока соединение, запросившее трассировку, не отключит ее исполнение. Впрочем, иногда этого недостаточно и в зависимости от версии используемой СУБД может понадобиться закрыть соединение с базой данных. Сейчас это происходит при отключении последнего пользователя, использующего информационную базу; не исключено, что платформа "1С:Предприятие" перестанет следовать этому принципу и тогда единственным гарантированным способом отключения сервера платформы от сервера СУБД будет перезапуск рабочего процесса сервера платформы.
Расположение файлов трассировки можно узнать, выполнив следующий запрос
Из имени файла трассировки сложно понять, когда он был записан. Для определения какой из файлов содержит интересующую информацию можно использовать косвенные признаки, такие как объем файла и время его последней модификации.
Полученную трассировку 10046 в сыром виде читать затруднительно. Обработка трассировки делается с помощью следующей команды (в отличие от всех остальных запросов в этой статье, эта команда выполняется не в сессии работы с СУБД, а в консоли операционной системы).
Опциональный параметр sort=exeela означает, что запросы будут отсортированы в порядке убывания времени исполнения.
Трассировку 10053 читать непросто, но возможно. Это дает понимание о том, как оптимизатор принял решение о способах соединения всех таблиц и подзапросов в общем запросе. В частных случаях удается использовать полученную информацию для сбора более детальной статистики по тем таблицам, где оптимизатор СУБД промахивается с оценкой кардинальности.
Иногда запись трассировочных файлов – существенно замедляет время выполнения запроса, поэтому судить о скорости выполнения запроса, когда записывается трассировка, неправильно. Трассировки нужны для анализа и понимания что и почему происходит в «голове» у СУБД, и в них содержится достаточно информации на эту тему.
В случае, если удастся определить, что СУБД тратит основное время на выработку плана запроса, а не на его исполнение, может оказаться полезным дать указание оптимизатору СУБД снизить количество вариантов перебора для выработки оптимального плана запроса.
По умолчанию, значение параметра " _optimizer_max_permutations " равно 2000. Изменить значение параметра можно следующей командой.
Уменьшение количества вариантов, перебираемых оптимизатором (значение параметра " _optimizer_max_permutations ") может привести к ухудшению производительности в том случае, когда оптимизатор не смог найти более оптимальный план запроса за 200 попыток (но смог бы за 2000). Тем не менее, накопленный опыт использования систем на базе платформы "1С:Предприятие" больше склоняет к предлагаемому уменьшению параметра до значения 200.
После изменения значения данного параметра имеет смысл сбросить кэш планов исполнения, чтобы следующий запрос был исполнен с выработкой плана. Команда сброса (уже упоминалась ранее в статье).
Важно отметить, что параметры оптимизатора, начинающиеся с подчеркивания, не документированы вендором и их изменение может приводить к непредвиденным проблемам. Поэтому изменение параметров рекомендуется только в том случае, когда есть полное и ясное понимание, на что влияют эти параметры и как и в каком случае следует их модифицировать.
Инструкция SET STATISTICS TIME ON позволяет нам легко получить информацию о времени выполнения запроса. В этой статье посмотрим подробнее, какую именно, и что она означает.
Введение
В современном мире пользователи ожидают от приложений максимальной производительности, поэтому наши запросы должны быть очень быстрыми. А в оптимизации запросов помогает измерение их основных параметров производительности и, в этом контексте, SET STATISTICS TIME ON предоставляет нам простой, но очень полезный отчет о времени выполнения запроса.
Измерение времени выполнения запроса
Давайте включим отображение этой статистики и выполним запрос, приведенный ниже. (Примечание переводчика: используется база данных AdventureWorks.)
Для более удобного представления результатов вы можете использовать Statistics Parser.
Parse and compile time (время синтаксического анализа и компиляции)
Выполнение запроса в SQL Server начинается с синтаксического анализа (проверка синтаксиса), с последующей компиляцией (генерация оптимального плана выполнения запроса). Время, затраченное на эти два этапа, отображается в разделе "SQL Server parse and compile time" (Время синтаксического анализа и компиляции SQL Server).
CPU time (время ЦП) — время процессора на синтаксический анализ и компиляцию.
Elapsed time (истекшее время) — общее время, затраченное на синтаксический анализ и компиляцию запроса. Включает в себя время процессора. Это значение также можно увидеть в плане запроса в атрибуте CompileTime оператора SELECT.
Но если мы выполним этот же запрос повторно, то, скорее всего, увидим нули. Это говорит о том, что SQL Server не тратит время на компиляцию и синтаксический анализ, так как план выполнения уже есть в кэше планов и используется повторно.
Однако в плане выполнения в атрибуте CompileTime все еще 32 мс — это время последней компиляции плана.
Execution Times (время работы)
В разделе SQL Server Execution Times (Время работы SQL Server) указано время, затраченное SQL server на выполнение скомпилированного плана запроса.
CPU time (Время ЦП) — время, затраченное процессором (процессорами). Elapsed time (затраченное время) — общее время выполнения запроса. Это время включает в себя все операции ввода-вывода, время ожидания и время, необходимое для отправки результата клиенту. Давайте проверим это. Включим фактический план выполнения и выполним следующий запрос.
Время синтаксического анализа и компиляции (SQL Server parse and compile time) равно нулю, так как запрос был найден в кэше. Общее время выполнения запроса (elapsed time) 3 823 мс, из них 562 мс — время процессора. Какие были ожидания можно увидеть в плане выполнения в свойстве WaitStats оператора SELECT. Для нашего примера это ASYNC_NETWORK_IO.
Для того чтобы убрать время пересылки результатов клиенту, в нашем случае, в SQL Server Management Studio (SSMS), отключим отображение результатов запроса, включив параметр "Discard results after the execution" (Отбросить результаты после выполнения).
Откроем новую вкладку в SSMS и выполним тот же запрос.
Видно, что время ожидания было добавлено к затраченному времени (elapsed time).
Иногда можно встретить ситуацию, когда CPU time (Время ЦП) больше, чем elapsed time (затраченное время). Например, в следующем запросе.
В плане выполнения у оператора SELECT мы видим атрибут Degree of Parallelism , который указывает, сколько процессоров использовалось для обработки запроса. Видим, что использовалось несколько процессоров, поэтому суммарное CPU time больше elapsed time (затраченного). Еще один атрибут, связанный с параллельной обработкой запросов, — ThreadStat . ThreadStat показывает, сколько потоков было зарезервировано и использовано.
Резюме
В этой статье мы узнали, как использовать SET STATISTICS TIME ON и как интерпретировать его результаты.
Шесть тысяч слов помогут вам понять статистику Oracle и план выполнения
Источник | JiekeXu Road (ID: JiekeXu_IT)
Свяжитесь с авторизацией для перепечатки | (WeChat ID: xxq1426321293)
Всем привет, я JiekuXu, я очень рад снова встретиться с вами, поделитесь этим сегодня Статистика Oracle и план выполнения. Эта статья была впервые опубликована в общедоступном аккаунте WeChat [JiekeXu Road], пожалуйста, нажмите на синюю букву выше, чтобы подписаться на меня!
Предисловие
Несколько дней назад я получил приглашение от г-на Ян Цзяньжун, автора «Рабочих заметок Oracle DBA» и «MySQL DBA Work Notes» и соучредителя сообщества DBAplus на WeChat, и сказал, что поделится технической, на рабочем месте и идеи в его группе QQ От таких статей я сразу почувствовал искренность и ужас.Мне было честью, что обмен опытом - это тоже процесс обучения, поэтому я с радостью согласился на приглашение Учителя Яна. Думая, что вы также изучаете в последнее время вещи, связанные с оптимизацией, вы можете обобщить и поделиться во время обучения.Если в статье есть другие недостатки, сообщите об этом.
1. Статистика
Статистическая информация в основном описывает тип информации, такой как размер, масштаб и статус распределения данных таблиц и индексов в базе данных. Например, количество строк в таблице, количество блоков, средний размер каждой строки, листовые блоки индекса, количество строк в индексном поле и размер различных значений являются статистическими. Информация. Начиная с Oracle11G, автоматический сбор статистики базы данных был интегрирован в задачи автоматического обслуживания, которые в основном выполняются автоматически по умолчанию, что также в большинстве случаев соответствует требованиям эксплуатации, но также может быть собрано вручную.Поговорим об этом вместе.
Использоватьgather_stats_job Автоматический сбор данных создается автоматически, когда база данных создается и управляется планировщиком. Он собирает статистику для всех объектов в базе данных, для которых отсутствует или устаревшая статистика оптимизатора.
Использоватьdbms_stats Пакет вручную собирает системную статистику.
Просмотр статуса задач автоматического сбора статистики
Имя задачи автоматического сбора статистической информации в oracle 11g - автоматический сбор статистики оптимизатора. Окно времени выполнения по умолчанию для автоматических задач в 11g (введение в временное окно Oracle):
С понедельника по пятницу начинается в 22:00 и заканчивается в 14:00.
Выходные - шесть часов утра и продолжаются 20 часов.
В этот период нагрузка на сервер, как правило, относительно невелика. Ресурсы сервера можно оставить для сбора статистической информации, а сбор статистической информации более ресурсоемкий. Это можно увидеть в следующем утверждении:
Как и выше, задача сбора статистической информации выполняется каждый день, но если нагрузка на сервер базы данных велика, а нагрузка высока ночью, эта задача может не выполняться. Вам нужно скорректировать эту задачу и время. Его можно отключить или изменить, но, как правило, он не отключен. Вам необходимо изменить временное окно на определенное время
- Остановить и запустить отдельную задачу (то есть остановить задачу в определенный день)
Связанные просмотры:
Вот и все, что касается автоматического сбора. Для получения дополнительной информации проверьте официальные документы или Doc ID 1300313.1
How to Create an Own Maintenance Window for Autotask Jobs in 11g (Doc ID1300313.1) . Позволь мне поговорить об этом dbms_stats Связанный с пакетом.
dbms_stats
Пакет DBMS_STATS в основном предоставляет методы для сбора (сбора), удаления (удаления), экспорта (экспорта), импорта (импорта) и изменения (установки) статистической информации. Говоря оdbms_stats Тогда нужно поговорить о команде анализа.
Разница между dbms_stats и анализировать: Dbms_stats - это пакет, используемый для сбора статистики в Oracle9i и более поздних версиях.Хотя команда анализа была всегда доступна, больше не рекомендуется использовать команду анализа для сбора статистики. Вместо этого используйте dbms_stats. Между ними существует большая разница. Dbms_stats может правильно собирать статистику таблицы разделов, что означает, что он может собирать глобальную статистику, в то время как анализ может собирать статистику только объектов нижнего уровня, а затем выводить и суммировать более высокие -уровневые объекты.Статистика: если таблица разделов собирает только статистику разделов, то суммирует статистику всех разделов, чтобы получить статистику на уровне таблицы. По сути, Analyze устарел. Он использовался более семи или восьми лет назад. Oracle и эксперты рекомендуют пакет dbms_stats.
Пакет dbms_stats может собирать статистику о базах данных, словарях данных, индексах, таблицах и т. Д.
dbms_stats.gather_table_ststs параметр
1、 cascade:
true: указывает, что статистика собирается вместе с индексом при подсчете
2、 no_invalidate:
true: после сбора статистики исходный план выполнения не становится недействительным.
false: после сбора статистики исходный план выполнения становится недействительным.
По умолчанию DBMS_STATS.AUTO_INVALIDATE, Oracle решает, когда сделать недействительным план выполнения.
3、 method_opt:
FOR ALL [INDEXED | HIDDEN] COLUMNS[size_clause]
FOR COLUMNS [size clause] column[size_clause] [,column [size_clause]. ]
Когда данные поля распределены неравномерно, создайте гистограмму (гистограмму):
Статистика гистограммы: значения столбца индексного поля для создания статистики
Многоколоночная статистика: статистика создания столбца составного индекса
Статистика выражений: создание статистики по клавишам индекса функций
Примечание. Случай двух приведенных выше строк отличается, при использовании exec его нужно записать в одну строку. Анонимные блоки могут быть записаны в несколько строк. Кроме того, значение Size равно 1-254, но после 12c значение становится 1-2048.
Просмотр статистики:
Примечание. Обычные пользователи могут проверить user_tab_col_statistics, а пользователи DBA могут проверить dba_tab_col_statistics. Конечно, вы также можете использовать dba_tab_statistics для просмотра времени последнего сбора статистической информации.
Вот и все статистические данные, давайте перейдем к сегодняшней теме: План реализации 。
2. План реализации
План выполнения: описание пути доступа или процесса выполнения оператора SQL в базе данных.Oracle через оптимизатор Optimizer (Оптимизатор здесь относится к оптимизатору на основе затрат [Cost Based Optimizer, CBO]) для поиска оптимального плана выполнения для выполнения. Затем мы сначала понимаем, как выполняется следующий SQL: обычно он проходит через три этапа: синтаксический анализ (Parse), выполнение (Execute) и получение (Fetch), которые выполняются различными компонентами Oracle. Подробная информация должна быть быть объясненным из архитектуры Oracle. Я не буду говорить об этом здесь.
rowsource Источник строки: в запросе подходящим набором данных, возвращенным предыдущей операцией, может быть вся таблица или ее часть.Конечно, также можно выполнить операцию соединения для двух таблиц. Что касается жесткого анализа, можно просмотреть мягкий анализПредыдущая статья。
В-третьих, просмотрите план выполнения
Часть SQL выполняется в базе данных и возвращает результат. Что происходит в середине и какие пути были доступны. Это требует проверки плана выполнения. Оптимизатор выберет наиболее разумный и наиболее эффективный метод выполнения, который, по его мнению, является наиболее разумный и эффективный метод выполнения для выполнения возврата SQL.Набор результатов предоставляется клиенту, поэтому давайте взглянем на общие методы проверки плана выполнения, включая, помимо прочего, следующие семь методов.
Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи — помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) — платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.
Performance Home
На вкладке Performance Home можно увидеть основные графики утилизации БД.
Average Runnable Process
Этот график дает общее понимание использования CPU.
| № | Показатель | Описание |
|---|---|---|
| 1 | Instance Foreground CPU | Отображает утилизацию CPU процессами текущего инстанса, напрямую запущенными клиентом, например выполнение запросов. Список событий ожидания текущего инстанса можно посмотреть в AWR-отчете |
| 2 | Instance Background CPU | Отображает утилизацию CPU фоновыми процессами текущего инстанса, например LGWR. Список событий фонового процесса текущего инстанса можно посмотреть в AWR-отчете или в официальной документации Oracle |
| 3 | Non-database Host CPU | Отображает утилизацию CPU процессами, не относящимися к текущему инстансу |
| 4 | Load Average | Отображает среднюю длину очереди процессов, ожидающих выполнения |
| 5 | CPU Treads/CPU Cores | Отображает лимит максимально возможного использования CPU |
Average Active Sessions
- Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
- Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
- Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH — Active Session History).
Throughput
Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.
Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет — необходимо изменить настройки БД.
Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график — основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.
Статистику по I/O можно смотреть в разрезе функций, в разрезе типов и в разрезе групп потребителей ресурсов (группы пользователей). Для этого на графике необходимо выбрать соответствующий Breakdown. Графики показывают количество I/O-операций в секунду и их вес в разрезе выбранного значения Breakdown. Для большей детализации можно провалиться глубже в статистику, выбрав соответствующее значение на графике или в легенде, и посмотреть статистику именно по выбранному значению.
I/O Function
График дает представление об уровне утилизации диска приложениями или джобами. То есть на графике можно увидеть, какие процессы больше всего читали и писали за определенный период.
Можно выделить следующие категории:
| № | Категория | Описание |
|---|---|---|
| 1 | Фоновые процессы | Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации) |
| 2 | Активность | XML DB, Streams AQ, Data Pump, Recovery, RMAN |
| 3 | Тип I/O | Включает прямую запись и чтение (в том числе чтение из кэша) |
| 4 | Другое | Включает операции ввода/вывода управляющих файлов |
I/O Type
Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.
Consumer group
Дает представление об утилизации диска в разрезе групп пользователей: показывает, какая группа пользователей выполняет операции чтения и записи в определенный период. Включает в себя фоновые процессы.
Parallel Executions
Раздел дает представление о показателях, связанных с параллельным выполнением запросов. Параллельный запрос делится на несколько процессов для ускорения выполнения запроса. Параллельное выполнение полезно при выполнении тяжелых запросов. Подробнее можно прочесть в официальной документации Oracle.
Services
Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS — это установка пользовательского сеанса.
ASH Report
ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.
- События ожидания и группы событий ожидания.
- Группы пользователей, пользователи, сервисы, инстансы.
- SQL-запросы.
AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.
Load Profile
Здесь отображается общая информация по тому, как была загружена БД за выбранный период.
| № | Параметр | Описание |
|---|---|---|
| 1 | DB Time(s) | Сумма времени утилизации процессора и время ожидания (без простоя) |
| 2 | DB CPU(s) | Нагрузка на процессор |
| 3 | Background CPU(s) | Загрузка процессора фоновыми задачами |
| 4 | Redo size | Объем чтения |
| 5 | Logical reads | Среднее количество логических чтений блоков |
| 6 | Block changes | Среднее значение измененных блоков |
| 7 | Physical reads | Физическое чтение в блоках |
| 8 | Physical writes | Количество записей в блоках |
| 9 | Read I/O requests | Количество чтений |
| 10 | Write I/O requests | Количество записей |
| 11 | Read I/O (MB) | Объем чтения |
| 12 | Write I/O (MB) | Объем записей |
| 13 | IM scan rows | Количество строк в In-Memory Compression Units (IMCU), которые были доступны |
| 14 | Session Logical Read IM | Чтения в In-Memory |
| 15 | User calls | Пользовательские вызовы |
| 16 | Parses | Разборы |
| 17 | Logons | Количество входов |
| 18 | Excecutes | Количество вызовов |
| 19 | Rollback | Количество откатов данных |
| 20 | Transacions | Количество транзакций |
Instance Efficiency Percentages
| № | Показатель | Критерии |
|---|---|---|
| 1 | Buffer nowait | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
| 2 | Buffer Hit | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
| 3 | Library cache hit | Если показатель меньше 95% — нужно расширять shared pool (либо причина в bind-переменных) |
| 4 | Redo NOWAIT | Если показатель меньше 95%, это говорит о проблеме в redo log buffer или redo log |
| 5 | Parse CPU to Parse Elapsd | Показатель должен быть больше или равен 90%, тогда большинство процессов не ожидает ресурсов, что говорит о правильной работе базы данных |
| 6 | Non-Parse CPU | Показатель должен приближаться к 100%, это значит, что большинство ресурсов CP используется в различных операциях, кроме parsing, что говорит о правильной работе базы данных. Если Non-Parse CPU низкий, значит, база много времени тратит на разбор запроса вместо реальной работы |
| 7 | In-memory sort | Значение меньше 100 говорит о том, что сортировка идет через диск, а также есть потенциальные проблемы с PGA_AGGREGATE_TARGET,SORT_AREA_SIZE,HASH_AREA_SIZE и bitmap setting |
| 8 | Soft Parse | Чем он выше, тем меньше у нас Hard Parse |
| 9 | Latch Hit | Чем он выше, тем меньше мы ждем Latches (если он низкий — у нас проблемы с CPU-Bound и Latches) |
Top 10 Foreground Events by Total Wait Time
В разделе находится топ-10 событий, которые ожидали ресурсов дольше остальных.
При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.
Описание некоторых событий ожидания:
| № | Событие ожидания | Описание |
|---|---|---|
| 1 | DB CPU | Отображает процессорное время, затраченное на пользовательские операции над БД. Это событие должно находиться на первом месте списка |
| 2 | db file sequential read | Метрика сигнализирует, что пользовательский процесс не находит нужный блок в buffer cache, загружает его с диска в SGA и ждет физического ввода/вывода |
| 3 | db file scattered read | Указывает на проблему с фулл-сканами, возможно, нужны индексы |
| 4 | read by other session | Может говорить о том, что размер блока слишком большой или задержка (latency) слишком большая |
| 5 | enq TX – row lock contention | Событие возникает при ожидании блокировки строки для дальнейшей ее модификации DML-запросом. Если показатель больше 10%, необходимо разбираться в причинах. Более детальную информацию можно посмотреть в разделе Segments by Row Lock Waits, в котором есть сведения о том, какие таблицы были заблокированы и какими запросами |
| 6 | DB FILE SEQUENTIAL READ | Если среднее значение параметра больше 100 мс, это может свидетельствовать о том, что диск работает медленно |
| 7 | LOG FILE SYNC | Значение AVG WAIT более 20 мс может свидетельствовать о проблемах |
| 8 | DB FILE SCATTERED READ | Если это событие выполняется — возможно, имеет смысл создать дополнительные индексы. Для более подробной информации нужно перейти к разделу Segments By Physical Read, в котором находится информация по таблицам и индексам, в которых происходит физическое чтение |
| 9 | direct path read temp ИЛИ direct path write temp | Эти события дают информацию по использованию временных файлов |
| 10 | Buffer Busy Wait | Событие указывает на то, что несколько процессов пытаются обратиться к одному блоку памяти, то есть пока первый процесс работает с конкретным блоком памяти, остальные процессы находятся в статусе ожидания |
Host CPU и Instance CPU
Здесь стоит обратить внимание на %Idle и %Total CPU. Если показатель %Idle низкий, а %Total CPU высокий, это может свидетельствовать о том, что процессор является узким местом.
Foreground Wait Class, Foreground Wait events и Background Wait Events
Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.
SQL statistics
Раздел содержит несколько таблиц со статистикой по SQL-запросам, отсортированным по определенному критерию.
Подробнее про оптимизацию запросов и примеры типичных проблем в запросах можно почитать в статье Проактивная оптимизация производительности БД Oracle.
| № | Параметр | Описание |
|---|---|---|
| 1 | SQL ordered by Elapsed Time | Топ SQL-запросов по затраченному времени на их выполнение |
| 2 | SQL ordered by CPU Time | Топ SQL-запросов по процессорному времени |
| 3 | SQL ordered by User I/O Wait Time | Топ SQL-запросов по времени ожидания ввода/вывода для пользователя |
| 4 | SQL ordered by Gets | Запросы к БД, упорядоченные по убыванию логических операций ввода/вывода. При анализе стоит учитывать, что для PL/SQL-процедур их количество прочитанных Buffer Gets будет состоять из суммы всех запросов в рамках этой процедуры |
| 5 | SQL ordered by Reads | Этот раздел схож с предыдущим: в нем указываются все операции ввода/вывода, наиболее активно физически считывающие данные с жесткого диска. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода |
| 6 | SQL ordered by Physical Reads (UnOptimized) | В этом разделе выводятся неоптимизированные запросы. В Oracle неоптимизированными считаются все запросы, которые не обслуживаются DSFC или Exadata Cell Smart Flash Cache (ECSFC) |
| 7 | SQL ordered by Executions | Наиболее часто выполняемые запросы |
| 8 | SQL ordered by Parse Calls | Отображает количество попыток разбора SQL-запросов до его выполнения |
| 9 | SQL ordered by Sharable Memory | Запросы, занимающие больший объем памяти общего пула SGA |
| 10 | SQL ordered by Version Count | Здесь показано количество SQL-операторов экземпляров одного и того же оператора в разделяемом пуле |
| 11 | Complete List of SQL Text | Показывает полный SQL-запрос, не только его хэш. В этой таблице можно найти неоптимальные запросы (например, запросы по всем столбцам таблицы «select * from. », запросы с большим количеством «like» и т. п.) |
Active Session History (ASH) Report
В данной таблице находятся самые тяжелые SQL запросы, на которые приходится наибольший процент активности и наибольшее время ожидания.
В таблице содержится статистика по запросам, на которые приходится наибольший процент выборочной активности и подробная информация о их плане выполнения. Вы можете использовать эту информацию, чтобы определить, какая часть выполнения SQL операторов значительно повлияла на затраченное время SQL оператора.
Читайте также: