СЕКРЕТЫ OPENEDGE: УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ OPENEDGE ПРИ ПОМОЩИ OPENEDGE MANAGEMENT

ПОДРОБНО О BEFORE-IMAGE

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

ОСНОВНЫЕ ПРАВИЛА

Эти правила применимы как к областям before-image, так и к областям данных:

• Не делайте их слишком большими
• Количество областей должно лежать в разумных пределах, ими должно быть легко управлять
• Схема данных должна быть отделена от самих данных
• Для всех таблиц, кроме схемы и таблиц очень маленького размера, должны быть использованы области хранения Типа II
• Большие таблицы выносите в отдельные области, остальные таблицы сгруппируйте в отдельных областях хранения по среднему размеру записи
• Всегда обращайте внимание при выделении таблиц в отдельные области на то, каким образом чаще всего используются эти таблицы
• Всегда делайте последний экстент области экстентом переменного размера
• Включите возможность использования больших файлов в качестве дополнительной меры безопасности

Включение опции EnableLargeFiles особенно важно для файла before-image, так как этот файл наиболее вероятно  может вырасти до размера больше чем 2Gb и вызвать проблемы. Плохо написанная программа, выполняющая большое обновление данных внутри неправильных транзакционных скобок, или программа, открывшая на длительное время транзакцию — все они могут вызвать аномальный рост before-image. Если фиксированный экстент области primary recovery равен 2Gb, то вполне возможно, что во время выполнения таких программ базе данных будет необходимо увеличивать и экстент нефиксированного типа. И тут может получиться так, что нам будет нужно задействовать гораздо больше пространства, чем 2Gb для отката транзакции. Если опция EnableLargeFiles применена к БД и на диске достаточно места, то беспокоиться не о чем. Если же поддержка больших файлов не включена, то база данных аварийно остановится при превышении размера в 2Gb для нефиксированного экстента и не сможет быть корректно восстановлена, так как для того, чтобы увеличить размер области primary recovery БД должна быть корректно остановлена.

ПОСЛЕДОВАТЕЛЬНЫЙ ДОСТУП

Область primary recovery — это область, к которой осуществляется последовательный доступ. Данные записываются и читаются из этой области в основном линейно. При возможности необходимо изолировать эту область от других областей базы данных. Лучше всего будет разместить экстенты данной области на одном зеркалированном диске.

Чередование (stripping) увеличивает потенциал пропускной способности файловой системы. Эффективность чередования наиболее полно раскрывается при случайном доступе к данным. Но если разместить область primary recovery на страйп-массив , то никакого выигрыша мы не получим, напротив увеличится количество перемещений головок дисков. Если же эта область не отделена от базы данных или необходимо разместить на одном массиве primary recovery области разных баз данных, то страйп-массив как нельзя лучше подходит для этих целей. В этом случае будет осуществляться действительно случайный доступ к данным на массиве.

ПРЕДВАРИТЕЛЬНОЕ ФОРМАТИРОВАНИЕ  BEFORE-IMAGE

При помощи утилиты proutil возможно предварительно отформатировать кластеры BI-файла перед тем, как их будет использовать база данных. Эта операция позволит записать больше recovery-заметок в файл и заполнить больше кластеров перед тем, как базе данных понадобится принимать решение о повторном использовании кластеров или об увеличении размера области. Если событие решения о повторном использовании будет происходит редко, то более вероятно, что самый «старый» кластер уже готов к повторному использованию и будет использоваться. Если область primary recovery не подвержена аномальному росту, то сохраняется постоянный размер данной области, что очень хорошо в плане производительности. Для предварительного форматирования файла BI база данных должна быть остановлена.

Команда, выполняющая такое форматирование выглядит так:

proutil dbname -C bigrow #

# — это количество кластеров, которые необходимо добавить к уже существующим кластерам области. Если эта команда выполняется после усечения (truncate) файла BI, то количество существующих кластеров равно нулю.