Конфигурирование сервера Oracle для сверхбольших баз данных
       

Число журнальных файлов


Число оперативных журнальных файлов дает Вам возможность определить, будут ли контрольные точки и архивирование журнальных файлов причиной возникновения «узких мест» при обработке транзакций. Выбор правильного числа журнальных файлов поможет Вам снизить:

  • Ожидания занятой контрольной точки

    (checkpoint busy wait) — ожидание занятой контрольной точки возникает, когда LGWR пытается переключиться на журнальный файл до того, как связанная с этим журнальным файлом предыдущая контрольная точка была завершена.

  • Ожидание занятого процесса архивирования (archiver busy wait) — ожидание занятого процесса архивирования возникает, когда LGWR пытается переключиться на журнальный файл, который еще не было скопирован в архивный журнальный файл процессом ARCH.

Ожидание занятой контрольной точки часто возникало в дни, когда в большинстве инсталляций сервера Oracle использовалось всего два журнальных файла, устанавливаемых по умолчанию при инсталляции. Вы можете использовать следующую процедуру для определения наличия и устранения ожиданий занятой контрольной точки:

  1. Проверьте событие log file switch (checkpoint incomplete) в v$session_wait. Если Вы установили параметр log_checkpoints_to_alert в значение true, то Вы можете определить возникновение этой ситуации с помощью текстового вхождения «cannot allocate» в файле alert.log.
  2. Снизить частоту возникновения события ожидания контрольной точки Вы можете:

    • увеличивая число оперативных журнальных файлов для снижения вероятности того, что LGWR сможет заполнить все файлы до того, как будет завершена контрольная точка; или
    • добавляя DBWR процессы для увеличения скорости выполнения контрольной точки (только если Вы используете синхронную запись); или
    • увеличивая значение параметра db_block_checkpoint_batch для увеличения скорости выполнения контрольной точки; или
    • уменьшая значение параметра db_block_buffers для снижения объема работы в контрольной точке; или
    • снижая число и размеры сегментов отката в базе данных (описанных в нижеследующем разделе)


      • Событие ожидания занятого процесса архивирования обычно возникает при генерации большого числа транзакций во время пакетной обработке, когда скорость записи redo-информации LGWR превышают возможности копирования процесса ARCH. Оно также служит причиной возникновения ожидания контрольной точки — ARCH становится «узким местом» для завершения всех транзакций в системе.

      Следующие техники могут использоваться для смягчения проблемы:


      • Чередование с малым размером сегмента

        — разместите Ваши архивные журнальные файлы на дисковом массиве с малым размером сегмента чередования для увеличения скорости обращения к файлам процессом ARCH.
      • Большее число оперативных журнальных файлов — создайте достаточное число оперативных журнальных файлов с тем, чтобы LGWR не смог заполнить все журнальные файлы до того как процесс ARCH закончил копировать.
      • Увеличение числа ARCH-процессов — используйте несколько ARCH-процессов с помощью команды сервера Oracle alter system archive log all to . . . . Консультанты службы поддержки Oracle подготовили несколько инструментов для автоматизации этого процесса.


      11(к тексту)Получены важные результаты, относящиеся к восстановлению носителя сервера Oracle, когда повреждены несколько файлов данных. Рекомендуется сделать несколько циклов восстановление-файла/восстановление-инстанции для каждого файла данных. В этом случае может наблюдаться лучшее качество использования буферного кэша базы данных [, Maulik and Patkar (1995)].
      12(к тексту)Администраторы СУБД Oracle дают большой разброс при оценке скорости доката. Я слышал как низкие оценки — 50KB/сек, так и высокие — до 1,750KB/сек.
      13(к тексту)В OLTP-операциях, частые подтверждения транзакций будут порождать записи LGWR и LGWR будет делать очень много малых записей. В пакетных операциях, нечастые подтверждения транзакций будут порождать большие объемы не записанной в журнальный файл информации, расположенной в журнальном буфере. Если информация будет накапливаться быстрее, чем LGWR будет получать команды для записи, то заполненность буфера более чем на 1/3 будет основанием для начала записи до l байт, где l — размер журнального буфера, заданного с помощью log_buffer.
      14(к тексту)Вы должны попытаться защитить себя от столь катастрофического события, используя n-кратное дублирование аппаратуры для хранения журнальных файлов. Если Вы не в состоянии позволить себе дублирование с помощью аппаратного решения, Oracle7 дает возможность введения зеркалирования с помощью программных средств, используя несколько членов журнальных файлов в группе журнальных файлов.

      Содержание раздела