Month: Февраль 2023

Log file sync switching to post/wait. eng.

Krotov KonstantinОставьте комментарий

DB version: Oracle 19.9 x86.

In this note, I will visually demonstrate how the transition of lgwr from poll->post to post/wait mode can look like.

Investigate time when it happened by using trace file of lgwr process:

*** 2023-02-16T12:45:09.010167+06:00 
Log file sync switching to post/wait 
Current approximate redo synch write rate is 10286 per sec
Fig.1
Fig.2

Figure 1 shows that the transition of lgwr from poll->post to post/wait mode led to a doubling of the log file sync wait time, from 250 microseconds to 500 microseconds.
Additionally, the number of redo blocks written in 128KB doubled. Although not visible in the graphs, there is also a decrease in the number of redo blocks written that are much smaller than 128KB (4, 8, 16, 32KB, etc).

Figure 2 shows how the number of log file parallel write waits (oracledb_event_p3_log_file_parallel_write_p2) has changed.
The number of waits has decreased by half, but the duration of a single log file parallel write wait (oracledb_event_p2_log_file_parallel_write_p2) has increased by an average of 50%, from 50 microseconds to 75 microseconds.

It looks like some sort of ferry mode where fewer operations are performed with larger block sizes, resulting in a 2x reduction in response time. This behavior is subject to change according to the algorithm and database parameters associated with the adaptive operation of LGWR.

You can read more here:

  1. Adaptive Switching Between Log Write Methods can Cause ‘log file sync’ Waits (Doc ID 1462942.1)
  2. ADAPTIVE LOG FILE SYNC: ORACLE, PLEASE DON’T DO THAT AGAIN

Actually, the solution is: ALTER SYSTEM SET «_use_adaptive_log_file_sync» = FALSE;

Log file sync switching to post/wait

Krotov KonstantinОставьте комментарий

Версия: Oracle 19.9

В данной заметке показано наглядно, как может выглядеть переход lgwr от poll->post к режиму post/wait.

Смотрим в трейс файл процесса lgwr, находим там:

*** 2023-02-16T12:45:09.010167+06:00

Log file sync switching to post/wait

Current approximate redo synch write rate is 10286 per sec

Идём в графану и смотрим визуализацию этого события:

Рис1.

Рис2.

На рисунке 1 показано, что переход lgwr от poll->post к режиму post/wait привёл к увеличению ожидания log file sync в 2 раза, с 250мксек до 500мксек, также, увеличилось количество записи редо блоком в 128KB в два раза. На графики этого не видно, но также имеется снижение количества записи редо блоком гораздо меньшим чем 128KB(4,8,16,32KB etc).

На рисунке 2 показано, как изменилось количество ожиданий log file parallel write(oracledb_event_p3_log_file_parallel_write_p2). Количество ожиданий уменьшилось в два раза, в тоже время длительность одного ожидания log file parallel write(oracledb_event_p2_log_file_parallel_write_p2) увеличилось, в среднем на 50%, с 50мксек до 75мксек.

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

Подробнее можно почитать тут:

  1. Adaptive Switching Between Log Write Methods can Cause ‘log file sync’ Waits (Doc ID 1462942.1)
  2. ADAPTIVE LOG FILE SYNC: ORACLE, PLEASE DON’T DO THAT AGAIN

Собственно, решение такое: ALTER SYSTEM SET «_use_adaptive_log_file_sync» = FALSE;

Оптимизация работы rman catalog.

Krotov KonstantinОставьте комментарий

В больших база данных, размеры которых идут на десятки, а то и сотни ТБ, и в зависимости от политики резервного копирования, могут образоваться сотни тысяч backup piece. При таком количестве backup piece задачи по удалению из rman каталога старых бэкапов, особенно инициированные не в ручную, а выполняемые по регламенту из какого либо софта MML , могут не успеть за отведённое время удалить необходимый перечень записей из контрольного файла и rman catalog. Это приведёт к накоплению устаревших записей о бэкапах как в контрольном файле, так и в rman каталоге.

Создание данных индексов позволят ускорить удаление записей из rman каталога в 4 раза:

create index BDF_DBINC_KEY_IX1 on BDF(Dbinc_Key,CKP_SCN) 
create index BRL_DBINC_KEY_IX1 on BRL(Dbinc_Key,Low_Scn)
create index CDF_DBINC_KEY_IX1 on CDF(Dbinc_Key,Ckp_Scn)
create index ROUT_KEY_IX1 on ROUT(DB_KEY,Site_Key,Rout_Skey)
create index bp_ix1 on bp(DB_KEY,handle);

Так же, если в бд, откуда делаются бэкапы, при выполнении задач по удалению старых записей о бэкапах, присутствует ожидание  “recovery area: computing obsolete files”, то вам следует выполнить/проверить реакцию бд на  ALTER SYSTEM SET db_recovery_file_dest=» SCOPE=BOTH;  Если конечно, оно, db_recovery_file_dest, вам ненужно.