pro4gl.ru

Продолжение перевода 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.