Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31
Доброго дня всем!

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE	11.2.0.3.0	Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production


В каждой группе (из 4-х) 3 мембера. Можно ли где-то посмотреть статистику записи в каждого конкретного мембера ибо периодически начинаются проблемы с log_file_sync, а понять на каком конкретно файле не могу. Отключать по-одному не вариант, так как проблемы нерегулярны.
7 апр 14, 12:59    [15842831]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Надо смотреть log file parallel write для начала, который собственно отражает скорость записи, т.к. проблемы с log file sync далеко не всегда связаны со скоростью записи.
7 апр 14, 13:04    [15842872]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31
ну так log_file_parallel_write не покажет отдельно по файлам, а суммарно мне не очень интересно. Чую, что проблема в каком-то конкретном мембере.
7 апр 14, 15:16    [15844138]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
Paranoiac
Member

Откуда: Saint Petersburg
Сообщений: 389
он покажет стоит ли тебе вообще копать в дисковую подсистему.если уж у тебя в v$event_histogram avg по этому ожиданию больше 10,тогда стоит уже думать, а так насколько я знаю причиной могут быть и частые комиты и слишком большой log buffer,и даже как я читал, слишком большая нагрузка на проц,что приводит к торможению LGWR. А так вопрос хороший...тоже бы послушал на него ответ
7 апр 14, 18:06    [15845437]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Paranoiac
он покажет стоит ли тебе вообще копать в дисковую подсистему.если уж у тебя в v$event_histogram avg по этому ожиданию больше 10,тогда стоит уже думать, а так насколько я знаю причиной могут быть и частые комиты и слишком большой log buffer,и даже как я читал, слишком большая нагрузка на проц,что приводит к торможению LGWR. А так вопрос хороший...тоже бы послушал на него ответ
Да я бы сказал что для log file parallel write нормаьно где-то 1-2 ms.
8 апр 14, 05:43    [15846998]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31

Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log file sync 66,078 531,928 3203 61.24 Commit

проблемы на массиве, но вот на каком именно?
8 апр 14, 06:08    [15847007]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
COXATbIU

Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log file sync 66,078 531,928 3203 61.24 Commit

проблемы на массиве, но вот на каком именно?
покажи log file parallel write. И гистограмму по нему если есть.
8 апр 14, 07:18    [15847058]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Смысл в том, что log file parallel write содержит итоговое время записи на все группы. Поэтому если есть проблема с записью - это будет сразу видно. И если 3-х секундный log file sync действительно вызван проблемами на массиве, то со стороны OS это легко увидеть и там и надо смотреть.
8 апр 14, 07:38    [15847072]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31

Event Waits %Time-outs Total Wait Time (s) Avg wait (ms) Waits /txn % bg time
log file parallel write 465,189 0 1,407 3 1.05 5.12
8 апр 14, 07:46    [15847076]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31

log file parallel write 1 24574969
log file parallel write 2 5464546
log file parallel write 4 3357014
log file parallel write 8 1648480
log file parallel write 16 623123
log file parallel write 32 141313
log file parallel write 64 80666
log file parallel write 128 55595
log file parallel write 256 25830
log file parallel write 512 9188
log file parallel write 1024 3332
log file parallel write 2048 1996
log file parallel write 4096 591
log file parallel write 8192 32
log file parallel write 16384 6


справедливости ради надо сказать, что в процессе решения проблемы базу на другой хост перенесли
8 апр 14, 07:54    [15847079]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Да как бы 3 ms на запись это нельзя сказать что совсем много, особенно в сравнении с 3.2 сек на log file sync. Понятно, что есть group commit, при котором log file sync может быть существенно больше чем log file parallel write, но тут слишком огромная разница. Если проблема в массиве, то всплесками, которые в усредненном 3 ms не видны. Поэтому надо смотреть гистограмму для log file parallel write. В 11g AWR есть, строится на основе dba_hist_event_histogram. Там будет видно, нет ли всплесков тормозов. В идеале надо приложить весь AWR, а лучше два AWR, когда хорошо и когда плохо.
8 апр 14, 08:01    [15847093]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
А эта гистограмма за какой период?
8 апр 14, 08:02    [15847095]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
По-хорошему надо смотреть dba_hist_event_histogram, чтобы было видно какое распределение когда тормоза и какое когда нет. И еще, если это 11g то в трэйс lgwr пишутся ворнинги когда время записи падает. И он туда пишет время/ скорость записи. Поэтому просто можно открыть трэйс и посмотреть распределение ворнингов по времени. Сразу все ясно, если проблема именно в LGWR.
8 апр 14, 08:08    [15847118]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31
только что снова вылезло :-(

*** 2014-04-08 03:03:56.130
Warning: log write elapsed time 543ms, size 4744KB

*** 2014-04-08 03:04:25.040
Warning: log write elapsed time 529ms, size 82KB

*** 2014-04-08 03:07:32.720
Warning: log write elapsed time 548ms, size 32KB

*** 2014-04-08 03:07:34.894
Warning: log write elapsed time 926ms, size 14KB

*** 2014-04-08 10:08:13.084
Warning: log write elapsed time 3943ms, size 110KB

*** 2014-04-08 10:16:49.888
Warning: log write elapsed time 516789ms, size 2498KB

*** 2014-04-08 10:28:45.637
Warning: log write elapsed time 715708ms, size 34452KB

К сообщению приложен файл (bad.zip - 142Kb) cкачать
8 апр 14, 09:14    [15847283]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31
ну и за хороший период

К сообщению приложен файл (good.zip - 143Kb) cкачать
8 апр 14, 09:14    [15847284]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Ну вот. Это уже проблема. Периодически заклинивает и ждет по 500 - 700 секунд. В AWR это видно, два оджидания log file parallel write в диапазоне 4 мин - 1 час и 23 в диапазоне 4 sec to 2 min. Понятно что среднее время всего 2 ms, но в период заклина все ждут log file sync. Но проблема не только в redo, видно что другие дисковые операции также тормозят. В ту же гистограмму 4 sec to 2 min попадают db file parallel read, db file parallel write, db file scattered read, db file sequential read, direct path read, direct path read temp, direct path write, direct path write temp. Так что надо разбираться с железом, наверное на уровне OS смотреть, запускать автоматический сбор метрик если еще не настроено. Ну или этими временными индтервалами идти в логи OS / в логи массивов и смотреть что было.
8 апр 14, 09:36    [15847327]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31
т.е. будем считать, что с базой всё хорошо, а виноваты во всём системщики?
8 апр 14, 09:46    [15847348]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
COXATbIU
т.е. будем считать, что с базой всё хорошо, а виноваты во всём системщики?
Ну если у тебя на 10 минут останавливается ввод-вывод то явно проблема не в базе. Это не тот вариант когда например из-за возросшей нагрузки увеличилось время на log file parallel write на 50 - 200% или еще как. Тут тупо вместо 1 ms имеем 715708ms и все курят. Надо смотреть что там с массивом в это время. Мож репликацию криво настроили или еще что.
8 апр 14, 10:01    [15847397]     Ответить | Цитировать Сообщить модератору
 Re: Запись в redo  [new]
COXATbIU
Member

Откуда:
Сообщений: 31
ок, спасибо
8 апр 14, 11:56    [15848251]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить