Часто задаваемые вопросы по OpenEdge RDBMS
VII. Вопросы по журналам транзакций
СУБД OpenEdge использует два типа транзакционных журналов: журнал Before-Image и необязательный журнал After-Image.
F. Журнал Before-Image Log (также BI, также журнал undo-redo)
Журнал Before-Image используется для записи последних изменений базы данных и предоставляет данные, необходимые для отката транзакций и восстановления при сбоях. Пространство в журнале Before-Image автоматически используется повторно после окончания транзакции, когда ее данные больше не нужны.
62. Как часто следует усекать журнал Before-Image?
В большинстве сред журнал the Before-Image стабилизируется на некотором «нормальном» размере, что зависит от конкретного приложения, числа пользователей, активности базы данных и ее размера. Вам не следует усекать журнал, если у вас нет каких-либо причин сделать это. Заметим, что для того, чтобы знать нормальный размер, вы должны наблюдать за нормальным функционированием системы в течение определенного периода времени, пока размер журнала Before-Image не стабилизируется.
Иногда журнал Before-Image может вырастать значительно больше его «нормального» размера, когда вы выполняете операции, которые изменяют большое количество данных, например, перемещение таблиц и индексов, удаление больших таблиц, изменение всех записей в большой таблице или обработка конца года.
Если журнал вырастает значительно больше нормального размера, вы можете рассмотреть необходимость его усечения. Обратите внимание, что горячее резервное копирование включает журнал Before-Image, так что это следует принимать во внимание. Резервные копии в режиме Offline не включают журнал Before-Image, если не используется параметр -norecover.
После усечения журнала Before-Image, когда вы снова запустите базу данных, будет отформатировано кольцо из четырех начальных кластеров журнала. Вы можете использовать утилиту proutil bigrow чтобы отформатировать некоторое количество дополнительных кластеров журнала, перед тем как снова начать использовать базу данных.
63. Почему мой журнал Before-Image такой большой?
Он действительно такой большой? У Вас кончается дисковое пространство? Смотрите ответ на вопрос об усечении журнала Before-Image.
Вот неполный список некоторых действий, которые могут привести к росту журнала Before-Image больше «нормального» размера:
- Обработка конца месяца, конца квартала, конца года и т.п. нагрузка, которая отличается от типичной повседневной нагрузки;
- Любые «массовые» операции, которые затрагивают большое количество данных в одной большой транзакции: обновление миллиона записей, перемещение таблиц и индексов, удаление большого количества ненужных старых данных;
- Транзакции, которые не затрагивают большого количества данных, но остаются открытыми в течение длительного времени, например, начать транзакцию и уйти на обед, домой или в отпуск;
- Увеличение числа пользователей. Обычно, чем больше пользователей, тем больше происходит изменений в базе данных. Обычно увеличение числа пользователей происходит постепенно;
- Рост размера базы данных также часто приводит к росту размера транзакций, что приводит к росту данных в журнале BI;
- Откат большой транзакции, которая была близка к завершению.
64. Какие параметры следует использовать для журнала Before-Image вместо значений по умолчанию?
- Размер кластера для базы данных Workgroup database: 128 килобайт
- Размер кластера для базы данных Enterprise: 2048 килобайт или больше. Оптимальное значение зависит от активности базы данных. Если значение столбца «Flushes» экрана «Checkpoints» в promon равно нулю или малое и продолжительность checkpoint duration равна минуте или более, то размер кластера достаточно велик.
- Размер блока Before-Image: 8192 или 16384.
65. Мой журнал Before-Image достиг 2 гигабайт и база данных остановилась. Что делать?
Обычной практикой является, когда вы имеете переменный экстент в качестве последнего экстента журнала Before-Image. Если этот переменный экстент достигает предельного размера файла в 2 гигабайта (если в базе данных включена поддержка больших файлов и файловая система поддерживает большие файлы, то переменный экстент может стать больше, чем 2 ГБ и проблема не возникнет), то в него нельзя записать больше данных. Вы можете столкнуться с этим ограничением, если база данных или файловая система не поддерживают большие файлы.
База данных закрывается, потому что она не имеет больше места для записей журнала транзакций, генерируемых активной транзакцией, изменяющей базу данных. Кроме того, откат активных транзакций требует создания еще большего количества записей журнала транзакций, поэтому нельзя произвести откат любых существующих активных транзакций. Таким образом, когда база данных находится в этом состоянии, восстановление после сбоя невозможно.
Для выхода из этой ситуации необходимо добавить больше пространства в журнал Before-Image с помощью prostrct add. К сожалению, эта утилита не позволит Вам добавить еще один переменный экстент без предварительного удаления существующего переменного экстента, а его нельзя удалить без предварительного усечения журнала BI, что требует выполнения восстановления после сбоя.
Однако вы можете использовать prostrct add для добавления фиксированного экстента BI. Затем, после выполнения восстановления после сбоя, вы можете усечь журнал Before-Image и создать новые экстенты журнала BI, сделав последний экстент переменным.
Альтернативный метод восстановления:
- Создайте резервную копию базы данных в режиме offline с указанием опции «norecovery». При этом журнал Before-Image будет включен в копию.
- Удалите существующую структуру хранения базы данных.
- Создайте новую структуру хранения и добавьте больше пространства для журнала Before-Image, добавив один или более экстентов BI.
- Используйте утилиту prostrct create для создания новой структуры хранения.
- Восстановите резервную копию в новую структуру базы данных, которая имеет больше пространства.
- Запустите базу данных снова и выполните восстановление после сбоя.
Версии до 9.0A имеют предел данных в 2 гигабайта для журнала Before-Image, даже если в экстентах BI распределено более 2 гигабайт пространства. Если вы используете такую версию, вы определенно должны перейти на свежую версию до того, как превысите этот предел.
66. Почему мое приложение замораживается и что такое checkpoint?
Состояние работающей базы данных определяется тремя (также может быть и четвертая часть, данные в журнале After-Image, но это не имеет отношения к данному вопросу) частями:
- Данные на диске в различных экстентах данных. Некоторые из этих данных являются устаревшими и противоречивыми.
- Данные в блоках буферов в области разделяемой памяти базы данных. Некоторые из этих данных были изменены, но не записаны на диск.
- Записи журнала транзакций в Before-Image. Эти данные необходимы для отката транзакций и восстановления после сбоев.
Все обновления базы данных выполняются на месте в памяти и эти изменения не записываются на диск, когда заканчивается сделавшая эти изменения транзакция. Вместо этого, изменения могут накапливаться в памяти в течение длительного периода времени. Checkpointing представляет собой непрерывный процесс синхронизации данных на диске с изменениями, которые были сделаны в памяти. Заметим, что 100% синхронизация достигается редко и в действительности не нужна. Данные на диске почти всегда частично устаревшие. Этот процесс работает путем записи обновленных блоков данных из разделяемой памяти на диск в непрерывной серии шагов, представляющих собой отдельные контрольные точки, одна за другой. Если этого не делать, данные на диске становятся все более устаревшими.
Каждая контрольная точка начинается, когда recovery manager базы данных открывает новый кластер в журнале Before-Image Log и заканчивается, когда кластер закрывается, после чего открывается новый кластер и начинается следующая контрольная точка. При окончании контрольной точки любые блоки данных, которые были изменены в течение предыдущей контрольной точки и еще не записаны на диск, должны быть записаны. Если таких блоков много, это может занять длительное время. Следующий кластер журнала Before-Image не может быть открыт, пока не завершится процесс записи. Существует два неприятных эффекта при возникновении такой (временной) ситуации:
- Не может быть сделано дальнейшего изменения состояния транзакций или изменений базы данных. Это приведет к тому, что любой пользователь, который хочет выполнить изменение базы данных, начать транзакцию или закончить транзакцию, должен ждать, и приложение покажется «замороженным» на какое-то время.
- Пропускная способность чтения дисков будет снижена из-за высокой интенсивности записи блоков данных. Это приведет к замедлению выполнения запросов.
Для предотвращения этого, база данных использует один или несколько процессов асинхронной записи страниц (APW) для записи блоков данных на диск в фоновом режиме (заметим, что версия Workgroup не включает фоновых процессов ввода/вывода) до окончания контрольной точки.
Когда все данные будут записаны, будет открыт следующий кластер журнала Before Image, будет восстановлено нормальное функционирование и начнется новая контрольная точка.
67. Как можно уменьшить число контрольных точек?
Длительность контрольных точек определяется двумя параметрами: размером кластера журнала Before-Image и числом изменений базы данных, которые происходят в течение контрольной точки (другими словами – нагрузкой). Число изменений есть функция от числа пользователей и операций с базой данных, выполняемых вашим приложением. Контрольная точка всегда начинается, когда открывается кластер журнала Before-Image и заканчивается, когда кластер журнала закрывается. Размер кластера журнала определяет, сколько данных журнала («bi notes») может в нем храниться.
Число контрольных точек, которые создаются в течение определенного периода времени, определяется целиком их продолжительностью. Как только заканчивается одна контрольная точка, всегда начинается следующая.
Чтобы уменьшить число контрольных точек за определенный период времени, вы либо должны уменьшить активность базы данных, либо увеличить размер кластера.
Вы можете увеличить размер кластера с помощью утилиты proutil для усечения журнала Before-Image с указанием нового размера кластера. Например:
$ proutil foo -C truncate bi -bi 4096
Это установит размер кластера равным 4 мегабайтам, и этот размер сохранится до тех пор, пока вы его снова не измените.
Размер кластера по умолчанию постепенно увеличивался от версии к версии от 16 килобайт до 512 килобайт. Вы должны увеличивать размер кластера до тех пор, пока ваши контрольные точки не будут продолжаться от одной до двух минут (или немного больше). Начните с 2048.
Если вы используете базу данных Workgroup, вы не должны увеличивать размер кластера. Наоборот, вы должны его уменьшить, что уменьшит количество измененных блоков, которые должны быть записаны по концу контрольной точки.
G. Журнал After-Image (также AI, также redo log)
Необязательный журнал After-Image используется, в комбинации с предварительной резервной копией, для восстановления после сбоя носителя или других сбоев, когда экстенты данных или журнала Before-Image повреждены или утрачены. При использовании журнала After-Image, вы должны архивировать содержимое заполненных экстентов AI перед тем, как их дисковое пространство может быть использовано повторно.
Для восстановления при аварии, вы восстанавливаете предварительную резервную копию базы данных и затем накатываете журналы After-Image до точки во времени, когда произошла авария.
Журнал After-Image может также быть использован для непрерывного поддержания в «горячем резерве» почти текущей копии базы данных на другом сервере путем копирования на него экстентов AI и наката их на резервную базу данных. Для этого вам может понадобиться дополнительная лицензия на базу данных на резервном сервере.
Имеется программа After-Image Archive Daemon, которая автоматически архивирует заполненные экстенты After-Image в подходящее место по вашему выбору.
68. Следует ли использовать журнал After-Image (AI)?
Ответ 1: Это зависит от базы данных, для чего она используется, насколько ценные данные в ней хранятся, и сколько вам будет стоить потеря всех или части данных, а также за какой период вы их потеряете.
Если это хранилище данных, которые могут быть легко воссозданы или импортированы из другого источника, или это исторический архив с имеющимися резервными копиями, то, возможно, вы можете обойтись без его использования.
Ответ 2: Да, конечно. Все должны это использовать.
Один администратор базы данных, которого мы знаем, и кто так и останется безымянным, однажды чтобы удалить некоторые файлы ввел команду:
rm *
Он был потрясен, когда понял, что он был не в том каталоге и только что удалил производственную базу данных в середине дня. Так как он был в системе UNIX, данные еще не были удалены, даже несмотря на то, что все записи о файлах базы данных были удалены из каталога. До тех пор, пока файлы все еще открыты, база данных по-прежнему существует, и каждый мог продолжать работать, но новые пользователи не могли подключиться.
Когда администратор понял, что произошло, он восстановил вчерашнюю резервную копию в другом каталоге. Затем он отправил сообщение всем пользователям о том, что возникла небольшая проблема, и ему нужно остановить и перезапустить базу данных. Все пользователи отключились от базы данных, и файлы базы данных исчезли, как только последний процесс закрыл файлы. Затем администратор переместил восстановленную копию в оригинальный каталог базы данных и накатил журналы After-Image за текущий день (они размещались на другом диске и не были удалены), чтобы получить самые свежие изменения. Затем он перезапустил сервер базы данных и разрешил пользователям возобновить работу. Никакие данные не были потеряны. Никто ничего не заметил.
69. Как использование AI влияет на производительность?
Многократное тестирование в течение многих лет показало, что на правильно настроенном сервере базы данных использование журналов After-Image уменьшает общую производительность базы данных на менее чем 4 процента. Это было подтверждено в производственных системах многочисленными опытными администраторами баз данных.
70. Сколько необходимо иметь экстентов After-Image?
Вы должны иметь не менее четырех экстентов (если вы определили менее четырех экстентов After-Image, вы почти наверняка столкнетесь с проблемами). Они распределяются следующим образом:
- Один экстент, который недавно был заполнен и ожидает архивирования;
- Один, который является текущим, новые записи журнала записываются в него по мере того, как приложение изменяет базу данных;
- Один пустой и готов к использованию, когда текущий заполнится, и
- Один, который находится в процессе архивирования и будет отмечен как пустой, так что сможет быть использован снова.
Этот вариант гарантирует, что активность базы данных не остановиться и не будет простаивать, потому что нет пустых экстентов, доступных для сохранения новых записей журнала After-Image. Однако: 4 – это абсолютный минимум, лучше использовать 8. Вам может потребоваться и больше, если ваша система создает большое количество данных и экстенты быстро заполняются, или если вы используете OpenEdge Replication. Заметим также, что этот механизм предполагает, что база данных работает в многопользовательском режиме. Если вы работаете в однопользовательском режиме, то, если больше нет пустых экстентов и текущий экстент становится заполненным, база данных будет остановлена. В однопользовательском режиме вы не можете архивировать заполненные экстенты After-Image и пометить их как пустые, когда база данных используется.
Не создавайте большое количество маленьких экстентов AI. Несколько больших файлов – это намного лучше, чем множество маленьких. Например, 200 экстентов по 1 мегабайту каждый является бесполезным расточительством системных ресурсов. Если у вас больше 20 экстентов, вы должны спросить себя – почему? Для этого должна быть действительно хорошая причина.
Чтобы определить, сколько данных будет записано в журнал After-Image, используйте утилиту promon чтобы увидеть, как много контрольных точек создается в обычный день. Затем умножьте количество контрольных точек на размер кластера журнала Before-Image в килобайтах. Такое же количество данных After-Image будет записано в день.
Так как экстенты After-Image должны быть заархивированы и очищены, вы должны иметь для этого автоматический механизм. Простейший способ – использовать программу After-Image Archiver Daemon, которая может быть настроена на архивирование экстентов, когда они заполняются или через заданные промежутки времени.
Если вы используете собственные скрипты для управления экстентами After-Image и запускаете их как задачи cron, убедитесь, что они ничего не будут делать, пока вы выполняете задачи по обслуживанию базы данных или восстановлению, или когда база данных не работает. Один из способов – проверять в скриптах существование файла (например, с именем «doaiarchive») и ничего не делать, если файл не существует. Тогда вы можете удалить файл, чтобы предотвратить выполнение скриптов, и создать его вновь (например, «touch doaiarchive»), когда вы закончили обслуживание.
71. Как использовать After-Image Archiver Daemon?
After-Image Archiver Daemon – это фоновая программа, которая архивирует экстенты After-Image в одно или более мест назначения. После архивирования экстента, программа очищает его, так что данные («after-image notes») снова могут записываться в него. Программа архивирует экстенты либо когда они заполняются, либо в указанные периоды времени, даже если они не заполнены. Для подробного руководства смотрите главу 7 руководства Database Administration.
Чтобы использовать After-Image Archiver, предполагая, что вы уже используете журналы After-image, воспользуйтесь следующими командами.
rfutil foo -C aiarchiver enable
Это включает возможность использования архиватора для базы данных. Затем вы запускаете сервер базы данных:
proserve foo -aiarcdir bar -aiarcinterval 3600
Программа After-Image Archiver Daemon будет запущена одновременно с сервером базы данных «foo» и экстенты After-Image будут архивироваться в каталоге «bar» каждый час. Лучше всего добавить эти параметры в файл параметров (файл «.pf»), который вы используете для запуска сервера базы данных. Тогда вы не забудете о них.
Если для вашей базы данных включена поддержка больших файлов, то вы должны убедиться, что целевой каталог архиватора также находится на файловой системе, поддерживающей большие файлы.
Вы можете изменить целевой каталог архиватора для работающей базы данных с помощью следующей команды:
rfutil foo -C aiarchiver setdir bar
где, вы должны заменить «foo» на имя вашей базы данных и «bar» на путь целевого каталога (или на разделенный запятыми список путей). Не забудьте изменить файл параметров запуска вашей базы данных.
After-Image Archiver Daemon записывает свои действия в файле журнала с именем foo.archival.log в том же каталоге, где находится foo.db.
72. Следует ли использовать экстенты After-Image фиксированного или переменного размера?
Вероятно, вы должны использовать экстенты After-Image переменного размера.
Преимущества использования экстентов After-Image переменного размера:
- Они могут расти по мере необходимости, и могут переключаться через регулярные промежутки времени, а не по их заполнению (например, каждые полчаса). Хотя имеются некоторые накладные расходы, вызванные периодическим расширением экстента переменного размера, в современных файловых системах эти накладные расходы обычно достаточно малы.
- Значительно снижается вероятность того, что вся активность базы данных будет приостановлена из-за того, что все экстенты After-Image заполнены.
- Когда экстент архивируется, в конце файла нет неиспользуемых блоков, что уменьшает количество данных, копируемых при создании архива.
- Когда экстент очищается, он усекается в размере и содержит только блок заголовка. Затем он снова расширяется по необходимости при записи новых данных.
Недостатки использования экстентов After-Image переменного размера:
- Существует небольшая потеря производительности, вызываемая необходимостью выделять дисковое пространство по мере роста экстента переменного размера. Величина этой потери варьируется в зависимости от конкретной операционной системы и типа используемой файловой системы. Вероятно, это создает заметный эффект только для систем с очень большим числом пользователей (более 500) и очень высокой транзакционной нагрузкой.
- Экстенты переменного размера используют переменное количество дискового пространства. Существует некоторая вероятность, что дискового пространства не хватит, и расширение экстента переменного размера может привести к ошибке. Если следующий экстент также расположен на той же (заполненной) файловой системе, он также не может быть расширен.
- Постоянное расширение и усечение экстентов After-Image может привести к некоторой фрагментации файловой системы, что в свою очередь приведет к постепенной деградации производительности файловой системы, если она заполнена приблизительно на 75-80%.
Заметим, что если вы используете After-Image Archiver Daemon для архивирования экстентов фиксированного размера и выполняете переключение по времени, в фиксированных экстентах могут быть распределенные, но не использованные блоки. Программа архивирования не копирует блоки экстентов AI, которые не содержат данных.
73. Как создать зеркало моей базы данных с использованием журналов After-Image?
Основной процесс прост и состоит из следующих действий:
- Создайте как минимум 4 экстента After-Image для базы данных.
- Включите журналы After-Image.
- Создайте резервную копию базы данных.
- Восстановите резервную копию на другом сервере.
- По мере заполнения экстентов After-Image, копируйте их на диск и очищайте. Программа архивирования будет делать это автоматически, либо по мере заполнения экстентов, либо через определенные промежутки времени.
- Копируйте архивированные экстенты на другой сервер, используя сетевое подключение по ssh, scp или с помощью другой подходящей программы. Чтобы убедится, что файлы были скопированы успешно, можно создать маленький файл-компаньон, который содержит хэш md5 отправляемого файла. Когда пересылка файла закончится, отправьте файл хэша. Его появление на принимающей стороне указывает, что основной файл был полностью получен, и может быть использован для проверки того, что полученная копия совпадает с оригиналом.
- На другом сервере используйте утилиту наката данных для загрузки данных из экстентов в копию базы данных.