Log file sync oracle это
This section provides detailed descriptions for those wait events of greatest interest.
Where appropriate, pointers are provided to further information elsewhere in Oracle Database documentation. For a complete listing of wait events, in alphabetical order, you can issue the following SQL statement:
30 января 2009 г.
C.3.15 buffer busy waits
Wait until a buffer becomes available.
There are four reasons that a session cannot pin a buffer in the buffer cache, and a separate wait event exists for each reason:
"buffer busy waits": A session cannot pin the buffer in the buffer cache because another session has the buffer pinned.
"read by other session": A session cannot pin the buffer in the buffer cache because another session is reading the buffer from disk.
"gc buffer busy acquire": A session cannot pin the buffer in the buffer cache because another session is reading the buffer from the cache of another instance.
"gc buffer busy release": A session cannot pin the buffer in the buffer cache because another session on another instance is taking the buffer from this cache into its own cache so it can pin it.
Prior to release 10.1, all four reasons were covered by "buffer busy waits." In release 10.1, the "gc buffer busy" wait event covered both the "gc buffer busy acquire" and "gc buffer busy release" wait events.
Wait Time: Normal wait time is 1 second. If the session was waiting for a buffer during the last wait, then the next wait will be 3 seconds.
Блог об администрировании баз данных Oracle.
This is my blog about Oracle Database Administration.
C.3.13 broadcast mesg queue transition
Processes enter "wait for broadcast mesg queue transition" when cleaning up a publisher channel handle to a RELIABLE broadcast channel. The publisher is responsible for moving the message to the free queue, but it cannot do so until the message is in the done queue. If the message is still not in the done queue, process enters this wait. This wait event will most likely appear when an Oracle process is about to exit normally, or when PMON cleans up a dead process.
Wait Time: Varies
publisher channel handle pointer
broadcast message pointer
A number indicating the function in KSR where the process is waiting
C.3.3 ASYNC Remote Write
Used to track the time (in centiseconds) for asynchronous streaming RFSWRITE operations. This includes stall reaps and streaming network submission time. This time is accumulated by TT nn (Redo Transport Slave) background processes.
Oracle Data Guard Concepts and Administration for more information about using RFS to manage standby redo logs.
C.3.6 BFILE closure
The session waits for an external large object (LOB) to close.
Wait Time: The total elapsed time for the close call
29 января 2009 г.
C.3.1 alter system set dispatcher
A session has issued a statement ALTER SYSTEM SET DISPATCHER = string and is waiting for the dispatchers to get started.
Wait Time: The session will wait 1 / 100 of a second and verify if the new dispatchers have started, else the session will wait again
Number of times that the session has waited 1 / 100 of a second
C.3.5 BFILE check if open
The session waits for an external large object (LOB) to open.
Wait Time: The total elapsed time for the isopen call
C.3.10 BFILE internal seek
The session waits for a positioning call within the external large object (LOB) to complete.
Wait Time: The total elapsed time for the seek to complete
21 января 2009 г.
Количество ожиданий в Oracle 10g (Number of Wait Events in Oracle 10g)
Сегодня читала про ожидания в Oracle 10g и наткнулась на эту презентацию, где увидела этот график:
Я знала, что в Oracle 10g появилось очень много новых событий ожидания (wait events) но даже не думала, что настоолько много! Первым делом решила проверить это и посчитала кол-во событий ожидания в версиях 9i и 10g:
В Oracle 9.2.0.8:В Oracle 10.2.0.4:В 10g кол-во ожиданий увеличилось больше чем вдвое: было 406, стало 889! Здесь пишут, что события ожидания в Oracle 10g стали более "descriptive", то есть более описательными, более детальными.
Wait event names in Oracle 10g are more descriptive in the areas of latches, enqueues, and buffer busy waits.
Здесь я писала об одном из таких примеров, когда из ожидания buffer busy waits "родилось и отколось" ожидание read by other session .
"buffer busy waits" и "read by other session"
В Oracle 10g появились ожидания read by other session , которые являются частным и "отколовшимся" случаем ожиданий buffer busy waits . Вот что пишут в документации Oracle о них:
This event ['read by other session'] occurs when a session requests a buffer that is currently being read into the buffer cache by another session . Prior to release 10.1, waits for this event ['read by other session'] were grouped with the other reasons for waiting for buffers under the 'buffer busy wait' event.
Наталья Гусева, одна из суперских ДБА, которых я знаю, подсказала, что read by other session - это тот же buffer busy waits с reason code = 130 .
Reason code = 130 : Block is being read by another session, and no other suitable block image was found, so we wait until the read is completed. This may also occur after a buffer cache assumed deadlock. The kernel can't get a buffer in a certain amount of time and assumes a deadlock. Therefore it will read the CR version of the block.
Полный список и описание reason code можно почитать здесь, правда там говорится применительно версии 9i.
Ожидания read by other session возникают, когда какая-то сессия пытается прочитать блок из диска в буферный кеш, в тот момент когда другая сессия уже читает ее из диска в буферный кеш.
В моей практике, причины таких внезапных ожиданий в продуктивных базах были - неэффективные планы выполнений, когда планы "сбиваются" по каким-то причинам.
В тестовых базах такие ожидания появлялись, когда кто-то забывал создать индексы после переноса схемы.
Столкнулись с ситуацией повышенного log file sync wait.
Конечно написанное приложение далеко от идеала, и в БД очень много коммитов. Но раньше такой ситуации по ожиданиям не возникало, а код остался нетронутым.
Деградации в производительности дискового хранилища и сети не были найдены, всё железо стабильно продолжало работать. В алертлоге ничего путного тоже нет, только:
«Thu Mar 30 15:20:19 2017
Thread 1 cannot allocate new log, sequence 4824
Private strand flush not complete»
Который в принципе можно игнорировать.
Ввиду того, что Standard edition, нужно было поставить statspack, и к сожалению состояние работы системы до возрастания ожидания не мониторилось.
Посмотрим среднее значение ожидания:
Оно же у нас и в «Top 5 Timed Events»
Event | Waits | Time (s) | Avg wait (ms) |
log file sync | 12,625,283 | 172,525 | 14 |
Сравним со средним значение, что тратится на запись на диск:
Event | Waits | Time (s) | Avg wait (ms) |
log file parallel write | 16,518,450 | 9,700 | 1 |
Окей, 1 мс мы записываем, а остальные 14 мы что делаем? Обычно основа ожидания для «log file sync» это долгая запись на диск, а здесь всё записалось довольно быстро — в пределах нормы.
Вывод: Это не проблемы ввода/вывода.
*** 2017-03-29 03:19:38.301
Log file sync switching to polling
Current scheduling delay is 1 usec
Current approximate redo synch write rate is 0 per sec»
Вот здесь самое интересное.
Начиная с 11gR2 LGWR может работать в двух режимах — «Post/wait» и «Polling».
Post/wait — традиционный метод, когда log writer явно оповещает все ждущие процессы, что коммит завершён.
Преимущества режима post/wait в том, что сессии практически сразу узнают, когда redo был сброшен на диск.
Polling — Foreground процессы (те которые обслуживают пользовательские сессии) засыпают на «некоторое время», а затем опрашивают, был ли завершён коммит.
Преимущества этого метода заключается в освобождении LGWR от оповещения множества ждущих завершения коммита процессов, тем самым снимая высокое использование CPU для LGWR.
Изначально, LGWR использует post/wait и согласно внутреннему алгоритму оценивает, будет ли лучше использовать pooling. Под высокой нагрузкой polling может выполняться лучше потому, что выполнение post/wait обычно плохо масштабируется. Если нагрузка на систему низкая, тогда post/wait выполняется лучше и обеспечивает лучшее время отклика, чем при использовании polling. Oracle полагается на внутреннюю статистику для определения метода, который должен использоваться. Ввиду того, что переключение между «Post/wait» и «Polling» влечёт за собой накладные расходы, существует защитный механизм, который гарантирует, что переключения не будут происходить слишком часто.
Все переключения записываются в файл трассировки LGWR с временной меткой и строкой «Log file sync switching to …».
Можно посмотреть статистику по pooling в v$sysstat:
SQL> select name,value from v$sysstat where name in ('redo synch poll writes','redo synch polls');
NAME | VALUE |
redo synch poll writes | 76138986 |
redo synch polls | 71409810 |
Мы видим, что использовался polling. Эта статистика также отражается в отчётах statspack и AWR.
В подавляющем большинстве случаев адаптивная синхронизация лог файла улучшает общую производительность (в части синхронизации лог файла).
Начиная с 11gR2 был введён параметр «_use_adaptive_log_file_sync», который контролирует будет ли включено адаптивное автоматическое переключение между post/wait и polling. В 11.2.0.1 и 11.2.0.2 значение по умолчанию у этого параметра = «false». С 11.2.0.3, его значение «true».
После выполнения:
ALTER SYSTEM SET "_use_adaptive_log_file_sync"= FALSE scope=both;
посмотрим снова в отчёт statspack’а
Event | Waits | Time (s) | Avg wait (ms) |
log file sync | 132,558 | 54 | 0 |
В 11:55 было изменено значение параметра, визуально выглядит так:
Как уже говорилось, при polling — Foreground процессы засыпают на «некоторое время», и это «некоторое время» вероятно оказывается довольно длительным, в следствии чего значительно растёт ожидание log file sync.
Эта статья посвящена анализу некоторых результатов общей оценки производительности системы. По мотивам интересной публикации на сайте Тома Кайта от 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 были сделаны изменения для повышения производительности, чтобы это делалось "быстрее".
C.3.4 BFILE check if exists
The session waits to check if an external large object (LOB) exists.
Wait Time: The total elapsed time for the exists call
C.3.1 alter system set dispatcher
A session has issued a statement ALTER SYSTEM SET DISPATCHER = string and is waiting for the dispatchers to get started.
Wait Time: The session will wait 1 / 100 of a second and verify if the new dispatchers have started, else the session will wait again
Number of times that the session has waited 1 / 100 of a second
C.3.9 BFILE get path object
The session is waiting on a call to find or generate the external path name of an external large object (LOB).
Wait Time: The total elapsed time for make external path to complete
C.3.11 BFILE open
The session waits for an external large object (LOB) to open.
Wait Time: The total elapsed time for the isopen call
C.3.2 ARCH Remote Write
Used to track the time (in centiseconds) that ARC n background processes spend blocked waiting for network write operations to complete.
Размер redo блоков (Redo log block size)
Сегодня хотела бы написать об размере блоков redo log buffer'а. Все мы знаем, о размере блока базы данных, который устанавливается параметром db_block_size , и который задает размер блоков в файлах данных и размер буфферов в буфферном кеше.
А какая структура у redo log buffer'а? Понятно, что она - цикличная , запись в него выполняется последовательно , не то что в буфферном кеше или в файлах данных, когда чтение и запись выполняется вразброс .
Мне всегда казалось, что если она цикличная и запись в него последовательная, то и думать тут не о чем: значит у него и структура памяти какая-то неразрывная, что ли.
Сегодня, когда пыталась понять смысл латча redo allocation , не могла понять, зачем вообще нужен этот латч. Что тут выделять-то? Память под redo log buffer уже выделена же в SGA. У Стива Адамса прочитала следующее:
The redo allocation latch must be taken to allocate space in the log buffer. This latch protects the SGA variables that are used to track which log buffer blocks are used and free .
Вот так я узнала, что redo log buffer состоит из блоков одинакового размера, а его цикличность - это структура данных, а в памяти они могут находится вразброс.
А теперь, собственно, про размер блоков redo log buffer'а. Стив Адамс пишет здесь:
Although the size of redo entries is measured in bytes, LGWR writes the redo to the log files on disk in blocks. The size of redo log blocks is fixed in the Oracle source code and is operating system specific.
Перевод: Хотя размер redo измеряется в байтах , LGWR пишет red в лог файлы на дисках в блоках . Размер redo блоков зашит в код ядра Oracle и зависит от операционной системы.
То есть размер redo блоков невозможно изменить параметром инициализации как размер блоков данных db_block_size.
Ниже, он приводит размеры redo блоков в разных ОС:
А так же, фактический размер redo блоков можно узнать следующим способом:
C.3.14 broadcast mesg recovery queue transition
Processes enter "wait for broadcast mesg recovery queue transition" when cleaning up a publisher channel handle to a RELIABLE broadcast channel. The broadcasted message is in the recovery queue of another channel handle (for example, ch2). Process enters this wait, if the message is yet to be removed from the recovery queue of the ch2 channel handle. This wait event will most likely appear when an Oracle process is about to exit normally, or when PMON cleans up a dead process.
Wait Time: Varies
Publisher channel handle pointer
Broadcast message pointer
A number indicating the function in KSR where the process is waiting
28 января 2009 г.
C.3.8 BFILE get name object
The session waits on a call to find or generate the external name of a external large object.
Wait Time: The total elapsed time for make external file name to complete
C.3.7 BFILE get length
The session waits on a call to check the size of an external large object (LOB).
Wait Time: The total elapsed time for the call to check the LOB size
Ожидания log file sync
Сессия, ожидает события log file sync , в то время как LGWR сбрасывает redo-информации из redo log buffer в redo log файлы.
Подробней: скажем какая-то сессия апдейтит какую-то таблицу. То есть выполняя апдейт, она генерит redo-информацию и записывает их в redo log buffer. В тот самый момент, когда сессия пишет redo-информацию в redo log buffer, LGWR сидит и ждет. Как только сессия коммитит транзакцию, LGWR у нужно сбросить redo-информацию из redo log buffer в redo log файлы и выдать сессии подверждение, что транзакция закоммичена. И пока LGWR сбрасывает redo-информацию из redo log buffer в redo log файлы, сессия ожидает события log file sync .
Мой коллега говорит, что это ожидание возникает только при commit'е сессии. Том Кайт тоже здесь пишет, что это ожидание возникает только при коммите:
log file sync - это клиентское ожидание события. Именно этого события ваши клиенты ждут, когда говорят "commit". Это ожидание, пока процесс LGWR фактически запишет их данные повторного выполнения на диск и фиксация транзакции будет завершена. Можно "настроить" этот процесс, ускорив работу процесса lgwr (отказавшись от использования raid 5, например) и фиксируя транзакции реже, генерируя меньше данных повторного выполнения (множественные изменения генерируют меньше данных повторного выполнения, чем построчные)
А как же сброс redo-информации из redo log buffer в redo-файлы по истечению 3 секунд, при заполнении redo log buffer'а на 1/3 и тд?
Если кто-то знает точный ответ на этот вопрос, напишите здесь.
Автор: Oracle DBA на 5:45 AM
4 коммент.:
имхо, поскольку свой scn транзакция получает именно в момент коммита, то его запись в редолог и приводит к соотвествующему ожиданию.
да, вы правы. Кстати, DBWR тоже ожидает события log file sync перед записью грязных блоков. Он просит LGWR сбросить реду-записи, защищающие грязные блоки, которые он хочет сбросить на диск.
Стив Адамс об этом пишет здесь: www.ixora.com.au/tips/mystery.doc. "Meanwhile, DBWR enters a log file sync wait and waits on its semaphore. This acts as a signal to the operating system to not schedule DBWR to run on a CPU until further notice, or until the wait times out. When LGWR has done its work, it posts DBWR’s semaphore to indicate to the operating system that DBWR can now be scheduled to run."
6:52 AM забава комментирует. Этот комментарий был удален администратором блога. 5:46 AM
Блог об администрировании баз данных Oracle.
This is my blog about Oracle Database Administration.
28 января 2009 г.
C.3.12 BFILE read
The session waits for a read from a external large object (LOB) to complete.
Wait Time: The total elapsed time for the read to complete
Ожидания log file sync
Сессия, ожидает события log file sync , в то время как LGWR сбрасывает redo-информации из redo log buffer в redo log файлы.
Подробней: скажем какая-то сессия апдейтит какую-то таблицу. То есть выполняя апдейт, она генерит redo-информацию и записывает их в redo log buffer. В тот самый момент, когда сессия пишет redo-информацию в redo log buffer, LGWR сидит и ждет. Как только сессия коммитит транзакцию, LGWR у нужно сбросить redo-информацию из redo log buffer в redo log файлы и выдать сессии подверждение, что транзакция закоммичена. И пока LGWR сбрасывает redo-информацию из redo log buffer в redo log файлы, сессия ожидает события log file sync .
Мой коллега говорит, что это ожидание возникает только при commit'е сессии. Том Кайт тоже здесь пишет, что это ожидание возникает только при коммите:
log file sync - это клиентское ожидание события. Именно этого события ваши клиенты ждут, когда говорят "commit". Это ожидание, пока процесс LGWR фактически запишет их данные повторного выполнения на диск и фиксация транзакции будет завершена. Можно "настроить" этот процесс, ускорив работу процесса lgwr (отказавшись от использования raid 5, например) и фиксируя транзакции реже, генерируя меньше данных повторного выполнения (множественные изменения генерируют меньше данных повторного выполнения, чем построчные)
А как же сброс redo-информации из redo log buffer в redo-файлы по истечению 3 секунд, при заполнении redo log buffer'а на 1/3 и тд?
Если кто-то знает точный ответ на этот вопрос, напишите здесь.
Читайте также: