Этот сайт посвящается администрированию баз данных OpenEdge Progress.
Не корысти ради, а познания для!
С уважением,
Валерий Башкатов
|
Сайт разработан при участии компании Progress Technologies, официального дистрибьютора Progress Software Corp. на территории стран СНГ и Латвии.
На сайте функционирует система коррекции ошибок. Обнаружив неточность в тексте, выделите её и нажмите Ctrl+Enter
Результаты опроса: Нужны ли книги по Progress OpenEdge на русском языке? (опрос проводился с мая 2009 по ноябрь 2010)
Да, нужны. Потому что будет легче понять материал - 268
Нет, не нужны. Достаточно материалов на английском языке - 10
Не знаю, мне всё равно - 6
А знаете ли вы что..
|
|
|
Влияние proutil -C tablemove на before-image и after-image
Когда Progress выполняет перемещение таблицы из одной области хранения в другую, для обеспечения целостности база данных, он это делает в пределах одной транзакции. Т.е. если в момент перемещения произойдет сбой, то все данные будут восстановлены в исходное состояние.
Во время процесса перемещения, все записи читаются из исходной таблицы, и один в один создаются в новой конечной таблице, после чего исходные записи удаляются. Кроме того, удаляются все индексы исходной таблицы, после чего они создаются уже для новой таблицы. Так же в это время происходит перераспределение пространства. Все эти операции регистрируются базой данных обычным способом, а это означает, что before-image файл может стать очень большим, намного больше чем размер таблицы и её индексов вместе взятых. Так же они регистрируются и в after-imaging, если он активирован, и это может привести к высокому количеству переключений между AI экстентами. На текущий момент не существует какого-либо способа точно вычислить дисковое пространство, необходимое для выполнения этих операций.
Самый простой способ, но не обязательно удобный, состоит в том, чтобы сделать отдельную базу данных, содержащую некоторую таблицу (образец) и выполнить её перемещение, после чего посмотреть, сколько информации будет зарегистрировано в BI и AI. Если перемещаемый образец таблицы будет по размеру составлять, скажем 10% от реальной таблицы, то значит размер генерируемых BI и AI заметок на боевой базе данных будет примерно в 10 раз больше того, что было сгенерировано при перемещении образца. Так же, если выключен AI, то необходимо убедиться, что AI -экстенты могут достаточно быстро копироваться, сохраняться и помечаться как empty, чтобы не допустить полного заполнения всех AI -экстентов.
Еще один пример для грубой оценки роста BI файла. Допустим, что таблица имеет размер 300 Мб и содержит записи по 100 байт. Таким образом, у нас есть примерно 3 000 000 записей. Для создания записи в новой области необходима BI-заметка примерно в 200 байт. Для удаления записи в исходной области так же требуется примерно 200 байт плюс еще 100 байт для создания указателя размещения (placeholder). Кроме того, будут необходимы заметки о перераспределении пространства и заметки для обновления RM-цепочки. Допустим, что им нужно еще 100 байт на запись (возможно реальное значение меньше). И в целом мы получаем 600 байт в BI-файле на одну запись. Таким образом 600 * 3 000 000 получаем 1 800 000 000 байт. И это не включая элементов индекса.
Количество заметок, необходимых для индексов, зависит от количества индексов. Для каждого индекса, существующий вход (entry), указывающий на исходную запись, должен быть удален, а новый вход, ссылающийся на новую запись в целевой области, должен быть создан. В нашем случае, у каждого индекса будет 3 000 000 входов. Предположим, что в BI-файле 100 байт нужны для удаления входа и еще 100, для того, чтобы создать новый. Получаем, 200 * 3 000 000 будет равно 600 000 000 байт на один индекс. Умножьте полученное значение на количество индексов...
Конечно же, эти числа представляют собой грубую оценку, но вероятность того что они окажутся верны, достаточно высока.
|
|
|
|
Главная
