Private Strand Flush Not Complete

Периодически в alert.log:

Fri Feb 11 13:46:28 2014
Thread 1 cannot allocate new log, sequence 152210
Private strand flush not complete
  Current log# 4 seq# 152209 mem# 0: +DATA/orcl/onlinelog/group_4.293.775538873
  Current log# 4 seq# 152209 mem# 1: +DATA/orcl/onlinelog/group_4.294.775538875
Beginning log switch checkpoint up to RBA [0x25292.2.10], SCN: 8485257222945
Thread 1 advanced to log sequence 152210 (LGWR switch)
...

— причина сообщений в этом случае некритичная, неновая, и хорошо описанная поддержкой — Alert Log Messages: Private Strand Flush Not Complete (Doc ID 372557.1), единственным минусом описания является не совсем полный список методов решений проблемы, а поскольку сообщения сопровождаются ожиданиями log file switch (private strand flush incomplete) проблема хорошо мониторится через ASH, например:

11.2.0.3.ORCL@SYS SQL> @ash_wait_tree "event='log file switch (private strand flush incomplete)'"

LVL BLOCKING_TREE  EVENT                                             WAITS_COUNT SESS_COUNT AVG_WAIT_TIME_MS
--- -------------- ------------------------------------------------- ----------- ---------- ----------------
  1 FOREGROUND     log file switch (private strand flush incomplete)          99         22              652 -- В ожидании этого события пользовательские сессии
  1 PX             log file switch (private strand flush incomplete)           5          4              537 -- и параллельные процессы
  2   (LGWR)       enq: CF - contention                                       29          1             1309 -- Коственно
  2   (LGWR)       control file parallel write                                28          1              303 -- и напрямую блокируемые операциями чтения
  2   (LGWR)       control file sequential read                               21          1               46 -- и записи контрольного файла,
  2   (LGWR)       log file parallel write                                    19          1              137 -- либо записью
  2   (LGWR)       log file sequential read                                    3          1               81 -- чтением лог файлов (в меньшей степени)
  3     (CKPT)     control file parallel write                                24          1             1275

— т.е. перемещение controlfile+redolog на быстрые дисковые группы с большой вероятностью решит проблему

Статистика ожидания за всю историю AWR также указывает на недостаточно быстрый I/O в качестве основной причины:

SQL> @ash_wait_tree_hist "event='log file switch (private strand flush incomplete)'"

LVL BLOCKING_TREE  EVENT                                             WAITS_COUNT SESS_COUNT AVG_WAIT_TIME_MS
--- -------------- ------------------------------------------------- ----------- ---------- ----------------
  1 FOREGROUND     log file switch (private strand flush incomplete)        2032        267              736
  1 PX             log file switch (private strand flush incomplete)         390        182              868
...
  2   (LGWR)       control file parallel write                               920          2              208
  2   (LGWR)       log file parallel write                                   602          2              682
  2   (LGWR)       control file sequential read                              395          2               68
  2   (LGWR)       log file single write                                     226          2              327
  2   (LGWR)       log file sequential read                                  195          2               51
  2   (LGWR)       enq: CF - contention                                       88          2             1172
  2   (LGWR)       On CPU / runqueue                                          25          1                0 -- *
...

*) здесь можно заметить, что дефицита процессорного ресурса LGWR не испытывает, что с одной стороны обусловлено невысокой нагрузкой / скоростью генерации логов в системе а, с другой стороны, использованием x86_64 процессоров с совершенно незначительной степенью Hyper-threading’а в отличие от SPARC T5, например, где уважаемым людям приходится на нагруженных системах фактически отключать Hyper-threading на выделенном для LGWR процессоре:

  • Provide LGWR exclusive access to shared H/W resources (need caution)
#Create Processor Set
# psrset -c 120-127
#Turn off all but one CPU in the processor set
# psradm -f 121-127
#Bind the lgwr to the processor set
# psrset -b 1 `pgrep -f ora_lgwr`
#Mark the CPU as non-interruptible
# psradm -i 120
Реклама

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s