Перенос данных на чистую базу (постановка)

Текущая версия на 14:49, 2 апреля 2014

Принципы ускорения:

• начальное создание оперативной БД физическим копированием файла исходной (архивной) БД
• однопроходное последовательное неиндексированное чтение данных
• отключение индексов, триггеров, ключей, ограничений для удаления устаревших записей на оперативной БД
• обработка списка идентификаторов в оперативной памяти

Пусть:

• A -- исходная (архивная) база данных.
• B -- оперативная база данных.

Все таблицы мы подразделяем на:

• Таблицу gd_document. Обрабатывается последней в два прохода. Сначала шапки, затем позиции.
• Главные таблицы БО (кроме gd_document). Только на главные таблицы могут налагаться условия переноса.
• Таблицы, связанные 1-к-1 в реляционной модели. Данные из этих таблиц переносятся, только если переносится главная запись.
• Детальные таблицы (таблицы с дополнительной информацией, таблицы с позициями документов, таблицы документов). Данные из этих таблиц переносятся, если переносится соответствующая мастер запись. Мы вычисляем такие таблицы по наличию поля masterkey или masterdockey.
• Таблицы-связки для атрибутов типа множество. Связки переносятся только в том случае, если переносится запись из таблицы, которой принадлежит атрибут типа множество.
• Прочие таблицы (без идентификатора ИД или со сложным первичным ключем). Переносятся всегда.
• Таблица GD_RUID (id в этой таблице будет обязательно дублироваться с одним из id из другой таблицы в БД). Из таблицы удаляются записи для ИД, которые не были перенесены.
• Таблицы, которые используют свои генераторы для присвоения идентификаторов (например, GD_USERGROUP). Данные переносятся всегда.

Списки таблиц упорядочиваем по возрастанию количества внешних ссылок на таблицу.

Подготовка исходной базы данных:

1. отключенные внешние ключи должны быть включены
2. блокировка периода должна быть снята
3. кэш не должен превышать 500 Мб
4. аудит должен быть отключен
5. пользователю рекомендуется провести бэкап-разбэкап исходной базы перед началом процесса.

База В получается из базы А путем копирования и присвоения нового идентификатора базы данных.

Пусть:

• M -- множество идентификаторов, требуемых в базе В по условиям целостности.
• M2 -- множество идентификаторов записей, не удовлетворяющих условиям.
• L -- список пар идентификаторов, где первый -- ИД записи, второй -- ИД ссылки одного из полей этой записи.

Алгоритм обработки базы В:

1. Последовательно сканируем каждую таблицу в соответствии с ее типом (см. выше). Проверяем каждую запись.
   1. Если запись удовлетворяет условию, то ее идентификатор и идентификаторы всех ссылок из нее заносим в М. При этом, если идентификатор ссылки находится в М2, то исключаем его оттуда и заносим в М все идентификаторы ссылок для данного идентификатора записи из списка L. После чего удаляем ненужные пары из L.
   2. Если запись не удовлетворяет условию, то ее идентификатор заносим в М2, а в L заносим пары идентификатор записи - идентификатор ссылки, для всех ссылок, которых нет в М.
2. Таблицу gd_document обрабатываем в два прохода:
   1. сначала только шапки, аналогично общему алгоритму обработки записей.
   2. затем только позиции. В М добавляем ИД позиции только в том случае, если там присутствует ИД шапки.
3. Деактивируем триггеры, удаляем индексы, удаляем внешние ключи, ограничения уникальности, первичные ключи.
4. Из всех таблиц удаляем записи, которых нет в М.
5. Восстанавливаем первичные ключи, ограничения уникальности, внешние ключи, индексы. Активируем триггеры.

[править] Замечания по реализации

1. Системные записи (ИД менее 147 000 000) и ссылки на системные записи игнорируем полностью.
2. Подключение к базе В выполняем с отключенной сборкой мусора.
3. Отключаем принудительную запись на базе В.
4. М и М2 -- битовые массивы, изначальные размеры которым устанавливаем исходя из диапазона идентификаторов, вычисленного как GD_G_UNIQUE - 147000000.Используем класс TgsHugeIntSet.

[править] Работа с базой А после разделения

IDA -- значение генератора из БД А на момент старта процесса. IDB = IDA + 1000000 -- значение генератора в БД B, устанавливаемое на момент окончания процесса.

В базе А создается триггер на коммит транзакции, который проверяет, если значение генератора больше, чем IDB - 1000, то выдается исключение.

[править] Слияние баз А и B

Сначала выполняются все отложенные операции синхронизации изменений в B.

В общем случае потребуется на базу А накатить все настройки, которые были установлены на B с момента разъединения этих баз.

[править] См. также

• Полное закрытие периода (постановка)