Вход в личный кабинет:

Забыли пароль? | Регистрация

Адреса компании:

Санкт-Петербург

196158, Санкт-Петербург,
Пулковское шоссе, д. 30,
корп. 4, Лит. А, офис 203

Тел: +7 812 414 95 41

Москва

129085, г. Москва, проезд Ольминского, д. 3а, стр. 3, офис 706

Тел: +7 495 616 00 53

Блог

26.08.2015

Progress OpenEdge: промышленные средства репликации данных в Oracle и MS-SQL

Progress OpenEdge Pro2 Replication

Читать далее →




Десять причин перехода на новые версии OpenEdge (Progress)


Влияние TABLEMOVE на Before-Image и After-Image

Вернуться к списку постов

12.03.2011

Когда 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 байт на один индекс. Умножьте полученное значение на количество индексов…

Конечно же, эти числа представляют собой грубую оценку, но вероятность того что они окажутся верны, достаточно высока.


Добавить свой комментарий

Ваше имя*:
Ваш E-mail*:
Ваш комментарий*:

Компьютерные системы для бизнеса
© 2010 - 2017 Все права на материалы, находящиеся на этом сайте, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах. При любом использовании материалов сайта ссылка на источник обязательна.