Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: ожидание log file parallel write и переключения редо логов  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
busy
~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 12,638 84.69
log file parallel write 176,586 702 4.70
log file sync 165,915 664 4.45


Пару слов по ожиданиям. Я присоединюсь к мнению Наты(DBA), что ожидания не выглядят критично, все таки 85% времени база шуршит процессорами ( что несколько настораживает, в принципе возможно злоупотребление индексным доступом в пакетных приложениях и соответственно чрезмерный LIO, попробуйте посмотреть запросы лидеры по IO в "одной процедуре").

Связка log file parallel write, log file sync в лидирующих ожиданиях похоже показывает что данные из буфера журнала в журнальные файлы начинают записываться только при фиксации ( откате) транзакции ( LGWR пишет и ждет OS на log file parallel write, пользовательские сессии делают COMMIT и ждут на log file sync пока LGWR сбросит в журнал ).
Информация из буфера сбрасываются каждые 3 секунды, по commit/rollback, по достижении _IO_LOG_SIZE ( 1/3 буфера по умолчанию), по превышении 1 MB.
У Вас похоже получается, что транзакции достаточно длинные и заполняют близко к 1/3 журнального буфера, который у Вас достаточно большой 2 MB и вся это информация начинает сбрасываться только при фиксации транзакции.
Соответственно имеет смысл поиграться с уменьшением _IO_LOG_SIZE что бы сброс redo начинался раньше и равномернее распределялся по времени, что бы пользовательские процессы меньше ждали на log file sync. Установка _IO_LOG_SIZE неоднократно обсуждалась на форуме, поищите.


log file parallel write ожидание LGWR и может быть вызвано как медленной работой дисковой подсистемы, тут надо смотреть среднее время ожидания, так и большим количеством генерируемой информации redo, тут надо смотреть количество этих ожиданий и количество генерируемой информации, ну или сочетанием этих факторов.

У вас среднее время ожидания ( если я правильно разделил :) ), где то 4 ms, что конечно не очень хорошо , но вроде бы и не сильно критично, в принципе Oracle критичной цифрой называет 10 ms, хотя техника конечно развивается, и я, например, сейчас обычно вижу средние времена этого ожидания 1ms и меньше. Т.е. на мой взгляд, проблему надо скорее искать в большом объеме генерируемой redo информации, т.е. в приложении, а не в дисковой подсистеме и расположении redo-логов, райдах и.т.д., ускорив дисковый ввод/вывод вы скорее только сгладите проблему а не решите.

P.S. Слово "проблема" употребляется выше в условном смысле, поскольку проблемы для бизнеса, как я понял, не наблюдается.
24 окт 06, 11:11    [3300415]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
DВА
Member

Откуда:
Сообщений: 5439
_log_io_size
:)
24 окт 06, 12:42    [3301190]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
BW
Member

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

Сейчас размер LOG_BUFFER как раз 2м, редо логи увеличены до 200м, но утром ситуация с check point not complete повторилась. Увеличивать пока не буду, если днём будет возникать подобная ситуация, то таки увеличу и буду переключать вручную, как вы говорите. С массивами буду думать.


Не надо никакого ручного переключения, есть параметер ARCHIVE_LAG_TARGET.

С уважением,
bw.
24 окт 06, 13:04    [3301421]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
DВА
_log_io_size
:)

спасибо
24 окт 06, 13:13    [3301504]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
DВА
Member

Откуда:
Сообщений: 5439
BW
busy

Сейчас размер LOG_BUFFER как раз 2м, редо логи увеличены до 200м, но утром ситуация с check point not complete повторилась. Увеличивать пока не буду, если днём будет возникать подобная ситуация, то таки увеличу и буду переключать вручную, как вы говорите. С массивами буду думать.


Не надо никакого ручного переключения, есть параметер ARCHIVE_LAG_TARGET.

С уважением,
bw.

увеличим логи, установим параметр ... и будем ждать checkpoint not complete :)

разве что динамически менять значение взависимости от нагрузки
24 окт 06, 13:13    [3301518]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
busy
Member

Откуда: Москва
Сообщений: 120
Я и ёжик
DВА
_log_io_size
:)

спасибо


спасибо :)
24 окт 06, 13:21    [3301604]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
HX
Member

Откуда: Moscow
Сообщений: 2454
Oracle Wait Interface Очень полезное чтиво на эту и не только эту тему
24 окт 06, 13:32    [3301727]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
BW
Member

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

Прошу прощения, взглючнула что-то на ночь глядя. Не тот файлик открыла, за два дня вообще по времени.
Вот этот часововой:

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 1,405 91.25
log file parallel write 14,737 51 3.30
log file sync 13,651 46 3.01
control file parallel write 1,266 26 1.68
db file sequential read 2,446 7 .44
-------------------------------------------------------------


А в момент выполнения Процедуры?

С уважением,
bw.
24 окт 06, 13:47    [3301874]     Ответить | Цитировать Сообщить модератору
 Re: ожидание log file parallel write и переключения редо логов  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
busy
... С массивами буду думать.

Я ещё раз перечитал описание вашей проблемы и у меня возникли следующие соображения:
У вас высокая конкуренция за диск реду логов, так как он один (логический) и на нём лежит как активный, так и архивируемый в данный момент логи.
Если вспомнить, что в активный журнал производится линейно запись, а процес ARCn линейно вычитывает архивируемый журнал, то избежав ненужной "болтанки" головками диска мы можем значительно улучшить производительность. Вам бы, конечно 10g + ASM, но за неимением оного можно ручками всё настроить.
  • Разбираем оба ваших RAID5, получаем 6 дисков.
  • Два диска у вас будут под архивлоги.(LOG_ARCHIVE_DEST_n)
  • На остальных 4-х создаём разделы на внешних (быстрых) цилиндрах для реду файлов (гиговые?).
  • Остальное дисковое пространство вы сможете использовать для хранения бакапов (т.к. слишком жирно будет полностью отдать 4 диска просто под реду).
  • Реду организуете так, чтобы у вас было 4 группы по два мембера в каждой. Чётные группы на одной паре дисков, нечётные - на другой. Таким образом после переключения логов у вас одна пара дисков будет полностью предоставлена записи, а другая - процессу(-ам) ARC.

    P.S.
    1. В вашей сегодняшней конфигурации, когда все реду лежат на одном диске, увеличение размеров файлов реду не принесет облегчения принципиально.
    2. Не используйте скрытых параметров без острой необходимости и рекомендации со стороны суппорта.
    3. Используйте параметер ARCHIVE_LAG_TARGET (спасибо BW за напоминание!)
    4. То, что вы сейчас делаете называется pro-active tuning. Это лучше сделать сейчас, потом придётся делать это же, но уже в режима аврала.
  • 24 окт 06, 21:19    [3304950]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    MacDuck
    Member

    Откуда: Москва-Подольск
    Сообщений: 6387
    Anton Demidov

    1. В вашей сегодняшней конфигурации, когда все реду лежат на одном диске, увеличение размеров файлов реду не принесет облегчения принципиально.


    Обоснуй.:-)
    25 окт 06, 01:15    [3305303]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    busy
    Member

    Откуда: Москва
    Сообщений: 120
    MacDuck
    Anton Demidov

    1. В вашей сегодняшней конфигурации, когда все реду лежат на одном диске, увеличение размеров файлов реду не принесет облегчения принципиально.


    Обоснуй.:-)


    Я увеличила редо файлы со 100м до 200м - спасение не пришло :)
    И мне кажется это неверное решение.
    Из форума стало ясно:
    1. Нужно поянять почему эта процедура скидывает столько редо.
    2. Если нельзя поправить код, то нужно перелопатить массив.
    Вот в общем-то и всё.
    25 окт 06, 08:48    [3305569]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    busy
    Member

    Откуда: Москва
    Сообщений: 120
    HX
    Oracle Wait Interface Очень полезное чтиво на эту и не только эту тему


    Спасибо. Отличная книга :)
    25 окт 06, 08:49    [3305572]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    BW
    Member

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

    Я увеличила редо файлы со 100м до 200м - спасение не пришло :)
    И мне кажется это неверное решение.
    Из форума стало ясно:
    1. Нужно поянять почему эта процедура скидывает столько редо.


    Вы так и не показали отчет Statspack за время работы процедуры.
    И тогда можно будет судить об проблемах с генерацией редологов.

    busy

    2. Если нельзя поправить код, то нужно перелопатить массив.
    Вот в общем-то и всё.

    RAID5 на трех дисках - это худший вариант. Минимум четыре диска, ИМХО.
    Возможно у Вас проблемы в сети хранения данных? Кроме Ораклового сервера еще что-нибудь подключено? Подключение сервера с Ораклом напрямую в стойку или через свитч?

    С уважением,
    bw.
    25 окт 06, 13:44    [3308165]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    HX
    Member

    Откуда: Moscow
    Сообщений: 2454
    BW
    Минимум четыре диска, ИМХО.

    Ширакно живете. Не все так могут себе позволить под одни redo 4 диска.
    25 окт 06, 14:31    [3308711]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    BW
    Member

    Откуда:
    Сообщений: 727
    HX
    BW
    Минимум четыре диска, ИМХО.

    Ширакно живете. Не все так могут себе позволить под одни redo 4 диска.

    Во-первых, где сказано про redo?!
    Во-вторых, шикарно - это иметь выносное хранилище. ;-)


    С уважением,
    bw.
    25 окт 06, 14:48    [3308895]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    HX
    Member

    Откуда: Moscow
    Сообщений: 2454
    BW
    [quot HX]
    Во-первых, где сказано про redo?!


    Тогда ладно. :-)..
    25 окт 06, 14:52    [3308943]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Anton Demidov
    Member

    Откуда: Atlanta, GA
    Сообщений: 1187
    MacDuck
    Anton Demidov

    1. В вашей сегодняшней конфигурации, когда все реду лежат на одном диске, увеличение размеров файлов реду не принесет облегчения принципиально.


    Обоснуй.:-)

    "Элементарно, Ватсон" (с)
    Смысл увеличения размера реду файла в том, что бы дать дополнительное время процесу ARC для архивирования лога, с которого только переключились. Дополнительное время ожидается по причине прекращения записи на этот диск (LGWR i/o = 0). В нашем случае диск один для всех групп. Переключение группы не освобождает его от io и ARC-у приходится конкурировать с LGWR за io на этот диск. Пока нагрузка маленькая (день) - производительности дисков хватает и проблема не проявляется. При запуске того тяжелого задания начинает генерится много реду и диск перестаёт справляться с нагрузкой (LGWR + ARC).

    PS
    Применеие RAID5 для хранения реду было принципиальной ошибкой.
    25 окт 06, 18:47    [3310852]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Biz©
    Member

    Откуда: Snezhinsk
    Сообщений: 5687
    во блин ... а я наивный думал что смысл этого достаточного общего решения в снижении частоты переключений логов и, соотв-но, чекпоинтов ...
    26 окт 06, 00:19    [3311629]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Anton Demidov
    Member

    Откуда: Atlanta, GA
    Сообщений: 1187
    Biz©
    во блин ... а я наивный думал что смысл этого достаточного общего решения в снижении частоты переключений логов и, соотв-но, чекпоинтов ...
    и были в общем правы, но именно в данном конкретном случае мы видим в top 5 wait events ожидания LGWR-a, a не DBWR-а. Именно в данном конкретном случае применили RAID-5 для реду и свалили их всех в одну кучу.
    26 окт 06, 00:49    [3311663]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Biz©
    Member

    Откуда: Snezhinsk
    Сообщений: 5687
    busy
    Checkpoint not completed - вызывает пока только одна процедура. Вчера увеличила в два раза размер редо логов, теперь 200м, но ситуация не изменилась.

    а может даже ухудшиться ... это от среднестатистического количества грязных блоков на "душу" редулога во время той процедуры ... тут мона было попробовать и наоборот уменьшить размер редулога ...
    но имхо предпочтительнее было бы сначала увеличение количество групп и при исчезновении ошибки, анализировать активность dbwr на предмет чего ж он так тупит и долго держит редулог ...
    26 окт 06, 08:23    [3311957]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Biz©
    Member

    Откуда: Snezhinsk
    Сообщений: 5687
    Я и ёжик
    Пару слов по ожиданиям. Я присоединюсь к мнению Наты(DBA), что ожидания не выглядят критично, все таки 85% времени база шуршит процессорами ( что несколько настораживает, в принципе возможно злоупотребление индексным доступом в пакетных приложениях и соответственно чрезмерный LIO, попробуйте посмотреть запросы лидеры по IO в "одной процедуре").

    Связка log file parallel write, log file sync в лидирующих ожиданиях похоже показывает что данные из буфера журнала в журнальные файлы начинают записываться только при фиксации ( откате) транзакции ( LGWR пишет и ждет OS на log file parallel write, пользовательские сессии делают COMMIT и ждут на log file sync пока LGWR сбросит в журнал ).
    Информация из буфера сбрасываются каждые 3 секунды, по commit/rollback, по достижении _IO_LOG_SIZE ( 1/3 буфера по умолчанию), по превышении 1 MB.
    У Вас похоже получается, что транзакции достаточно длинные и заполняют близко к 1/3 журнального буфера, который у Вас достаточно большой 2 MB и вся это информация начинает сбрасываться только при фиксации транзакции.
    Соответственно имеет смысл поиграться с уменьшением _IO_LOG_SIZE что бы сброс redo начинался раньше и равномернее распределялся по времени, что бы пользовательские процессы меньше ждали на log file sync. Установка _IO_LOG_SIZE неоднократно обсуждалась на форуме, поищите.


    log file parallel write ожидание LGWR и может быть вызвано как медленной работой дисковой подсистемы, тут надо смотреть среднее время ожидания, так и большим количеством генерируемой информации redo, тут надо смотреть количество этих ожиданий и количество генерируемой информации, ну или сочетанием этих факторов.

    У вас среднее время ожидания ( если я правильно разделил :) ), где то 4 ms, что конечно не очень хорошо , но вроде бы и не сильно критично, в принципе Oracle критичной цифрой называет 10 ms, хотя техника конечно развивается, и я, например, сейчас обычно вижу средние времена этого ожидания 1ms и меньше. Т.е. на мой взгляд, проблему надо скорее искать в большом объеме генерируемой redo информации, т.е. в приложении, а не в дисковой подсистеме и расположении redo-логов, райдах и.т.д., ускорив дисковый ввод/вывод вы скорее только сгладите проблему а не решите.

    P.S. Слово "проблема" употребляется выше в условном смысле, поскольку проблемы для бизнеса, как я понял, не наблюдается.

    в целом трудно не согласиться ... но гложат сомнения насчёт мысли о длительных транзакциях ... может наоборот ? ведь R5 именно на частых и коротких записях начинает тупить ... впрочем R5 на 3х дисках и на длительных не особо скорострелен :)
    26 окт 06, 08:39    [3311980]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Biz©
    Member

    Откуда: Snezhinsk
    Сообщений: 5687
    Anton Demidov
    Biz©
    во блин ... а я наивный думал что смысл этого достаточного общего решения в снижении частоты переключений логов и, соотв-но, чекпоинтов ...
    и были в общем правы, но именно в данном конкретном случае мы видим в top 5 wait events ожидания LGWR-a, a не DBWR-а. Именно в данном конкретном случае применили RAID-5 для реду и свалили их всех в одну кучу.

    да эт была реакция на обоснование "смысла" а не по сути треда
    26 окт 06, 08:46    [3311993]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Я и ёжик
    Member

    Откуда: СПб
    Сообщений: 1815
    Biz©
    в целом трудно не согласиться ... но гложат сомнения насчёт мысли о длительных транзакциях ... может наоборот ? ведь R5 именно на частых и коротких записях начинает тупить ... впрочем R5 на 3х дисках и на длительных не особо скорострелен :)


    Да чего вы прицепились то к этому R5. Среднее время одного ожидания 3-4 ms, по приведенным файлам, не блестяще, но и не так страшно.
    Основную долю 85-90% и по 7-ми часовому и по 1-часовому отчету занимает обработка на CPU. Ну уменьшите вы ожидания на записи log файла в 2 раза, промучаетесь со всеми реконфигурациями, возможно ночью придется выйти, дабы бизнес процесс не нарушать, получите выигрыш 2%... заметит это кто то? Ну, разве что начальство, если по результатам нарисуете большой красивый график, уменьшение ожиданий на журнальных файлах, да и то если у начальства не возникнет вопрос, а что нашему бизнесу от этого вашего %.

    Это уже не говоря о том, представляет ли в принципе какую ценность вся эта средняя температура, по больнице полученная по statspack. Вот если журнально-ориентированные ожидания станут составлять существенную долю во времени отклика какого важного бизнес процесса, а время его выполнения будет превышать требуемые или есть вероятность , что будут превышать в будущем, то тогда и надо смотреть как их уменьшить. А так борьба с ветряными мельницами.
    Если хочется бороться за улучшение показателей функционирования базы, т.е. демонстрацией для начальства бурной деятельности, лучше заняться временем cpu, поискать запросики генерирующие много LIO и.т.п., результирующие цифры для начальства будут более привлекательными и может даже пользователям станет лучше.
    26 окт 06, 10:49    [3312702]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    Biz©
    Member

    Откуда: Snezhinsk
    Сообщений: 5687
    Я и ёжик
    Biz©
    в целом трудно не согласиться ... но гложат сомнения насчёт мысли о длительных транзакциях ... может наоборот ? ведь R5 именно на частых и коротких записях начинает тупить ... впрочем R5 на 3х дисках и на длительных не особо скорострелен :)


    Да чего вы прицепились то к этому R5. Среднее время одного ожидания 3-4 ms, по приведенным файлам, не блестяще, но и не так страшно.
    Основную долю 85-90% и по 7-ми часовому и по 1-часовому отчету занимает обработка на CPU. Ну уменьшите вы ожидания на записи log файла в 2 раза, промучаетесь со всеми реконфигурациями, возможно ночью придется выйти, дабы бизнес процесс не нарушать, получите выигрыш 2%... заметит это кто то? Ну, разве что начальство, если по результатам нарисуете большой красивый график, уменьшение ожиданий на журнальных файлах, да и то если у начальства не возникнет вопрос, а что нашему бизнесу от этого вашего %.

    Это уже не говоря о том, представляет ли в принципе какую ценность вся эта средняя температура, по больнице полученная по statspack. Вот если журнально-ориентированные ожидания станут составлять существенную долю во времени отклика какого важного бизнес процесса, а время его выполнения будет превышать требуемые или есть вероятность , что будут превышать в будущем, то тогда и надо смотреть как их уменьшить. А так борьба с ветряными мельницами.
    Если хочется бороться за улучшение показателей функционирования базы, т.е. демонстрацией для начальства бурной деятельности, лучше заняться временем cpu, поискать запросики генерирующие много LIO и.т.п., результирующие цифры для начальства будут более привлекательными и может даже пользователям станет лучше.

    не приписывайте мне чужих заслуг ... я реагировал _только_ на вашу мысль о _длинных транзакциях_ исходя из позиций в топе и объяснял почему меня другие мыслия посетили ... я ж _в целом согласился_, за што пинаити та ? :)
    26 окт 06, 11:21    [3313026]     Ответить | Цитировать Сообщить модератору
     Re: ожидание log file parallel write и переключения редо логов  [new]
    fortnet
    Member

    Откуда:
    Сообщений: 526
    А почему никто не предложил raw - раздел по redo ? Может и не сильно поможет (исходя из 5 %) , зато затрат почти никаких - только разделы создать.
    26 окт 06, 11:35    [3313168]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
    Все форумы / Oracle Ответить