Журналирование After-Image

Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management». Перевод публикуется в виде статей и постоянно редактируется.

Журналирование After-Image

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

Файлы AI похожи на файлы BI – доступ к ним осуществляется так же последовательно, однако у них нет автоматического повторного использования. Из-за этого ограничения использование AI-журналирования требовало участия администратора. Но начиная с 10-ой версии в OpenEdge для облегчения работы используется AI Archiver. Кроме того, AI-журналирование является неотъемлимой частью OE Replication, так что если вы планируете запустить репликацию БД, то AI-журналирование должно быть включено.

На сегодняшний день AI-журналирование является единственным способом восстановления при сбоях аппаратного обеспечения и при логическом разрушении информации в базе данных.

Рассмотрим пример : был запущен некорректный скрипт, который обновил каждое поле Name таблицы Customer на значение “Frank Smith”. Никакие меры физической защиты БД тут не помогут – если мы используем зеркалирование, то и на зеркальном массиве у нас будут неправильные данные. Единственный способ восстановить данные – это восстановление ночного бекапа и накат (roll-forward) на него AI-файлов ровно до времени запуска вредоносной утилиты. Рекомендуется включать журналирование для любой БД, в которой обновляется информация – это позволит восстановить данные вплоть до момента отказа.

Журналирование AI и утилита OpenEdge AI Archiver

Ниже рассматривается:

  • Изолированное хранение файлов журналирования для аварийного восстановления
  • Состав After-Image
  • Определение количества AI-экстентов
  • Выбор переменных или фиксированных экстентов
  • Статусы экстентов
  • Последовательный доступ
  • Включение AI-журналирования
  • Включение AI Archiver
  • Запуск базы данных с опцией AI Archiver
  • Добавление AI-экстентов
  • Хранение заархивированных AI-файлов
  • Стратегия хранения архивов AI
  • Некоторые команды AI Archiver и опции запуска

 

Файлы AI-журналирования должны храниться отдельно от БД

Как мы уже отмечали – файлы BI должны находиться на отдельных от основной БД носителях. Это обусловлено требованиями к производительности БД. Файлы AI должны также отделяться от основной БД и размещаться на отдельных от нее носителях или даже на другом сервере. Но причина другая – только таким образом возможно защититься от потери БД при крахе носителей, на которых она размещена. При крахе носителей БД или отказе накопителей с  журналом BI необходимо восстановить прошлый бэкап и использовать файлы AI-журналирования для восстановления БД на момент отказа накопителей. В этом случае мы потеряем только незавершенные на момент отказа транзакции.Если же отказали носители AI-файлов, то мы просто выключим AI-журналирование и перезапустим БД. Важно понимать, что изолировать файлы AI-журналов необходимо на физическом уровне,т.е. выделять под них отдельные носители или устройства.

Состав AI-журнала

Файлы AI-журнала могут размещаться в одном или нескольких экстентах БД OpenEdge. Каждый экстент имеет свой уникальный номер. Для систем высокой доступности AI-журнал должен иметь более одного экстента.

Определение количества AI-экстентов

Необходимо минимум два при активированной опции AI Archiver, а вообще советуется иметь больше сегментов. Более-менее разумное значение для большинства систем – это 5.

Кроме того, для снятия online-бекапа БД необходимо больше одного экстента AI. Процесс снятия online-бекапа происходи следующим образом:

  • Выставляется латч (защелка, latch) в shared-memory, которая запрещает update-активность БД.
  • Происходит псевдо-чекпойнт (сбрасываются на диск модифицированные буфера БД)
  • Происходит переключение AI-экстента (если используется AI)
  • AI-экстент в статусе Busy (см. ниже) помечается как Full и переключенный в предыдущем шаге экстент маркируется как busy
  • Производится бекап BI-области
  • Снимается латч, запрещающий update-активность БД
  • Производится дальнейший бекап блоков БД

 Выбор экстента – переменный или фиксированный?

Доводы за экстенты переменной длины:

  • С ними легко работать. Практически не нужно наблюдать за размером экстента
  • Наращение экстента практически незаметно для системы
  • Экстенты переменной длины минимизируют потери дискового пространства и занимают ровно столько места, сколько необходимо
  • Если файловая система, где лежат AI-экстенты используется еще кем-то, то существует риск фрагментации файлов AI-журнала. Обычно данный риск считается незначительным.

Доводы за экстенты фиксированной длины:

  • Необходимо понимать активность БД на изменение/добавление записей
  • Экстенты фиксированной длины не наращивают свой размер в процессе работы БД – есть небольшой выйгрыш в производительности
  • Практически сведен на нет риск того, что экстент AI-журнала будет фрагментирован

Состояния экстента

Каждый экстент находится в одном из трех возможных состояний

  • Empty – Это пустой экстент. Он пуст и готов к использованию
  • Busy – экстент в этом статусе используется в текущий момент базой данных. Статуз Busy – всегда только у одного экстента БД.
  • Full – Экстент содержит заметки AI-журнала и закрыт. Запись в него невозможна до тех пор, пока оне не будет подготовлен для повторного использования администратором БД и не помечен как Empty

Последовательный доступ

Файл журнала AI – файл последовательного доступа, аналогично файлу журнала BI. К нему применимы все те же рекомендации, что и для описанной выше области primary recovery.

 

 

 

 

Leave a Reply

You must be logged in to post a comment.