Log file sync oracle это
Обновлено: 01.07.2024
Презентация начинается с обзора механизма семафоров в Linux. Рассматриваются функции semget, semtimedop и semctl. Так же дается описание реализации асинхронного ввода-вывода на Linux через функции io_submit и io_getevents.
Далее рассматриваются известные C-функции базы данных Oracle, такие как kskthbwt, kskthewt, kslgetl. Говорится о выявлении новой функции kslwt_update_stats_int, через которую происходит обновление статистики в v$sesstat. Рассматриваются средства трассировки выполняемых программ на Linux: strace, gdb, systemtap.
После этого приводятся результаты трассировки LGWR и пользовательских процессов при различных комбинация параметров _log_parallelism_max, in_memory_undo, _disable_logging, _use_adaptive_log_file_sync. В заключении даются рекомендации по настройке инстанса для минимизации ожиданий “log file sync” and “log file parallel write”.
Презентация начинается с обзора механизма семафоров в Linux. Рассматриваются функции semget, semtimedop и semctl. Так же дается описание реализации асинхронного ввода-вывода на Linux через функции io_submit и io_getevents.
Далее рассматриваются известные C-функции базы данных Oracle, такие как kskthbwt, kskthewt, kslgetl. Говорится о выявлении новой функции kslwt_update_stats_int, через которую происходит обновление статистики в v$sesstat. Рассматриваются средства трассировки выполняемых программ на Linux: strace, gdb, systemtap.
После этого приводятся результаты трассировки LGWR и пользовательских процессов при различных комбинация параметров _log_parallelism_max, in_memory_undo, _disable_logging, _use_adaptive_log_file_sync. В заключении даются рекомендации по настройке инстанса для минимизации ожиданий “log file sync” and “log file parallel write”.
Для участников конференции был доступен специальный тариф на проживание.
Обоснование трат
Хотите, чтобы ваша компания отправила вас нас конференцию PG Day’17 Russia?
Скопируйте этот образец письма, отредактируйте его под себя и отправьте его своему руководителю.
Я хочу посетить техническую конференцию Pg Day’17 Russia, посвященную базам данных,
которая состоится 5-7 июля 2017 в Санкт-Петербурге.
- Систематизировать имеющиеся знания о СУБД и приобрести новые;
- Получить рекомендации по использованию и эксплуатации СУБД;
- Улучшить собственные навыки работы с базами данных;
- Получить последнюю информацию о состоянии сообщества;
- Повысить свою продуктивность, получив ответы от мировых экспертов отрасли и переняв опыт коллег из других организаций;
- Почерпнуть новые идеи и узнать об инновационных методах работы.
- Ориентировочная стоимость авиабилетов — [15000] руб.
- Ориентировочная стоимость отеля: (ночь) — [5000] руб.
- Билет на конференцию — [18000] руб.
- Общая сумма — [38000] руб.
Соглашение на обработку персональных данных
Под персональными данными я понимаю любую информацию, относящуюся ко мне как к Субъекту Персональных Данных, в том числе мои фамилию, имя, отчество, адрес, профессию, контактные данные (телефон, факс, электронная почта, почтовый адрес), иную другую информацию. Под обработкой персональных данных я понимаю сбор, систематизацию, накопление, уточнение, обновление, изменение, использование, распространение, передачу, в том числе трансграничную, обезличивание, блокирование, уничтожение, бессрочное хранение), и любые другие действия (операции) с персональными данными.
Датой выдачи согласия на обработку персональных данных Субъекта Персональных Данных является дата отправки регистрационной формы с Сайта Компании.
Обработка персональных данных Субъекта Персональных Данных может осуществляться с помощью средств автоматизации и/или без использования средств автоматизации в соответствии с действующим законодательством РФ и внутренними положениями Компании.
Компания принимает необходимые правовые, организационные и технические меры или обеспечивает их принятие для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения персональных данных, а также от иных неправомерных действий в отношении персональных данных, а также принимает на себя обязательство сохранения конфиденциальности персональных данных Субъекта Персональных Данных. Компания вправе привлекать для обработки персональных данных Субъекта Персональных Данных субподрядчиков, а также вправе передавать персональные данные для обработки своим аффилированным лицам, обеспечивая при этом принятие такими субподрядчиками и аффилированными лицами соответствующих обязательств в части конфиденциальности персональных данных.
Я ознакомлен(а), что:
1. настоящее согласие на обработку моих персональных данных, указанных при регистрации на Сайте Компании, направляемых (заполненных) с использованием Cайта, действует в течение 20 (двадцати) лет с момента регистрации на Cайте Компании;
2. согласие может быть отозвано мною на основании письменного заявления в произвольной форме;
3. предоставление персональных данных третьих лиц без их согласия влечет ответственность в соответствии с действующим законодательством Российской Федерации.
Эта статья посвящена анализу некоторых результатов общей оценки производительности системы. По мотивам интересной публикации на сайте Тома Кайта от 16 марта 2004 года. Надеюсь, вы еще помните и регулярно посещаете его сайт.
Statspack: кто ждет событий log file sync и LGWR wait for redo copy?
Прошу прощения за точ, что не могу кратко сформулировать вопрос.
Вот выдержка из отчета statspack :
Я обратил внимание на CPU time - 3,747 секунды в системе с 4 HT-процессорами (в диспетчере задач Windows отображается 8 процессоров). Это означает, что на одну секунду реального времени приходится 5.85 секунды процессорного времени, затраченного многими одновременно работающими сеансами, загружающими данные в базу.
Теперь, возникает вопрос о событиях ожидания log file sync и LGWR wait for redo copy - я вижу время ожидания 65 секунд, и, насколько я понимаю, это время, которое провели в ожидании фоновые процессы. Если фоновые процессы ждали так долго, мне интересно, насколько это повлияло на пользовательские сеансы (сколько им пришлось ждать в это же время). (или, возможно, именно это время сеансы конечного пользователя и ждали, поскольку надо было копировать журналы повторного выполнения). Другими словами, это время ожидания самих фоновых процессов или время, в течение которого пользовательские сеансы ожидали завершения фоновых процессов?
Мы только что перевели кэш-буфер диска в режим только записи, как советуется в книге Джонатана Льюиса "Practical Oracle 8i " (ранее он использовался поровну на чтение и запись). При похожей загрузке системы мы увидели уменьшение этих статистических показателей (как по количеству ожиданий, так и по времени):
Могу задать вопрос и по-другому - если процесс LGWR прождал 3 секунды, пока копируются данные повторного выполнения, но ни один пользовательский сеанс из-за этого не ждал (если такое вообще возможно), отразится ли это на ожидании событий?
Ответ Тома Кайта
Рассмотрим процессорное время. При наличии продолжительных вызовов, оно легко может быть как больше, так и меньше , чем указано в отчете.
Пусть вы сделали снимок за период в 1 минуту. Пусть при этом происходили представленные выше "выполнения". statspack сообщит об использованных 80 секундах процессорного времени (50+30), поскольку статистика по процессорному времени учитывается при завершении вызова. Поэтому, вторая и четвертая строки внесли свой вклад в cpu time , а остальные - нет (они не завершились в рассматриваемый период). Учитывайте это.
log file sync - это клиентское ожидание события. Именно этого события ваши клиенты ждут, когда говорят "commit". Это ожидание, пока процесс LGWR фактически запишет их данные повторного выполнения на диск и фиксация транзакции будет завершена. Можно "настроить" этот процесс, ускорив работу процесса lgwr (отказавшись от использования raid 5, например) и фиксируя транзакции реже, генерируя меньше данных повторного выполнения (множественные изменения генерируют меньше данных повторного выполнения, чем построчные)
А вот другое ожидание - фоновое. Процесс LGWR ждет, пока приоритетные процессы закончат текущее копирование, затрагивающее данные, которые LGWR должен обработать.
ОДНАКО, с учетом всего вышесказанного, настройка любого из этих показателей, в любом случае, никак существенно не повлияет на производительность вашей системы! Похоже, основное ваше ожидание - " enqueue ", и связано оно с особенностями приложения. Это тяжеловесные блокировки, связанные с алгоритмом работы приложения. Вы достигшнете лучших результатов, изучая в этот момент приложение , а не "систему" в целом.
Установите для приложения событие трассировки 10046 уровня 12 и посмотрите, чего именно оно ждет. Все дело - в настройке приложения.
Все равно не понимаю LGWR wait for redo copy
Спасибо за полезный ответ! Не могли бы вы уточнить, зачем нужны эти ожидания LGWR - какие "приоритетные процессы закончат текущее копирование" и чего именно?
Проясняю в отношении CPU. Наш снимок - за 10 минут, тогда как большинство транзакций (а, значит, и вызовов операторов) завершается не более? чем за минуту => возможность недосчитать или пересчитать составляет +/-10%.
Проясняю в отношении Equeues (я ожидал такого комментария, но не хотел выбрасывать эту строку из отчета statspack). Очереди, однако, хотя и выглядят подозрительно - не вызывают проблем в нашей системе, просто потому, что так и было задумано . Наша система спроектирована так, что ряд фоновых заданий выполняет завершающую обработку данных после их загрузки. И, иногда? фоновые процессы ждут завершения приоритетных процессов (с помощью SELECT. FOR UPDATE), чтобы гарантировать согласованность. Идея в том, что хотя приритетные задания по загрузке могут требовать до одной минуты на транзакцию, эти фоновые задания срабатывают за пару секунд. Большую часть времени наши процессы очереди заданий (6 из них) простаивают, а когда просыпаются (каждую минуту) для выполнения недавно переданных заданий по завершающей обработке, могут обнаружить, что им надо подождать завершения других загрузок. Вреда от этого нет - даже если некоторые процессы очереди заданий из-за этого "зависают", другие процессы свободны и могут выполнять другие задания, а в самом худшем случае завершающая обработка откладывается не более? чем на минуту. Так что, хотя и можно было избавиться от "Enqueues", изменив время выполнения заданий по завершающей обработке, это, вероятно, не повысит общую производительность системы.
Наконец, вы правы в том, что настройка процесса LGWR и log file sync в нашем случае не сильно повысит общую производительность системы (очевидно, что речь идет примерно о 2% общего времени). На самом деле? цель была не столько в настройке, сколько в изучении и доказательстве утверждения Джонатана (установка процента использования кэша для чтения и записи на диске заняла одну минуту).
Ответ Тома Кайта
Копирование данных повторного выполнения - приоритетные процессы это делают (например, lgwr пытается сбросить буфер журнала по одной из причин, которая такой сброс вызывает - 3 секунды, заполнение 1/3, заполнение 1 Мбайта, commit).
Но, серьезно, - эти ожидания ничего не значат , и я бы посоветовал их игнорировать ПОКА они не появятся в результатах трассировки приложения!
Ваши комментарии об очередях (enqueues) - прекрасное объяснение, почему настройка с помощью statspack - "не лучший способ" и почему надо изучать приложение. Любой, кто посмотрит на такой отчет statspack , обратит внимание на enqueues - но вы-то знаете, что в вашем случае они связаны с простоем ("idle-ing waits") :)
Серьезно, какие приоритетные процессы и что копируют?
Я понял, и про настройку больше не спрашиваю. Поделитесь, пожалуйста, как обычно, недостающими нам знаниями. Приведите пример "приоритеного" процесса (это пользовательский сеанс или что-то еще) и того, что именно он копирует (данные, буферы журнала или что-то еще)?
Еще меня удивляет следующий результат:
Почему Oracle читает файл журнала повторного выполнения (кроме как при восстановлении, но мы его не выполняли в период? охваченный этим отчетом statspack )?
Ответ Тома Кайта
Процесс LGWR собирается записать набор блоков журнала на диск. Он должен подождать, пока приоритетный процесс (мы, вы и я) не завершит любые текущие операции копирования, затрагивающие буферы, которые мы собираемся записывать. Раньше была защелка ' redo copy latch ', но в 8i были сделаны изменения для повышения производительности, чтобы это делалось "быстрее".
Некоторые важные для анализа производительности систем Oracle события ожидания (wait events), статистики (statistics) и вычисляемые коэффициенты (ratio), используемые при анализе производительности и отчётов Statspack/AWR
События ожидания
Дисковый ввод-вывод (I/O wait events )
db file sequential read
Среднее время этого ожидания = фактическому среднему времени чтения одного блока БД (что на уровне ОС обычно называют выборочным или случайным чтением (random read)). Типичное нормальное значение
db file scattered read
read by other session
db file async i/o submit
недокументированное событие, появившееся начиная с Oracle 11.2, проявляется при установке комбинации параметров
с точки зрения настройки производительности ожидание db file async I/O submit должно рассматриваться как db file parallel write, или как другое ожидание выполнения операции дискового ввода-вывода (например, log file switch (checkpoint incomplete)). Точное название ожидания можно получить изменив значение параметра FILESYSTEMIO_OPTIONS на отличное от NONE
direct path read
Типичные ситуации возникновения ожидания:
по умолчанию, при старте инстанса параметр _small_table_threshold устанавливается
1.9-2 % от размера буферного кэша [__]db_cache_size / db_block_size
Для форсированного включения direct path read в документах поддержки упоминается установка параметра _serial_direct_read=TRUE (доступно на уровне сессии, значение по умолчанию FALSE до 11.2.0.1 включительно)
Для отключения Dion Cho Disabling direct path read for the serial full table scan– 11g нашёл и описал событие 10949:
Соответствующая ожиданию статистика physical reads direct
direct path write / direct path write temp
Соответствующая ожиданию статистика physical write direct
db file parallel read
В 11g используется, в основном, при индексном доступе к блокам таблицы, выполняемом параллельно PX slaves процессами
async disk IO | ksfd: async disk IO
control file sequential read
Disk file operations I/O
utl_file I/O
В соответствии с документацией ожидание фиксируется при использовании процедур пакета UTL_FILE
Обработка логов (Log waits)
log file sync
Пользовательский сессия (foreground process) ожидает совершения системным (background) процессом LGWR операции записи модифицированных данных из буфера в локальный или удалённый (при SYNC конфигурации standby сервиса) redo log файл во время выполнения пользовательской сессией операции завершения транзакции COMMIT / ROLLBACK
Может быть заметно в случае низкой скорости дисковой записи / сетевой передачи логов или высокой конкуренции за системные ресурсы (диск, процессор).
Типичные причины: неудачное размещение и [коственно] малый размер файлов redo, низкая производительность и/или неудачная конфигурация подсистемы ввода-вывода*), либо высокая (возможно, избыточная?) интенсивность операций COMMIT / ROLLBACK**. Нормальное время ожидания не должно превышать нескольких миллисекунд для OLTP систем
*) Пример: несколько копий лог файлов (для «надёжности») на одном небыстром разделе RAID5 либо RAID6 (для «экономии»). Время ожидания может легко превышать и 20, и 30, и 80 ms. Oracle категорически не рекомендует RAID5 для размещения online redo log файлов
**) При невозможности изменить приложение с целью уменьшить частоту транзакций, для буферизации и выбора асинхронного режима можно рассмотреть изменение параметров COMMIT_WRITE (начиная с Oracle 10g) или COMMIT_LOGGING, COMMIT_WAIT (начиная с 11g)
На пример отчёта AWR небольшого RAC 11.2.0.3 можно видеть, что время ожидания log file sync , в основном, тратится на запись логов процессом LGWR с ожиданием log file parallel write, которое кроме того включает время обработки запросов Global Cache Service от процессов LMS с соответсвующим ожиданием gcs log flush sync:
Для диагностики log file sync и связанных ожиданий может быть полезен скрипт lfsdiag.sql с сайта поддержки Oracle:
- параметры, влияющие на log file sync
- гистограммы ожиданий
- вычисляет и выводит данные о периодах наихудших средних времён ожидания log file sync из репозиториев Active Session History / AWR
Простой пример влияния конфигурации передачи логов на удалённый standby (определяемой параметром log_archive_dest_n) на ожидания log file sync и log file switch completion, первоначальная конфигурация:
log buffer space
log file switch completion
- недостаточный размер online лог файлов
- недостаточное количество групп лог файлов
- недостаточная скорость записи / передачи redo
- блокировки синхронного доступа к controlfile
log file switch (checkpoint incomplete)
log file switch (private strand flush incomplete)
LGWR wait for redo copy
wait on ATTACH
ожидание ARC | LGWR соединения с процессами RFS (Remote File Server) для выполнения архивации на удалённый сервис
Например, при безуспешных попытках архивации логов на отсутствующие/неработающие LOG_ARCHIVE_DESTINATION SERVICE, в AWR можно наблюдать сетевой таймаум
при этом соответствующий V$ARCHIVE_DEST.STATUS будет периодически менять значение VALID / ERROR
wait on SENDREQ
открытие, запись полученных redo данных, закрытие удалённых лог-файлов
wait on DETACH
завершение RFS соединения
LGWR wait on LNS
LNS wait on LGWR
LGWR-LNS wait on channel
Пример: при передаче логов на standby в SYNC режиме:
AWR показывает значительную долю ожиданий log file sync в топе:
Пользовательские процессы (JDBC Thin Client) при выполнении commit ожидают завершения операции log file sync, выполняемой системным процессом LGWR, который в свою очередь ожидает (в основном) события LGWR-LNS wait on channel, вызванного синхронной передачей логов (на standby):
После отключения SYNC режима для удалённых LOG_ARCHIVE_DEST среднее и суммарное времена ожидания log file sync снижаются на порядок (примерно в той же пропорции ускоряя бизнес-процессы, активно пишущие/обновляющие данные):
Ожидание LGWR-LNS wait on channel ожидаемо исчезает из топа ожиданий, блокирующих пользовательские операции commit:
Ожидания при работе с разделяемой памятью Oracle Shared Pool
library cache load lock
library cache lock [object handle]
library cache pin [object heap]
События, контролирующие загрузку и совместный доступ к объектам Library Cache (table, view, procedure, function, package, package body, trigger, index, cluster, synonym)
- сессия 368 на время выполнения процедуры sleep(1000); удерживает Library Cache Lock (на дескриптор процедуры) в состянии Null и Pin (на объект пула) в моде Share
- следующая по времени запуска сессия 357 для рекомпиляции той же процедуры получила Lock в состянии Exclusive и ожидает Exclusive Pin на соответствующем событии library cache pin. Pin (объект процедуры в Library Cache) блокирован сессией 368 на время выполнения в Share моде во избежание изменений
- последняя по времени сессия 347 ожидает Lock в Exclusive моде, кот.удерживается сессией 357 на соответствующем событии library cache lock. Получение Pin (блокировки на объект) до получения Lock (нахождение и блокировка дескриптора) невозможно
cursor: pin S wait on X (library cache pin)
Ожидание, связанное с разбором SQL при использовании mutex механизма (начиная с Oracle 10.2, аналог события library cache pin традиционного library cache механизма) во время компиляции child cursor –> см. подробное обсуждение, системные обзоры:
CURSOR_SHARING – в частности, событие оказывало значительное влияние на производительность (загрузку процессоров) при значении параметра CURSOR_SHARING = SIMILAR в присутствии гистограмм (автоматический сбор статистики по столбцам METHOD_OPT = FOR ALL COLUMNS SIZE AUTO) – OLTP DB Web приложения без использования связанных переменных в версии 10.2.
Возможные способы уменьшения ожиданий:
Отключение (исключение) гистограм распределения значений в столбцах таблиц в статистике объектов БД. Например, можно установить на уровне системы параметр METHOD_OPT = FOR ALL COLUMNS SIZE 1, который отключит исключит расчёт гистограм из процедур автоматического сбора статистики
Использование значения параметра CURSOR_SHARING=FORCE
Использование связанных переменных в приложении и значения по умолчанию параметра CURSOR_SHARING=EXACT
Ещё одним источником кратковременных всплесков ожиданий cursor: pin S wait on X / library cache lock могут быть DDL операции при наличии проблем ввода-вывода, например, при выполнении TRUNCATE партицированной таблицы можно наблюдать:
Library cache: mutex X
Cursor: pin S
kksfbc child completion
ожидание завершения процесса формирования/построения дочернего курсора, относится к фазе hard parse, часто наблюдается при большом количестве дочерних курсоров, сигнализируя о проблеме high version count
Наблюдаемый в Oracle 11g таймаут 50 мс
SGA: allocation forcing component growth
Process waiting on an immediate mode memory transfer with auto-tune SGA after a 4031 for MMAN to get the memory and post it.
Wait Time: 10 msec
Для уменьшения ожидания логично выяснить и устранить причины конкуренции за память в области shared pool SGA (ORA-4031):
- избыточную активность процесса автоматического перераспределения памяти ASMM
- использование и фрагментацию shared pool
- баги Oracle
Блокировки / Enqueue разного рода
Описание типов (V$LOCK.TYPE) и параметров блокировок (V$LOCK.ID1, V$LOCK.ID2) можно получить из обзора V$LOCK_TYPE
Удельный вес разных типов блокировок (с момента старта системы) можно получить из GV$ENQUEUE_STAT
Режимы, в которых блокировки удерживаются или ожидаются сессиями в Oracle (lock mode, V$LOCK.LMODE)
При описании глобальных блокировок (global deadlock detection) в разделе Global Wait-For-Graph(WFG) трейса LMD используются другие цифровые обозначения типов блокировок (GES enqueue lock mode)
10.3.6.1 Finding Locks and Lock Holders: как найти сессии, удерживающие/ожидающие блокировки
Типичные причины из документации
Также транзакционные блокировки на SYS.MLOG$ используются Oracle при конкурирующих операциях DML (dbms_mview.refresh) / DDL с Materialized View Log:
Дапм заголовка потенциально проблемного блока 4K:
Кроме того, эта блокировка используется для сериализации доступа к [заголовку] LOB-сегмента, например при интенсивных DML и недостаточной производительности ввода-вывода можно наблюдать:
Конкуренция происходит за LOB segment header:
В этом случае уменьшить ожидание можно как увеличив производительность ввода-вывода, так и изменив метод хранения LOB:
Инсерт 10000 копий файла в TEST таблицу в 10 сессиях
время выполнения с SECUREFILE
4minutes
время выполнения с BASIC
Sequence Cache enqueue, используется для доступа к последовательностям Oracle, ожидание может наблюдаться в кластерных конфигурациях (Oracle RAC), могут быть значительно уменьшены модификацией последовательностей с опциями CACHE NOORDER
Механизм возникновения, параметры, события, обзоры в Query result cache
| p2 | p3 | argument |
|---|---|---|
| tablespace_number | 1 | Local enqueue, to notify SMON to request some action for tablespace identified by tablespace id |
| tablespace_number | 2 | Global enqueue, to release space for releasing space in tablespace identified by tablespace id |
Latch contention
latch: library cache
latch: library cache pin
значение параметра P1RAW из V$SESSION_WAIT / V$SESSION:
Определение запрашиваемых объектов бд:
latch: library cache lock
latch: shared pool
Возможные причины из документации:
- SQL предложения не используются повторно
- Не используются связанные переменные
- Недостаточный размер кэша курсоров приложения (application cursor cache) [см. параметр SESSION_CACHED_CURSORS]
- Курсоры закрываются приложением [explicitly] после каждого выполнения
- Частые пересоединения со стороны приложения [logins and logoffs]
- Структура объектов, используемых курсорами модифицируется (например, командой truncate)
- Недостаточный размер shared pool
latch: cache buffers chains
Запрос к V$LATCH_CHILDREN
Объединённый запрос для определения сегментов с hot blocks по значению V$LATCH_CHILDREN.ADDR
Однако на практике внезапный рост кол-ва ожиданий:
часто сопровождается появлением/частым одновременным выполнением конкретных запросов:
, что является проблемой плана выполнения, либо конструкции запроса, и может/должен быть исправлен:
latch: object queue header operation
Кроме общей конкуренции за буферный кэш (большое кол-во чтений Gets), может сигнализировать об интенсивных операциях над CLOB переменными в PL/SQL
Например, при замедлении выполнения неких процедурных отчётных заданий (типа concurrent) в 11.2.0.3:
Цепочка ожиданий по ASH выглядит так:
gc cr multi block request
gc current multi block request
gc cr request | global cache cr request | gc cr block request
gc current block request
gc current block busy
DML (update, delete) с использованием FULL SCAN
buffer busy waits
Один из возможных случаев отражает диаграмма ожиданий из окружающей действительности:
gc buffer busy
gc buffer busy release
gc buffer busy acquire
Индикаторы невозможности немедленного получения гранта на доступ (grant access) к блокам данных локального buffer cache
- В случае, если блокирующий Global Cache запрос (GC request) открыт локальной сессией, ожидается gc buffer busy acquire
- Если же блокирующий GC запрос открыт сессией другого инстанса (remote instance), будет отражено ожидание gc buffer busy release
Заметный уровень ожиданий сигнализирует об одновременных попытках доступа (локально или через cluster interconnect с помощью механизма cache fusion) с получением соответсвующего уровня доступа (grant access) большим количеством пользовательских процессов к определённому набору блоков buffer cache, например:
По значению параметра P3 можно определить, что сессии конкурирую за заголовок UNDO сегмента (undo header):
Красивый пример исследования события gc buffer busy с использованием ASH можно прочитать на сайте Jeremy Schneider’а GC Buffer Busy Waits in RAC: Finding Hot Blocks
gc cr block lost / gc current block lost
gcs log flush sync
Процессы LMS, обслуживающий запросы Global Cache Service, ожидает записи логов локальным процессом LGWR:
gc cr block flush time
gc current block flush time
отражаются в AWR:
, в то время как блокирующий процесс LGWR выполняется с обычным приоритетом
DFS lock handle
ожидание глобальной блокировки (lock handle), обслуживаемой процессом Distributed Lock Manager (DLM). Слово DFS (Distributed File System) унаследовано со времён Oracle Parallel Server
Сетевые ожидания (Wait class: Network)
virtual circuit status
shared server idle wait
virtual circuit wait
комплексное ожидание, параметры:
Ожидания, наблюдаемые при параллельном выполнении запросов
PX Deq: Parse Reply
Начиная с версии 10g из частей целого запроса процесс-координатор (QC) готовит отдельные SQL для выполнения процессами PX Slaves. На этом событии QC ожидает выполнения разбора (parse & binds variable) частичных SQL параллельными серверами
PX Deq: Test for msg
Прочие ожидания
buffer exterminate
достаточно экзотическое событие ожижания, возникающего при динамическом изменении размера DB CACHE BUFFER
events in waitclass Other
resmgr:cpu quantum
В последнем случае, как правило, событие является индикатором активного выполнения других ресурсоёмких задач / запросов
Wait for stopper event to be increased
Статистики Oracle (statistics)
redo size
Объём генерируемых данных redo
Генерация redo включает в себя redo entries for lost write detection в объёме, например:
redo synch time
суммарное время ожиданий log file sync, csec
redo synch long waits
Индикатор медленной записи, в трейсе LGWR:
, либо задержек в процессе SCN broadcast acknowledge при использовании RAC, в трейсе LGWR или LMD|LMS:
gc cr block receive time
gc cr blocks received
gc current block receive time
cуммарное время ожидания клиентскими процессами получения через interconnect блоков бд в состоянии CURRENT
gc current blocks received
общее количество полученных блоков
Запрос для оценки средних времён получения блоков по Oracle Cluster мс момента запуска инстансов)
Статистика Row CR attempts показывает количество попыток выполнения updates, удовлетворяющих этим условиям [про update здесь пишется применительно к Oracle 9i, начиная с Oracle 10g механизм Row CR используется также для операций SELECT с доступом по индексу].
class slave wait
Неправильно классифицированное ожидание в версии 10.1.0.3 (непропатченный Oracle 10) ошибочно относится к классу ожиданий Other, в отчёте ADDM выглядит так
index scans kdiixs1
Popular Statistics with Database In-Memory
Коэффициенты Statspack / AWR
% Non-Parse CPU = 100*(1-(:prscpu/:tcpu))
(1-parse time CPU / CPU used by session)*100
доля процессорного времени, затраченная пользовательскими процессами (сессиями) на продуктивную работу, в отличие от подготовки к выполнению/ разбора запросов (SQL parsing)
Parse CPU to Parse Elapsd % = 100*:prscpu/:prsela
parse time CPU / parse time elapsed
Estd Interconnect traffic (KB)
формула из sprepins.sql
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об 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 оператора.
Читайте также: