DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Решение вопросов, связанных с буфером журнала обновлений


Проблемы, непосредственно влияющие на буфер журнала обновлений, обычно очень простые. Процесс задерживают всего две вещи: либо процесс сервера не может получить требующуюся ему защелку, либо переполнен буфер журнала обновлений и нет места для записи информации протокола. Если собы­тие 

log buffer 

случается часто и отнимает значительное количество времени, можно смело говорить, что есть проблема. Если же это событие сопровождает­ся одним или несколькими событиями типа 

log file 

(см. предыдущий раздел), это
означает, что, скорее всего, проблема связана с системой ввода/вывода.
Обнаружение в результате поиска события latch free вместе с событиями 

log buffer по

дсказывает, что мы имеем дело с неверным числом защелок или размером журнала. Задавая запросы к V$LATCH о значениях 

redo copy latch 

и 

redo allocation latch, 

можно ознакомиться со статистикой защелок. Это подтвердит, что мы имеем дело с проблемой защелок. Когда отношение числа непопаданий (misses) к числу логических чтений (gets) или immediates_misses к immediate_gets стано­вится больше 1%, ситуация корректируется установлением значения параметра LOG_SIMULTANEOUS_COPIES равным его разрешенному максимуму для конк­ретной платформы (напомним, что этот параметр исключен в Oracle8i), что по­зволяет увеличить число защелок копий. На самом деле можно с самого начала установить максимальное значение этого параметра. Напомним, что в Oracle8i данный параметр конфигурируется автоматически и равен удвоенному количе­ству процессоров в систем
Поэтому, если с защелками все в порядке, проблема, по-видимому, состоит в том, что процесс сервера не может получить достаточного места в буфере жур­нала обновлений. Эта ситуация имеет место, когда буфер журнала сбрасывается принудительно недостаточно быстро или недостаточно часто. Совсем нетрудно сделать буфер журнала большим по размеру, но опыт показывает, что это может довольно быстро привести к достижению точки уменьшения отдачи. Не стоит увеличивать размер буфера журнала обновления, пока не получены конкретные доказательства, что причина кроется в
Очень важно
С позиции чистого ввода/вывода наиболее частой ошибкой является размещение журналов обновлений вместе с файлами базы данных или другими типами файлов, что создает конкуренцию за ресурсы именно там, где это менее всего допустимо. Необходимо размещать журналы обновлений на независимых устройствах, и они должны быть отделены от всех других файлов. Только тогда они смогут работать оптимально. Не забывайте, что переключения журналов обновления на архивирование баз данных также подвержено ограничениям. Следует проверить журналы обновлений и убедиться, что они расположены на правильно сконфигурированных внешних устройствах. Помните, что нельзя перегружать мальчика-копировщика и заставлять его разносить письма и быть на побегушках у всех. Если поступать именно так, велик .   . риск, что он будет не в состоянии правильно выполнять свою основную работу.
После корректировки вопросов распределения внешних устройств (если
это необходимо) преобразуйте размер буфера журнала обновлений. Измените в
файле инициализации значения        и снова запустите экземпляр.
Начните со значения 128 Кбайт или 256 Кбайт и проверьте базу данных на нали­чие событий ожидания, связанных с буфером журнала обновлений. Если он уже стал достаточно большим, скажем, больше 1 Мбайт, то, может быть, не в поряд­ке что-нибудь менее существенное. Например, база данных дошла до точки уме­ньшения отдачи безотносительно к размеру буфера журнала обновлений.
Безошибочный метод вычисления оптимальных размеров буфера журнала об­новлений (или любой другой относящейся к этому кругу вопросов структуры па­мяти) должен опираться на события ожидания и только на них.
 


кирпич облицовочный размеры. . проволока мм . купить диплом







jAntivirus