Управление журнальными файлами

dbstalker, 10 октября

На примере журнальных файлов можно демонстрировать закон единства и борьбы противоположностей.

  • Для оптимизации производительности Вам необходимо конфигурировать LGWR и DBWR так, чтобы операции записи выполнялись как можно реже.
  • для минимизации времени восстановления екземпляра, Вам необходимо конфигурировать LGWR и DBWR так, чтобы операции записи производились как можно чаще.

Решение этой проблемы заключается в достаточном понимании технологий (в основном в понимании обработки контрольной точки и восстановления экземпляра) для того, чтобы выбрать значение параметра log_checkpoint_interval или FAST_START_MTTR_TARGET (в зависимости от версии оракла), которое было бы и достаточно большим и достаточно малым для удовлетворения обоих требований.

Рассмотрим основные моменты администрирования журналов повторного выполнения:

Мультиплексирование

Мультиплексирование необходимо для надежной защиты журнальных файлов от повреждений. Для этого создаются группы журнальных файлов. Каждая группа состоит из нескольких абсолютно идентичных журнальных файлов, называемых элементами (членами) группы, содержат абсолютно одинаковую информацию и имеют один и тот же порядковый номер.

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

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

Если не доступны все элементы текущей группы – у вас большие проблемы: базу нужно восстанавливать.

Если не доступны все элементы активной группы – у вас ёще есть надежда (очень-очень небольшая), что можно принудительно выполнить контрольную точку (ALTER SYSTEM SWITCH LOGFILE, ALTER SYSTEM CHECKPOINT ), после чего журнальная группа станет неактивной. Если же контрольную точку выполнить не удастся, то действия ваши такие же, как и при утрате текущей группы.

Разноска членов журнальной группы по разным дискам

Для того чтобы увеличить период бесперебойной роботы сервера очень желательно разнести элементы журнальной группы по разным дискам. В случае отказа какого-либо диска, будут утеряны только члены группы, которые на нем были размещены. Остальные же элементы будут поддерживать работу сервера.

Очень хорошо сказывается физическое отделение журнальных групп друг от друга. Это связано с тем, что в то время как LGWR-процесс пишет в журнальный файл, процесс ARCn читает журнальный файл (в любой момент времени он может читать один из журнальных файлов, кроме того, который открыт LGWR). Одновременно ARCH пишет в один архивный журнальный файл. Поэтому чтобы избежать конкуренции между процессами ARCn и LGWR, архивные и оперативные журналы также желательно разнести по разным дискам.

Таким образом, если есть три группы по два элемента, то желательно все 6 элементов расположить на 6 разных дисках. Архивные журнальные файлы направлять на 7 диск.

В хорошей конфигурации журнальные файлы должны быть изолированы от файлов данных настолько, насколько это возможно. Физическая изоляция на выделенных дисках и контроллерах позволит Вам снизить до минимума шанс возникновения «узкого места» при выполнении операций ввода/вывода. Это связано с тем, что процесс LGWR пишет на диск последовательно, процесс DBWR вразброс.

Определение оптимального размера

Размер элементов группы зависит от объема генерируемой информации (т.е. как много ваших данных обновляется, удаляется, добавляется) и какие у вас требования ко времени восстановления экземпляра в случае сбоя. Если база работает в режиме ARCHIVELOG , то архивные файлы должны быть такого размера, чтобы поместился на носителе, и неиспользованное пространство было как можно меньше. Желательно, чтобы все журнальные файлы были одного размера – контрольные точки будут выполняться через одинаковые промежутки времени.

Если Вы выбрали большой размер для журнальных файлов, то:

  • Снижается частота переключения журнальных файлов
  • Упрощается размещение журнальных файлов
  • Проще восстановить экземпляр после сбоя (меньше журналов нужно накатать)
  • Снижается вероятность ожидания контрольной точки
  • Снижается нагрузка с процесса архивирования

Если Вы выбрали маленький размер для журнальных файлов, то:

  • уменьшается рассинхронизация резервной и основной базы данных в случае использования standby
  • если будет утерян текущий или активный файл, то будет потерян незначительный объем данных
  • проще манипулировать в операционной системе с архивными журнальными файлами.

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

Определение оптимального количества

Журнальных групп должно быть столько, чтобы не возникало проблем в работе процесса LGWR, журналы всегда должны быть доступны для LGWR. То есть, обработка контрольных точек и процесс архивирования не должны быть препятствием в роботе LGWR. Подбором оптимального числа журнальных групп необходимо снизить вероятность ожидания завершения обработки контрольной точки и архивирования журнальной группы, которая понадобилась серверу в данный момент времени.

Если LGWR будет часто ждать завершения контрольной точки (т.е. пока DBWR завершит запись грязных блоков на диск) или пока журнальный файл будет заархивирован (см. alert.log и файлы трассировки), то очевидно возникает явная необходимость в увеличении количества журнальных групп.

Необходимо также знать, что максимальное количество журнальных групп и максимальное количество членов (элементов) в группе было вами установлены при создании базы данных командой ALTER DATABASE. Если вы хотите в действующей базе данных поменять значения этих параметров, то пересоздайте контрольный файл. Сделать это можно следующим образом:

  • ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
  • В результате вы получите скрипт на создание контрольного файла. Внесите в него изменения.
  • SHUTDOWN IMMEDIATE
  • STARTUP NOMOUNT
  • Выполните скрипт на создание контрольного файла
  • ALTER DATABASE OPEN

Переключение журналов по времени.

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

  • Для уменьшения рассинхронизации резервной и основной базы (standby)
  • Для точного указания периода времени, за которое может быть потеряна информация
  • Для принудительного архивирования.

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

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

Если же значение параметра слишком мало – переключение журнала будет происходить часто, а это потребует значительных серверных ресурсов. Поэтому к установке этого параметра нужно подходить взвешено.

Рекомендую для общего развития почитать статьи по контрольной точке и по восстановлению после сбоя.

2 комментария

Прокоментировать

er
19 июня 2009 г. в 09:40

Вопрос:
  есть некая группа приложений - DWH -BPM , которым транзакции и логи в принципе не нужны, так как источником информации для них являются другие БД, а не уникальные действия пользователей. (я так понимаю REDO отключить не получится в принципе ? )
какие рекомендации для REDO будут в этом случае ? - максимально большой размер ?
может есть недокументируемая возможность об абсолютном отключении логов ?

dbstalker
19 июня 2009 г. в 14:41

REDO не отключается в принципе. Если формируется малый объем redo, значит в большом размере журнальных файлов нет необходимости. К сведению , redo формируется на все (блоки данных и undo сегменты), что находятся в буферном кэше и изменяется.

А зачем в вашем случае вообще нужен ORACLE?

 

Новый комментарий

Я не спамер: введите суму 1+4



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Нужен поставщик Дропшиппинг
10 декабря, 1 ответа
КИНО КАФЕ!!!!!!!!!!!!!!!!
10 декабря, 1 ответа