Вход |  Регистрация

Все Тэги

Мониторинг Oracle: оптимизация и тюнинг

30.01.20141337 просм.

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

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

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

  • Убедитесь, что Оптимизатор Затрат Oracle(Cost Based Optimizer) запущен
  • Регулярно собирайте статистику оптимизатора
  • Оптимизируйте SQL запросы:
    • Определите проблемные SQL запросы (то есть те, которые слишком долго выполняются)
    • Проанализируйте по ним статистику Oracle оптимизатора (убедитесь, что данные актуальны)
    • Проанализируйте план выполнения
    • При необходимости измените структуру SQL запросов
    • При необходимости измените структуру индекса
    • Видоизменяйте планы выполнения с течением времени
  • Используйте связанные переменные в SQL запросах. Это поможет сократить количество курсоров, хранящихся в общем пуле.
  • Аккуратно используйте индексы. Не стоит индексировать все столбцы, а только те, к которым обращается больше всего запросов.
  • Помогите SQL оптимизатору с помощью подсказок (optimization hints). Это следует делать после анализа производительности SQL запросов.
  • Оптимизируйте размер структур памяти. Размер Общего Пула, Буферного Кэша и других структур памяти критичен для производительности баз данных.
    • Смоделируйте стандартную рабочую нагрузку приложения.
    • Мониторьте ожидания, попадания в кэш, подкачку и своп страниц и т.д.
    • Вот перечень самых основных параметров, которые нуждаются в тюнинге:

Параметр          Описание

 db_cache_size – Определяет размер буферного кэша в SGA.

db_keep_cache_size – Объекты, попавшие в этот кэш, остаются в нем навсегда. Сюда помещают те объекты, к которым чаще всего обращаются и которые должны сохраняться в памяти. Например, маленькие часто используемые таблицы поиска. Этот кэш – один из кэшей по умолчанию, и задается параметром DB_CACHE_SIZE. Это обязательный параметр для любой БД.

shared_pool_size – Определяет размер Общего Пула.

pga_aggregate_target –  Задает общую целевую память PGA, доступную для всех серверных процессов связанных с экземпляром БД.

log_buffer – Определяет размер буфера журнала изменений.

query_rewrite_enabled – Определяет, может ли Oracle изменить SQL оператор, прежде чем его выполнить.

cursor_sharing  – Определяет, какие SQL операторы могут иметь общие курсоры.

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

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

  • Чтобы уменьшить количество операций ввода/вывода, необходимо стремиться получить высокий коэффициент buffer-cache hit. В среде OLTP он должен быть больше 80 в среде OLTP. Ну а идеал – 99.
  • Коэффициент Dictionary cache hit должен быть около 90%. Записей по dc_table_grants, d_user_grants, и dc_users должно быть меньше 5% в колонке MISS RATE %.
  • Monitor Sorts показывает соотношение между сортировкой на диске и памятью. Этот показатель должен быть меньше 0.10.
  • Сведите к минимуму борьбу за ресурсы базы данных. Проанализируйте количество блокировок и устраните все возможные.

Метки: , , ,

Добавить комментарий

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

Партнеры DevOpsHub и DevOpsWiki