Проблемы, непосредственно влияющие на буфер журнала обновлений, обычно очень простые. Процесс задерживают всего две вещи: либо процесс сервера не может получить требующуюся ему защелку, либо переполнен буфер журнала обновлений и нет места для записи информации протокола. Если событие
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 Мбайт, то, может быть, не в порядке что-нибудь менее существенное. Например, база данных дошла до точки уменьшения отдачи безотносительно к размеру буфера журнала обновлений.
Безошибочный метод вычисления оптимальных размеров буфера журнала обновлений (или любой другой относящейся к этому кругу вопросов структуры памяти) должен опираться на события ожидания и только на них.
< Предыдущая | Следующая > |
---|