home \ Oracle
Написано: 03.01.2023

2. Метод повышения производительности БД Oracle

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

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

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

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

В этой главе обсуждается метод повышения производительности БД Oracle и содержатся следующие разделы:

Сбор статистики БД с использованием автоматического хранилища рабочей нагрузки

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

Накопительная статистика – это число (например такое, как количество считываний блока). БД Oracle генерирует множество типов накопительной статистики для системы, сеансов и отдельных инструкций SQL. БД Oracle Database также отслеживает накопительную статистику по сегментам и службам. Автоматическое хранилище рабочей нагрузки (AWR) автоматически собирает статистику БД путем сбора, обработки и поддержания статистики производительности для целей обнаружения проблем с БД и самонастройки.

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

Следующие параметры инициализации актуальны для AWR:

  • STATISTICS_LEVEL
    Установка этого параметра в значение TYPICAL (по умолчанию) или ALL позволяет собирать статистику AWR. Установка STATISTICS_LEVEL в значение BASIC отключает многие функции БД, включая AWR, и не рекомендуется.

  • CONTROL_MANAGEMENT_PACK_ACCESS
    Установка значения DIAGNOSTIC+TUNING (по умолчанию) или DIAGNOSTIC включает автоматический диагностический мониторинг БД. Установка CONTROL_MANAGEMENT_PACK_ACCESS в значение NONE отключает многие функции БД, в том числе ADDM, и настоятельно не рекомендуется.

Смотрите также:

  • Oracle Database Reference для получения дополнительной информации о параметре инициализации STATISTICS_LEVEL

  • Oracle Database Reference для получения дополнительной информации о параметре инициализации CONTROL_MANAGEMENT_PACK_ACCESS

Статистические данные БД, собранные и обработанные AWR, включают:

Time Model Statistics

Статистика временной модели измеряет время, проведенное в БД, в зависимости от типа операции. Наиболее важной статистикой временной модели является время БД (DB time). Время БД представляет собой общее время, затраченное на вызовы БД активными сессиями, и является показателем общей рабочей нагрузки экземпляра. Как показано на рисунке 2-1, время работы БД составляет часть общего времени отклика пользователя приложения.

Fig2-1

Сессия – это логический объект в памяти экземпляра БД, который представляет состояние текущего входа пользователя в БД. Время работы БД рассчитывается путем суммирования процессорного времени и времени ожидания всех активных сессий (сессий, которые не простаивают). Для любого запроса БД процессорное время – это сумма времени, затраченного на обработку запроса, в то время как время ожидания – это сумма всех ожиданий различных ресурсов экземпляра БД. Время БД включает только время, затраченное на клиентские процессы, и не включает время, затраченное на фоновые процессы, такие как PMON.

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

Fig2-2

  1. Query for novels by author
    Пользователь выполняет поиск романов определенного автора. Это действие заставляет приложение выполнять запрос к базе данных для романов автора.

  2. Browse results of query
    Пользователь просматривает возвращенный список романов автора и получает доступ к дополнительной информации, такой как отзывы пользователей и статус учёта. Это действие заставляет приложение выполнять дополнительные запросы к БД.

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

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

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

Обратите внимание: Время в БД измеряется накопительно с момента запуска экземпляра. Поскольку время БД объединяет время всех непростаивающих пользовательских сессий, время БД может превышать время, прошедшее с момента запуска экземпляра. Например, экземпляр, который проработал 5 минут, может иметь четыре активных сеанса, совокупное время работы с БД которых составляет 20 минут.

Целью настройки БД является сокращение времени работы с БД. Таким образом, вы можете улучшить общее время отклика пользовательских транзакций в приложении.

Wait Event Statistics

События ожидания возрастают за сессию и показывают, что сессия ожидала завершения события, прежде чем смогла продолжить обработку. Когда сессии приходится ждать во время обработки пользовательского запроса, БД записывает ожидание, используя одно из набора предопределенных событий ожидания. Затем события группируются в классы ожидания, такие как пользовательский ввод-вывод и сетевой. Данные о событии ожидания выявляют симптомы проблем, которые могут влиять на производительность, таких как задержка, буфер или конфликт ввода-вывода.

Смотрите также:

Session and System Statistics

Большое количество накопленной статистики БД доступно на системном и сессионном уровне. Некоторые из этих статистических данных собраны AWR.

Active Session History Statistics

Статистика истории активных сессий (ASH) представляет собой образцы активности сессии в БД. БД опрашивает активные сессии каждую секунду и сохраняет их в циклическом буфере в глобальной области системы (SGA). Любая сессия, подключенная к БД и использующая процессор, или ожидающая события, которое не относится к классу ожидания в режиме ожидания, считается активной. Фиксируя только активные сессии, можно получить управляемый набор данных. Размер данных напрямую связан с выполняемой работой, а не с количеством сессий, разрешенных для БД.

Используя пример времени DB, описанный в “Time Model Statistics”, образцы активности сессии собираются из онлайн-транзакции, совершенной на веб-сайте книготорговца, представленными вертикальными линиями под горизонтальной стрелкой на рисунке 2-3.

Fig2-3

Светлые вертикальные линии представляют образцы неактивной активности сессии, которые не учитываются в статистике ASH. Жирные вертикальные линии представляют образцы активных сессий, которые записаны в:

  • 7:38, когда произошёл запрос романов автора

  • 7:42, когда пользователь просматривал результат запроса

  • 7:50, когда в корзину был добавлен один роман

  • 7:52, во время совершения заказа

Time SID Module SQL ID State Event
7:38 213 Book by author qa324jffritcf Waiting db file sequential read
7:42 213 Get review ID aferv5desfzs5 CPU n/a
7:50 213 Add item to cart hk32pekfcbdfr Waiting buffer busy wait
7:52 213 Checkout abngldf95f4de Waiting log file sync

High-Load SQL Statistics

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

Использование метода производительности Oracle

Настройка производительности с использованием метода Oracle performance осуществляется путем выявления и устранения узких мест в базе данных, а также путем разработки эффективных инструкций SQL. Настройка базы данных выполняется в два этапа: проактивно и реактивно.

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

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

Настройка SQL – это итеративный процесс для идентификации, настройки и повышения эффективности высоконагруженных SQL-инструкций.

Применение метода производительности Oracle включает в себя следующее:

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

Подготовка БД к настройке

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

Для подготовки базы данных к настройке:

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

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

  3. Убедитесь, что для параметра инициализации STATISTICS_LEVEL установлено значение TYPICAL (по умолчанию) или ALL, чтобы включить функции автоматической настройки производительности Oracle Database, включая AWR и ADDM.

  4. Убедитесь, что для параметра инициализации CONTROL_MANAGEMENT_PACK_ACCESS установлено значение DIAGNOSTIC+TUNING (по умолчанию) или DIAGNOSTIC для включения ADDM.

Предварительная настройка БД

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

Для предварительной настройки БД:

  1. Просматривайте результаты ADDM, как описано в разделе Автоматический мониторинг производительности базы данных.
    ADDM автоматически обнаруживает проблемы с производительностью базы данных и сообщает о них, включая большинство “распространенных проблем с производительностью, обнаруженных в БД”. Результаты отображаются в виде результатов ADDM на домашней странице базы данных в Oracle Enterprise Manager Cloud Control (Облачный контроль). Анализ этих результатов позволяет вам быстро выявить проблемы с производительностью, требующие вашего внимания.

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

  3. Отслеживайте проблемы с производительностью БД в режиме реального времени, как описано в разделе Мониторинг производительности базы данных в режиме реального времени.
    Страница производительности в Cloud Control позволяет выявлять проблемы с производительностью в режиме реального времени и реагировать на них. Переходя к соответствующим страницам, вы можете выявлять и устранять проблемы с производительностью базы данных в режиме реального времени, не дожидаясь следующего анализа ADDM.

  4. Реагируйте на предупреждения, связанные с производительностью, как описано в разделе Мониторинг предупреждений о производительности.
    На домашней странице базы данных в Cloud Control отображаются предупреждения, связанные с производительностью, генерируемые базой данных. Как правило, устранение проблем, указанных в этих предупреждениях, повышает производительность БД.

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

Реагирующая настройка БД

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

Для реактивной настройки БД:

  1. Запустите ADDM вручную для диагностики текущей и исторической производительности БД, когда пользователи сообщают о проблемах с производительностью, как описано в разделе Мониторинг производительности БД вручную.
    Таким образом, вы можете проанализировать текущую производительность БД перед следующим анализом ADDM или проанализировать историческую производительность БД, когда вы не осуществляли упреждающий мониторинг системы.

  2. Устраните временные проблемы с производительностью, как описано в разделе Устранение временных проблем с производительностью.
    Отчеты об истории активных сеансов (ASH) позволяют анализировать временные проблемы с производительностью БД, которые являются кратковременными и не отображаются в анализе ADDM.

  3. Устраните снижение производительности с течением времени, как описано в разделе Устранение снижения производительности с течением времени.
    Отчет о сравнении периодов автоматического хранилища рабочей нагрузки (AWR) позволяет сравнить производительность БД за два периода времени и устранить снижение производительности, которое может произойти от одного периода времени к другому.

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

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

Настройка SQL-инструкций

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

Для настройки SQL-инструкций:

  1. Определите высоконагруженные инструкции SQL, как описано в разделе Определение высоконагруженных инструкций SQL.
    Используйте результаты ADDM и раздел Top SQL, чтобы определить высоконагруженные инструкции SQL, которые вызывают наибольшие разногласия.

  2. Настройте высоконагруженные SQL-инструкции, как описано в разделе Настройка SQL-инструкций.
    Вы можете повысить эффективность высоконагруженных SQL-инструкций, настроив их с помощью SQL Tuning Advisor.

  3. Оптимизируйте пути доступа к данным, как описано в разделе Оптимизация путей доступа к данным.
    Вы можете оптимизировать производительность путей доступа к данным, создав соответствующий набор материализованных представлений, журналов материализованных представлений и индексов для заданной рабочей нагрузки с помощью SQL Access Advisor.

  4. Проанализируйте влияние настройки SQL и других системных изменений на производительность SQL с помощью SQL Performance Analyzer.
    Чтобы узнать, как использовать SQL Performance Analyzer, см. Руководство по тестированию БД Oracle.

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

Распространенные проблемы с производительностью, обнаруживаемые в БД

В этом разделе перечислены и описаны распространенные проблемы с производительностью, обнаруживаемые в БД. Следуя методу производительности Oracle, вы сможете избежать этих проблем в экземпляре БД Oracle. Если у вас возникли эти проблемы, повторите действия в методе производительности Oracle, как описано в разделе “Использование метода производительности Oracle”, или обратитесь к соответствующему разделу, в котором рассматриваются эти проблемы:

  • Узкие места процессора
    Приложение работает плохо из-за того, что система привязана к процессору? Проблемы с производительностью, вызванные узкими местами процессора, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД. Вы также можете определить узкие места процессора, используя страницу производительности в Cloud Control, как описано в разделе “Мониторинг загрузки процессора”.

  • Недостаточные структуры памяти
    Достаточны ли размеры структур памяти Oracle, таких как Глобальная область системы (SGA), глобальная область программы (PGA) и буферный кэш? Проблемы с производительностью, вызванные недостаточными размерами структур памяти, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД. Вы также можете определить проблемы с использованием памяти, используя страницу производительности в Cloud Control, как описано в разделе “Мониторинг использования памяти”.

  • Проблемы с пропускной способностью ввода-вывода
    Работает ли подсистема ввода-вывода так, как ожидалось? Проблемы с производительностью, вызванные проблемами с пропускной способностью ввода-вывода, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД. Вы также можете определить проблемы с дисковым вводом-выводом, используя страницу производительности в Cloud Control, как описано в разделе “Мониторинг использования дискового ввода-вывода”.

  • Неоптимальное использование приложением БД Oracle
    Оптимально ли использует приложение БД Oracle? Такие проблемы, как многократное установление новых подключений к БД, чрезмерный синтаксический анализ SQL и высокий уровень конкуренции за небольшой объем данных (также известный как конкуренция блоков на уровне приложения), могут значительно снизить производительность приложения. Проблемы с производительностью, вызванные неоптимальным использованием приложением БД Oracle, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД. Вы также можете отслеживать активность пользователей в различных измерениях, включая SQL, сеанс, службы, модули и действия, используя страницу производительности в Cloud Control, как описано в разделе “Мониторинг активности пользователей”.

  • Проблемы параллелизма
    Оптимально ли работает БД из-за высокой степени параллельных действий в БД? Высокая степень одновременности действий может привести к конкуренции за общие ресурсы, которая может проявляться в виде блокировок или ожидания буферного кэша. Проблемы с производительностью, вызванные проблемами параллелизма, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД. Вы также можете выявить проблемы с параллелизмом, используя сеансы Top в Cloud Control, как описано в разделе “Мониторинг сеансов Top”.

  • Проблемы с конфигурацией БД
    Оптимально ли настроена БД для обеспечения желаемых уровней производительности? Например, есть ли признаки неправильного размера файлов журналов, проблем с архивированием, слишком большого количества контрольных точек или неоптимальных настроек параметров? Проблемы с производительностью, вызванные проблемами конфигурации БД, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД.

  • Кратковременные проблемы с производительностью
    Жалуются ли пользователи на кратковременные или прерывистые проблемы с производительностью? В зависимости от интервала между моментальными снимками, сделанными AWR, проблемы с производительностью, которые имеют короткую продолжительность, могут не быть зафиксированы ADDM. Вы можете определить кратковременные проблемы с производительностью, используя отчет об истории активных сеансов, как описано в разделе Устранение временных проблем с производительностью.

  • Снижение производительности БД с течением времени
    Есть ли доказательства того, что производительность БД со временем снизилась? Например, замечаете ли вы или ваши пользователи, что БД работает не так хорошо, как это было 6 месяцев назад? Вы можете сгенерировать отчет AWR Compare Periods, чтобы сравнить период, когда производительность была низкой, с периодом, когда производительность стабильна, чтобы определить параметры конфигурации, профиль рабочей нагрузки и статистику, которые отличаются между этими двумя периодами времени. Этот метод поможет вам определить причину снижения производительности, как описано в разделе Устранение снижения производительности с течением времени.

  • Неэффективные или высоконагруженные SQL-инструкции
    Используют ли какие-либо инструкции SQL чрезмерные системные ресурсы, которые влияют на систему? Проблемы с производительностью, вызванные высоконагруженными SQL-инструкциями, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД и “Идентификация высоконагруженных SQL-инструкций с использованием результатов ADDM”. Вы также можете идентифицировать высоконагруженные SQL-инструкции с помощью Top SQL в Cloud Control, как описано в разделе “Идентификация высоконагруженных SQL-инструкций с помощью Top SQL”. После того, как они будут идентифицированы, вы можете настроить высоконагруженные SQL-инструкции с помощью SQL Tuning Advisor, как описано в разделе Настройка SQL-инструкций.

  • Конфликт объектов
    Являются ли какие-либо объекты БД источником узких мест из-за постоянного доступа к ним? Проблемы с производительностью, вызванные конфликтом объектов, диагностируются ADDM, как описано в разделе Автоматический мониторинг производительности БД. Вы также можете оптимизировать путь доступа к данным к этим объектам с помощью SQL Access Advisor, как описано в разделе Оптимизация путей доступа к данным.

  • Неожиданный регресс производительности после настройки SQL-инструкций
    Ухудшается ли производительность SQL-инструкций после того, как они были настроены? Настройка инструкций SQL может привести к изменениям в планах их выполнения, что окажет значительное влияние на производительность SQL. В некоторых случаях изменения могут привести к улучшению производительности SQL. В других случаях изменения могут привести к регрессу SQL-инструкций, что приведет к снижению производительности SQL.

Прежде чем вносить изменения в производственную систему, вы можете проанализировать влияние настройки SQL на тестовую систему с помощью SQL Performance Analyzer. Эта функция позволяет прогнозировать влияние системных изменений на рабочую нагрузку SQL с помощью:

  • Измерение производительности до и после изменения

  • Создание отчета, описывающего изменение производительности

  • Определение инструкций SQL, которые регрессировали или улучшились

  • Предоставление рекомендаций по настройке для каждого оператора SQL, который регрессировал

  • Позволяют вам выполнять рекомендации по настройке, когда это необходимо