Журнал before-image
Журнал before-image
Нам следует побеспокоиться и о размере области, отведенной под журнал before-image (или — область primary recovery). Эта область постоянно ответственна за поддержку целостности базы данных и является очень важной. Основная нагрузка этой области — нагрузка на запись. Если область расположена на медленных дисках, то операции обновления данных в базе будут такими же медленными. Размер области зависит от активности по обновлению данных и от длины транзакций.
Область primary recovery состоит из кластеров, размер кластеров можно настроить. При обновлении записи БД создаются заметки об этом обновлении, которые и записываются в эту область . Если в транзакции возникла ошибка или пользователь решил отменить (undo) изменения этой транзакции, то эти заметки используются для корректного отката всех произошедших внутри транзакции изменений .
Для примера предположим, что нам надо увеличить на 10 процентов значение одного конкретного поля для всех записей в таблице. Для изменения надо использовать стратегию «всё-или-ничего» , так как мы не сможем определить на каком месте аварийно закончилось обновление. В этом случае нам необходима одна большая транзакция внутри которой мы будем производить изменения. Если произойдет ошибка, то все измененные поля в записях «откатятся» к своим первоначальным значениям. Важно знать, что если у нас выполняется одновременно несколько больших процессов, то размер области before-image может стать довольно значительным.
Давайте рассмотрим структуру и использование данной области подробнее. Эта структура представляет собой связанный список кластеров, размер которых может быть изменен в широких пределах — от 8Kb до более чем 256Mb.
Чем меньше размер кластера, тем чаще наступает событие именуемое как checkpoint. Checkpoint — это точка синхронизации буферной памяти БД и дисковой системы. Может возникнуть желание сделать наступление checkpoint как можно редким из-за соображений производительности, но тем самым мы увеличиваем время на процессы восстановления (recovery) базы данных.
Как же определить правильный размер кластера before-image ?
- Необходимо наблюдение за БД во время наибольшей активности на обновление
- Сбор статистики при помощи OpenEdge Management
- Наблюдение за интервалами между checkpoint’ами в течении недели
В идеальном случае, событие checkpoint должно наступать не чаще, чем один раз в две минуты. Если это событие наступает чаще, то необходимо увеличить размер кластера before-image. Это не означает, что при более редких checkpoint’ах нам необходимо уменьшать размер кластера bi-файла. Значение по умолчанию — 512Kb. Это достаточно для маленьких систем с редкой транзакционной активностью. Для большинства других систем больше подходят значения из диапазона 1024 — 4096Kb.
Просмотр информации о событиях checkpoint в OE Management
- Из верхнего меню выбрать «Resources» и необходимую нам базу данных
- Выбрать опцию «Page Writers» из секции «Operations Views» страницы ресурсов БД.
На иллюстрации ниже — пример раздела «Checkpoint summary»
Как уже и говорилось, размер кластера влияет на частоту наступления событий checkpoint. Пользователи изменяют данные в буферной памяти БД, лежащую в разделяемой памяти (shared memory) и заполняют кластер bi-файла заметками об этом. Процессы APW (Async Page Writers, асинхронные страничные писатели) постоянно сканируют память в поисках модифицированных буферов для сброса их на диск. Во время первого checkpoint все модифицированные буфера помещаются в очередь. Буфера из этой очереди должны быть сброшены на диск процессами APW до наступления следующего checkpoint. Приоритет записи из такой очереди больше, чем для записи на диск текущих модифицированных буферов. Если вся очередь сброшена на диск успешно, то появляется время на обработку этих буферов. Наша цель — чтобы так и происходило. Если же буферы из этой очереди за оставшееся время сбросить на диск не удается, то обработка текущих модифицированных буферов приостанавливается до полного исчерпания оставшейся очереди. Если интервал событий checkpoint лежит в разумных временных рамках и все же при наступлении checkpoint происходит сброс буферов (flushing buffers at checkpoint), то необходимо добавить один или несколько APW-процессов и посмотреть, что из этого получится. Обычно добавление APW помогает, если нет — добавьте еще один процесс и оцените результат. Если добавление APW-процессов перестало улучшать картину, то необходимо искать узкое место в дисковой подсистеме.
Мы обсудили структуру области primary recovery, но не её размер. Универсального рецепта нет — все зависит от приложения. Но одно сказать можно — из-за соображений производительности необходимо изолировать раздел, содержащий эту область, от других томов БД. Если база у нас одна, то можно вынести эту область на отдельный раздел-зеркало (RAID1). При наличии нескольких БД области primary recovery можно разместить на защищенных массивах с чередованием (RAID10) для увеличения пропускной способности.