Как прочитать отчет оракула Awr

Обновлено: 21.11.2024

Поскольку вы создали отчет AWR в Oracle, следующая задача — проанализировать отчет AWR в Oracle. Читая отчет AWR, вы можете легко решить такие проблемы, как медленная база данных, события с высоким ожиданием, медленный запрос и многие другие. Хотя это длинный отчет, анализ или чтение соответствующей части отчета AWR может помочь устранить проблемы простым и быстрым способом.

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

<р>1. Проблема с машиной базы данных. OS Watcher — лучший инструмент для начала.

<р>2. Если есть проблемы с производительностью базы данных, обратите внимание на отчет AWR.

В случае, если конкретный запрос работает плохо, я бы посоветовал посмотреть план выполнения запроса, статистику базовой таблицы и т. д. В этом случае AWR мало чем поможет.

Рекомендации перед получением отчета AWR.

<р>1. Соберите несколько отчетов AWR: всегда хорошо иметь два отчета AWR, один для хорошего времени (когда база данных работала хорошо), второй, когда производительность низкая. Таким образом, удаленный администратор базы данных может легко сравнить хорошие и плохие отчеты, чтобы найти виновника.

<р>2. Придерживайтесь определенного времени: «База данных работает медленно» больше не поможет решить проблемы с производительностью. У нас должно быть определенное время, например, база данных была медленной вчера в 13:00 и продолжалась до 16:00. Здесь администратор базы данных получит отчет за эти три часа.

<р>3. Разделите большой отчет AWR на более мелкие отчеты: вместо того, чтобы иметь один отчет в течение длительного времени, как один отчет в течение 4 часов. лучше четыре доклада каждый по часу. Это поможет изолировать проблему.

В случае окружения RAC. генерировать один отчет для каждого экземпляра. Однажды вы создали отчет AWR. Теперь пришло время проанализировать отчет. Поскольку отчет AWR — это огромный отчет, и область изучения AWR также зависит от проблемы. Здесь я перечисляю наиболее распространенные области, которые администратор базы данных может изучить, чтобы получить четкое представление о проблеме.

Шаги по анализу отчета AWR

1. Заголовок отчета

Детали базы данных:

После получения отчета AWR Это первая и верхняя часть отчета. В этой части перекрестно проверьте базу данных, экземпляр и версию базы данных с базой данных, имеющей проблемы с производительностью. В этом отчете также отображается RAC=YES, если это база данных RAC.

Конфигурация хоста:

Это даст вам имя, CUP платформы, сокет и ОЗУ и т. д. Важно отметить, что количество ядер в системе. В этом примере в ядрах 12 CUP.

Детали моментального снимка:

Это подробные сведения о сделанном снимке, времени начала и окончания снимка. Разница между ними в том, что «Прошло». Вот новый термин "Время БД"

Время БД= время сеанса, проведенное в базе данных.
Время БД = время процессора + время ожидания без простоя.
Вы можете обнаружить, что время БД очень велико по сравнению со временем прохождения, что не является проблемой. Проверьте, получили ли вы отчет за то время, когда у вас возникли проблемы с производительностью. Если да, хорошо, в противном случае сделайте отчет о проблеме с производительностью.

Далее идет размер кэша, в котором подробно рассказывается о компонентах SGA.

2. Загрузить профиль:

Вот несколько важных статистических данных, на которые должен обратить внимание администратор баз данных. Fist — это «ЦП БД» в секунду. Перед этим давайте разберемся, как работает DB CUP. Предположим, у вас есть 12 ядер в системе. Таким образом, на каждую секунду настенных часов у вас есть 12 секунд для работы на процессоре.

В этом случае машина имеет 12 ядер, а ЦП БД в секунду составляет 6,8. Таким образом, это не случай, связанный с процессором.

Следующая статистика, на которую стоит обратить внимание, – Parses и Hard parses. Если отношение жесткого синтаксического анализа к синтаксическому анализу велико, это означает, что база данных выполняет более жесткий синтаксический анализ. Итак, нужно посмотреть на такие параметры, как cursor_sharing и уровень приложения для переменных связывания и т. д.

Время БД:
Количество времени, которое Oracle потратил на выполнение запросов пользователей к базе данных. Обратите внимание, что это не включает фоновые процессы.
ЦП БД:
Количество времени ЦП, затраченного на вызовы пользователей. Как и время БД, оно не включает фоновый процесс.Значение указано в микросекундах.
Размер повторов:
Например, в приведенной ниже таблице показано, что в среднем транзакция генерирует около 19 000 данных повторов, а также около 48 000 повторений в секунду.
Логические чтения:
Непротиворечивые операции чтения + блоки БД Получения = логические операции чтения
Изменения блоков:
Количество блоков, измененных в течение интервала выборки
Физические операции чтения:
Количество запросов блока, вызывающих операцию ввода-вывода.
Физическая запись:
Количество выполненных физических операций записи.
Вызовы пользователей:
Количество сгенерированных пользовательских запросов. >Сумма всех разборов; и твердые и мягкие.
Жесткий анализ:
анализ, требующий полностью нового анализа оператора SQL. Они потребляют как защелки, так и общую область пула.
Мягкие синтаксические анализы:
Мягкие синтаксические анализы не перечислены, но получены путем вычитания жестких синтаксических анализов из синтаксических анализов. Мягкий синтаксический анализ повторно использует предыдущий жесткий синтаксический анализ; следовательно, он потребляет гораздо меньше ресурсов.
Сортировки:
Количество выполненных сортировок
Входы в систему:
Количество входов в систему в течение интервала
Выполнения:
Количество выполнений SQL
Транзакции:
Количество транзакций в секунду

Профиль нагрузки предоставляет краткий обзор некоторых конкретных операционных статистических данных. Вы можете сравнить эту статистику с базовым отчетом о моментальном снимке, чтобы определить, отличается ли активность базы данных. Значения для этих статистических данных представлены в двух форматах. Первый — это значение в секунду (например, сколько повторов было сгенерировано за секунду), а второй — это значение на транзакцию (например, на одну транзакцию было сгенерировано 1024 байта повторов).
Статистика, представленная в профиле нагрузки, включает в себя такие вещи, как:
Размер повторного выполнения — указание на количество операций DML, которые испытывает база данных.

Логические и физические операции чтения – количество операций ввода-вывода (физических и логических), которые выполняет база данных.

Вызовы пользователей. Указывает, сколько вызовов пользователей произошло за период создания снимка. Это значение может указывать на увеличение использования.

Синтаксический анализ и полный синтаксический анализ — показывает эффективность повторного использования SQL.

Сортировки. Это число показывает, насколько часто выполняется сортировка в базе данных.

Входы в систему — показывает, сколько входов в систему произошло за период создания снимка.

Выполняется. Указывает, сколько операторов SQL было выполнено в течение периода создания моментального снимка.

Транзакции. Указывает, сколько транзакций произошло за период создания снимка.
Кроме того, в разделе профиля нагрузки указан процент блоков, которые были изменены при чтении, процент выполненных рекурсивных вызовов, процент отката транзакций и количество строк, отсортированных за одну операцию сортировки.

3. Процент эффективности экземпляра:

В этой статистике вы должны смотреть на «% ЦП без анализа». Если это значение близко к 100 %, это означает, что большая часть ресурсов ЦП используется для операций, отличных от синтаксического анализа, что хорошо для работоспособности базы данных.

Выполнить для синтаксического анализа % и синтаксического анализа ЦП для синтаксического анализа Elapsd %:

Если значение низкое, как в приведенном выше случае 3,40 и 0,01, это может означать, что может возникнуть проблема синтаксического анализа. Возможно, вам придется обратить внимание на проблемы с переменными привязки или размер общего пула.

Повторить NoWait%:

Обычно эта статистика составляет 99 или выше

% сортировки в памяти:

Это может сказать вам, насколько эффективны вы sort_area_size, hash_area_size или pga_aggrigate_target. Если у вас нет адекватных размеров параметров sort, hash и pga, процент сортировки в памяти уменьшится

Мягкий синтаксический анализ %:

где 98,20 % для мягкого синтаксического анализа означает, что около 1,72 % (100 -мягкий синтаксический анализ) приходится на жесткий синтаксический анализ. Возможно, вы захотите взглянуть на свои проблемы с привязкой переменных.

% совпадений с фиксацией:
должен быть близок к 100.

% ЦП без синтаксического анализа:

Большинство наших операторов уже были проанализированы, поэтому мы не проводили много повторного анализа. Повторный синтаксический анализ сильно загружает ЦП, и его следует избегать.

4. Топ-5 событий переднего плана по времени:

Это еще одна наиболее важная статистика, которую следует учитывать при просмотре отчета AWR по любой проблеме, связанной с производительностью базы данных. Здесь есть список из 5 основных событий ожидания переднего плана.

Здесь, прежде всего, проверьте класс ожидания, если классом ожидания является пользовательский ввод-вывод, системный ввод-вывод, другие и т. д., это может быть нормально, но если класс ожидания имеет значение «Параллелизм», тогда могут возникнуть серьезные проблемы. Далее нужно посмотреть время (с), которое показывает, сколько раз БД ждала в этом классе, а затем среднее ожидание (мс). Если время (с) высокое, но среднее время ожидания (мс) низкое, вы можете игнорировать это.Если оба параметра высоки или среднее время ожидания (мс) велико, необходимо провести дальнейшее расследование.

На приведенном выше снимке экрана большая часть ресурсов занята ЦП БД = 64 % времени БД. Захват ресурсов БД CUP — нормальная ситуация.

Давайте возьмем пример. Событием является "переключение файла журнала (незавершенная контрольная точка)", которое имеет высокие ожидания, огромное время (с) и большие значения среднего ожидания (мс), а класс ожидания является конфигурацией. Итак, здесь вам нужно исследовать и устранить переключение файла журнала (контрольная точка не завершена).

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

Крайне важно заглянуть в этот раздел. Если вы отключите статистический параметр, время не будет отображаться. Анализ ожидания должен выполняться с учетом времени (время), так как может быть миллион ожиданий, но если это произойдет в течение секунды или около того, то кого это волнует. Поэтому время является очень важной составляющей.

Итак, у вас есть несколько разных типов ожидания. Таким образом, вы можете увидеть различные ожидания в своем отчете AWR. Итак, давайте обсудим наиболее распространенные варианты ожидания.

Ожидания

файла df:

последовательное чтение файла db:

Это ожидание, происходящее с физической стороны базы данных. это связано с нехваткой памяти и неселективным использованием индекса. последовательное чтение — это чтение индекса, за которым следует чтение таблицы, потому что оно выполняет поиск по индексу, который точно сообщает, к какому блоку перейти

рассеянное чтение файла db:

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

Прямой путь пишет:

Вы не увидите их, если не выполняете какие-либо добавления или загрузку данных

Чтение прямого пути:

может произойти, если вы выполняете много параллельных запросов

параллельная запись/чтение файла db:

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

однократная запись файла базы данных:

если вы видите это событие, вероятно, в вашей базе данных много файлов данных.

временное чтение прямого пути или временное время записи прямого пути:

это событие ожидания показывает активность временного файла (сортировка, хэши, временные таблицы, растровое изображение)
проверка параметра pga или области сортировки или хэша параметры площади. Возможно, вы захотите увеличить их
Статистика ЦП хоста, ЦП экземпляра и памяти не требует пояснений.

5. Статистика модели времени:

Это подробное объяснение потребления системных ресурсов. Статистика упорядочена по времени (с) и % времени БД.

Заметный результат Сумма всех % времени БД > 100%. почему это ?
Потому что это кумулятивное время, т. е. в этом случае истекшее время выполнения SQL занимает 89% времени БД, включая его части, такие как истекшее время синтаксического анализа, истекшее время жесткого синтаксического анализа и т. д. Итак, если вы обнаружите, что истекшее время жесткого синтаксического анализа занимает больше %. Так что исследуйте дальше и так далее.
БД должен искать статистику, которая занимает ненормальный % времени БД.

6. Статистика операционной системы — подробности:

Это информация, относящаяся к ОС, каков статус загрузки системы, показанный здесь.

В этом отчете показано, что на момент составления отчета система простаивала на 62% и 70%. Таким образом, на системном уровне не было дефицита ресурсов. Но если вы обнаружили очень высокий процент занятости, пользователя или системы, это действительно приведет к низкому проценту простоя. Исследуйте, чем это вызвано. OS Watcher — это инструмент, который может помочь в этом направлении.
Следующая, очень важная часть отчета AWR для администратора баз данных — статистика SQL. Все детали SQL-запроса выполняются в течение интервала времени отчета.

Мы рассмотрим некоторые из них, чтобы понять, как анализировать эти отчеты. Начнем с

7. SQL, упорядоченный по прошедшему времени:

Как следует из самого названия, здесь перечислены SQL-запросы, упорядоченные по истекшему времени в указанный интервал времени.

В этом отчете ищите запрос с низким числом выполнений и высоким значением истекшего времени на выполнение (с), и этот запрос может быть кандидатом на устранение неполадок или оптимизацию. В приведенном выше отчете вы можете видеть, что первый запрос имеет максимальное истекшее время, но не выполняется.Так что вы должны расследовать это.
Важный момент: если количество выполнений равно 0, это не означает, что запрос не выполняется, это может быть в том случае, когда запрос все еще выполнялся, а вы получили отчет AWR. Вот почему завершение запроса не было отражено в отчете.

10. Статистика SQL:

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

статистика, ищите запросы с наибольшим временем ЦП. Если запрос показывает выполнение 0, это не означает, что запрос не выполняется. Это может быть тот же случай, что и в SQL-запросах, упорядоченных по прошедшему времени. Запрос все еще выполняется, и вы сделали снимок.

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

В этой статье я объясню, как анализировать, интерпретировать или читать отчет AWR (автоматический репозиторий рабочей нагрузки) в Oracle.

Анализ, интерпретация или чтение отчета AWR

Если вы не знаете, что такое AWR и как его создать, прочтите перед этим следующую статью. Поскольку я не буду объяснять эти темы в этой статье, я просто объясню, как это анализировать.

Прочитанный отчет AWR (автоматический репозиторий рабочей нагрузки)

Аналитический отчет AWR

Если вы подробно изучите этот раздел, в него будет включена основная информация о базе данных, сервере базы данных и отчете AWR. Эта информация включает имя базы данных, имя экземпляра, запуск, версию, кластер, имя хоста сервера базы данных, платформу сервера, номер процессора, размер ОЗУ и т. д.

Время начала и окончания снимков также находится в этом разделе. Перед созданием отчета AWR необходимо указать правильное время начала и окончания.

Отчет AWR – Загрузить профиль

Этот раздел является одним из самых важных в отчете AWR. Потому что вы можете узнать загрузку базы данных из времени БД, транзакций, жесткого разбора, размера повтора, физического чтения, записи и т. д. в единицах в секунду и транзакций в секунду.

Если вы хотите принять правильное решение, вам необходимо подробно проанализировать и сравнить отчет AWR как минимум с двумя или тремя отчетами AWR. Эти отчеты AWR должны быть за прошлый день и за последнюю неделю или месяц, а именно, они должны быть одинаковыми или похожими.

Чтобы узнать, является ли значение профиля нагрузки высоким или нет, сравните эти значения со старыми отчетами AWR.

Например, если количество транзакций одинаково, но время БД очень велико в соответствии со старым , то, вероятно, в базе данных есть параллелизм, блокировка или другие подобные события ожидания.

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

Если параметр Hard Parse очень высок (20-30 в секунду или более), то в ваших запросах не используются переменные Bind. Вы можете проверить их с помощью следующего скрипта. Настоятельно рекомендуется использовать переменные Bind в запросах.

Время БД: прошедшее время сеансов в базе данных. Время БД = время процессора + ожидания.

ЦП БД: прошедшее время сеанса в ЦП.

Размер повтора: размер повтора (в байтах) между двумя снимками.

Логические чтения: количество логических операций чтения в базе данных. Логическое чтение = получение согласованных данных + получение блоков БД

Блокировать изменения: блокировка изменений засчитывается между двумя моментальными снимками.

Физические чтения: число физических операций чтения в базе данных. Если какой-либо блок не существует в памяти, Oracle выполняет физическое чтение, чтобы получить этот блок из файла данных.

Физические записи: количество физических записей в базе данных. Если какой-либо чистый блок еще не записывает файл данных, Oracle выполняет физическую запись, чтобы записать этот блок в файл данных.

Вызовы пользователей: количество запросов или вызовов, отправленных в базу данных пользователями базы данных в диапазоне 2 моментальных снимков.

Синтаксический анализ: это сумма аппаратного и мягкого синтаксического анализа, которые происходят в базе данных в диапазоне 2 моментальных снимков.

Hard Parses: количество Hard Parses, происходящих в базе данных в диапазоне 2 моментальных снимков.(Если запрос ранее не выполнялся, SQL анализируется, создается план выполнения и сохраняется в области Shared SQL в библиотечном кэше. Эта операция называется жестким разбором.

Вт/МБ обработано: количество операций хеш-соединения или сортировки между двумя снимками

Входы в систему: количество входов в базу данных между 2 моментальными снимками

Выполнений: количество выполнений

Откаты: количество операций отката

Транзакции: количество транзакций между двумя снимками

Основные события переднего плана или класс событий ожидания

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

Если количество событий ожидания больше %5 или очень высокое, за исключением ЦП БД , вам необходимо проанализировать каждое событие ожидания.

Я подробно объясню каждое событие ожидания в следующих сообщениях, потому что каждое событие ожидания по-разному влияет на базу данных с точки зрения производительности.

Я продолжу объяснять, как анализировать отчет AWR, в следующем посте.

Вы можете получить доступ ко второй публикации отчета AWR по следующей ссылке.

Если вы хотите подробно изучить настройку производительности базы данных Oracle, щелкните эту ссылку.

6275 просмотров в прошлом месяце, 8 просмотров сегодня

О Мехмете Салихе Деведжи

Я являюсь основателем SysDBASoft IT and IT Tutorial и сертифицированным экспертом по базам данных Oracle и SQL Server, Goldengate, Exadata Machine, администратором Oracle Database Appliance с более чем 10-летним опытом работы. У меня есть сертификаты экспертов OCA, OCP, OCE RAC. Я работал. Более 100 банковских, страховых, финансовых, телекоммуникационных и т. д. клиентов в качестве консультанта, Insource или Outsource. Я выполнил более 200 операций в этих клиентах, таких как установка Exadata, PoC, миграция и обновление, обновление базы данных Oracle и SQL Server, Oracle RAC Установка, установка SQL Server AlwaysOn, миграция базы данных, аварийное восстановление, восстановление резервной копии, настройка производительности, периодические проверки работоспособности. Я выполнил более 2000 репликаций таблиц с помощью Goldengate или инструмента репликации SQL Server для баз данных DWH во многих клиентах. Если вам нужен Oracle DBA, SQL Администратор баз данных серверов, администратор баз данных приложений, Exadata, Goldengate, консультации и обучение EBS, вы можете отправить мой адрес электронной почты [email protected] .- - Oracle DBA, администратор баз данных SQL Server, администратор баз данных приложений, Exadata, Goldengate, EBS и linux Danışmanl ık ve Eğitim için [email protected] a mail atabilirsiniz.

2 комментария

Спасибо, что поделились и подробно объяснили..

Добро пожаловать, у нас есть много руководств по базе данных Oracle. Вы также можете просмотреть их.

Автоматический репозиторий рабочей нагрузки (AWR) Oracle собирает, обрабатывает и поддерживает статистику производительности для обнаружения проблем и самонастройки. Отчет, созданный AWR, представляет собой большой отчет, и могут потребоваться годы опыта, чтобы действительно понять все аспекты этого отчета. В этом посте мы попытаемся объяснить некоторые важные разделы AWR, значение этих разделов, а также несколько важных советов. Обратите внимание, что объяснение всех разделов AWR невозможно, поэтому мы остановимся на некоторых из наиболее часто используемых разделов.

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

Для начала давайте упомянем несколько важных советов относительно AWR:

<р>1. Соберите несколько отчетов AWR: полезно иметь два отчета AWR, один для хорошего времени, а другой, когда производительность низкая, или вы можете создать три отчета (отчеты до/между временем/после) в течение периода времени, когда возникла проблема, и сравнить его с временные рамки до и после.

<р>2. Придерживайтесь определенного времени: у вас должно быть определенное время, когда база данных была медленной, чтобы вы могли выбрать более короткий период времени для получения более точного отчета.

<р>3. Разделите большой отчет AWR на более мелкие отчеты: вместо того, чтобы иметь один отчет в течение длительного времени, как один отчет в течение 3 часов. лучше иметь три доклада каждый по одному часу. Это поможет изолировать проблему

<р>4. ДЛЯ RAC используйте отдельный отчет для каждого экземпляра: для среды RAC вам нужно сделать это отдельно для всех экземпляров в RAC, чтобы увидеть, все ли экземпляры сбалансированы так, как должны быть.

<р>5. Также используйте ASH: используйте AWR, чтобы определить проблемные области, а затем используйте ASH, чтобы подтвердить эти области.

<р>6. Увеличьте срок хранения. В некоторых случаях, когда вы получаете больше проблем с производительностью, вам следует увеличить время хранения, чтобы иметь возможность сравнивать исторические данные.

ЕДИНИЦЫ ВРЕМЕНИ, ИСПОЛЬЗУЕМЫЕ В РАЗЛИЧНЫХ РАЗДЕЛАХ ОТЧЕТОВ AWR

-> s – секунды
-> cs – сантисекунды – сотые доли секунды
-> ms – миллисекунды – 1000 доли секунды
-> us – микросекунды – 1000000 доли секунды

Верхний заголовок

ЗНАЧЕНИЕ ЭТОГО РАЗДЕЛА:

Содержит информацию о базе данных и среде. Наряду с идентификаторами моментальных снимков и временем. Важно отметить, что конфигурация ЦП и памяти не изменилась при снижении производительности.

ПАРАМЕТР	ОПИСАНИЕ	АНАЛИЗ
ВРЕМЯ БД	Время, проведенное в базе данных в течение прошедшего времени ИЛИ Сумма времени, затраченного всеми сеансами в базе данных в течение прошедшего времени. Время БД = время процессора + время ожидания без простоя. Примечание: это не включает фоновые процессы	ВРЕМЯ БД > Прошедшее время будет означать, что сеансы были активны в базе данных одновременно

Вы можете найти среднее количество активных сеансов в течение времени AWR:

ВРЕМЯ БД/ПРОШЕДШЕЕ => 1964,97/899,99 = 2,18

Итак, нагрузка на базу данных (среднее количество активных сеансов) = 2,18

(ТА ЖЕ ИДЕЯ, КАК НАГРУЗКА ЦП в UNIX)

Возможно, ~2 пользователя были активны в базе данных в течение «прошедшего» времени.
или
Может быть 4 пользователя были активны в течение прошедшего времени/2 каждый
или
Может быть 8 пользователей были активны в течение прошедшего времени/4 каждый
или
Возможно, 64 пользователя были активны в течение прошедшего времени/32 каждый

Если время БД имеет более высокое значение, это означает, что активность/сеансы БД были высокими в течение времени AWR.

ОТЧЕТ AWR, КОТОРЫЙ МЫ РАССМОТРИМ НИЖЕ, ОСНОВАН НА ЭТОМ ВРЕМЕНИ БД.

Это означает, что на каждую минуту Истекшего времени в базе данных выполняется 2,2 минуты работы

Вчера у моей базы данных были серьезные проблемы с производительностью. Я искал везде, но не нашел проблемы. Я не знаю, как интерпретировать отчет AWR, не могли бы вы помочь мне прочитать мой отчет.

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

Не существует идеального способа прочитать отчет AWR (или Statspack), хотя есть две или три части, которые вам следует прочитать для начала. Профиль нагрузки сообщает вам кое-что о характере выполняемой работы, основное время сообщает вам, где было потрачено больше всего времени (и, следовательно, где вы могли бы наиболее эффективно сократить затраченное время), а SQL, упорядоченный по xxxx, сообщает вам о SQL. что использовал время. Есть и другие части, которые могут быть очень полезными, но этих трех часто достаточно, чтобы начать полезный анализ.

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

Вы можете просмотреть несколько статьй из этого списка, чтобы найти дополнительные идеи.

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

Наблюдения

Похоже, что база данных не использовалась для выполнения большой работы, кроме создания большого количества больших индексов. Возможно, что-то сделало массовое «создание набора таблиц», «создание набора индексов» за эти 5 часов. Проблема с этим анализом в том, что вы ничего не сказали о том, что вы ожидаете увидеть, по сравнению с тем, что вы видели на самом деле. Возможно, вы ожидаете увидеть много операций «создать таблицу/индекс», но, возможно, считаете, что это должно быть выполнено за 1 час, а не за 5.

Симптомы, ведущие к наблюдению.

a) Профиль нагрузки: время БД — 12 секунд в секунду, ЦП БД — 0,6 секунды в секунду. Таким образом, большая часть вашего времени тратится на ввод-вывод (я заметил из статистики ОС, что у вас 12 процессоров, поэтому мне интересно, вы постоянно выполняли 12 одновременных операторов CREATE или, может быть, вы распараллелили несколько операций Create). заявления).

b) 10 наиболее важных событий переднего плана по общему времени ожидания: очень большая часть общего времени приходится на запись по прямому пути, еще одна значительная часть — на чтение по прямому пути, еще одна — на временную запись по прямому пути. Это похоже на сканирование таблиц с прямым путем с очень большими выбросами на диск при сортировке для создания индексов.

c) SQL, упорядоченный по физическим операциям чтения: первые 5 операторов – "CREATE INDEX", но на них приходится только 44 % операций ввода-вывода, поэтому, возможно, существует больше операций Create, которые были завершены и сброшены.

d) Сегменты по прямой физической записи: все индексы с BKHIS в именах до I7 (с пропущенной парой цифр).

e) Сегменты по прямому физическому чтению: верхний — это таблица BKHIS.

f) Активность экземпляра: "Параллелизованные операторы DDL" 2 827

Итак, проделано много работы над параллельным DDL, но особенно над созданием индексов в BKHIS — это нормальное поведение?

Читайте также: