Перенос данных на чистую базу (постановка)
Принципы ускорения:
- последовательное неиндексированное чтение исходных данных
- отключение индексов, триггеров, ключей, ограничений на конечной базе данных
- обработка множества идентификаторов в оперативной памяти
- пересылка данных между базами внутри сервера
Примем:
A -- исходная база данных. B -- конечная база данных.
Перед началом процесса проверяем базу А:
- отключенные внешние ключи должны быть включены
- блокировка периода должна быть снята
- кэш не должен превышать 500 Мб
- аудит должен быть отключен
Пользователю рекомендуется провести бэкап-разбэкап исходной базы перед началом процесса.
База B создается из копии метаданных А. На время переноса данных отключается принудительная запись и размер кэша устанавливается не более 500 Мб. Подключение осуществляется в режиме с отключенными триггерами базы данных. Генератор идентификаторов базы B увеличивается на заданную дельту.
В базе B создаем структуры:
- для хранения структуры БД в части удаленных\отключенных объектов метаданных
- для хранения информации о записях с начальным сальдо
- для хранения лога изменения данных
- для хранения информации об исходной БД
Считываем и запоминаем структуру базы B. Деактивируем или удаляем следующие объекты метаданных: триггеры, индексы, чеки, внешние ключи, первичные ключи, вычисляемые поля.
Создаем множество R для идентификаторов объектов, подлежащих переносу из А в B.
Выводим сальдовые значения и помещаем их в B. Помещаем в R идентификаторы объектов, необходимых для суммарных значений.
Все таблицы мы подразделяем на:
- таблицу gd_document
- главные таблицы БО (кроме gd_document)
- таблицы, связанные 1-к-1 в реляционной модели
- детальные таблицы (таблицы с дополнительной информацией, таблицы с позициями документов, таблицы документов)
- таблицы-связки для атрибутов типа множество
- прочие таблицы (без идентификатора ИД или со сложным первичным ключем)
- таблица GD_RUID (id в этой таблице будет обязательно дублироваться с одним из id из другой таблицы в БД)
- таблицы, которые используют свои генераторы для присвоения идентификаторов (например, GD_USERGROUP)
Списки таблиц упорядочиваем по возрастанию количества внешних ссылок на таблицу.
Алгоритм переноса:
- Проходимся по таблицам-связкам для множеств и помещаем в R все встреченные идентификаторы элементов множеств.
- Организуем цикл по прочим таблицам. Для каждой сканируем все записи и добавляем все встреченные ссылки в R.
- Сканируем шапки из таблицы gd_document. Проверям на условия переноса. Если условия выполнены и ИД записи еще нет в R то:
- сканируем все поля-ссылки в этой записи и добавляем в R идентификаторы.
- добавляем ее идентификатор в R.
- Сканируем позиции из таблицы gd_document. Если ИД записи еще нет в R и ИД шапки находится в R, то:
- сканируем все поля-ссылки в этой записи и добавляем в R идентификаторы.
- добавляем ее идентификатор в R.
- Организуем цикл по главным таблицам БО. Внутри каждой таблицы организуем цикл по всем записям. Если ИД записи не в R и по условиям она подлегает переносу, то:
- сканируем все поля-ссылки в этой записи и добавляем в R идентификаторы.
- добавляем ее идентификатор в R.
- Организуем цикл по детальным таблицам и по таблицам 1-к-1. Если ИД главной записи находится в R, то:
- сканируем все поля-ссылки в этой записи и добавляем в R идентификаторы.
- добавляем ее идентификатор в R.
- Если в процессе выполнения пунктов 3-6 в R добавлен хотя бы один новый идентификатор, то повторяем цикл начиная с шага 3.
- Переносим данные из А в B:
- все данные прочих таблиц
- для таблиц с идентификаторами -- все записи, которые зафиксированы в R
- для таблиц-связок -- все записи, относящиеся к объектам из R
Примечание: при выполнении шагов 5 и 6, если таблица имеет древовидную структуру, то организуется цикл от первой до последней записи, который повторяется пока в процессе обработки не было добавлено ни одного нового ИД в R.
Восстанавливаем в B удаленные и деактивированные объекты метаданных.
В базе B на каждую таблицу создаются триггеры после изменения и после удаления, которые синхронизируют изменения с базой А. (или фиксируют изменения для последующей синхронизации).
Создаем в А таблицу и записываем параметры базы B.
Работа с базой А после разделения
IDA -- значение генератора из БД А на момент старта процесса. IDB = IDA + 1000000 -- значение генератора в БД B, устанавливаемое на момент окончания процесса.
В базе А создается триггер на коммит транзакции, который проверяет, если значение генератора больше, чем IDB - 1000, то выдается исключение.
Слияние баз А и B
Сначала выполняются все отложенные операции синхронизации изменений в B.
Создается база C, как копия метаданных базы B. Запоминается ее структура. Отключаются индексы, чеки, триггеры, ключи. Переносится на нее информация из A и из B. Не переносятся суммарные данные. Восстанавливаются ключи, индексы, триггеры, чеки.
В общем случае потребуется на базу А накатить все настройки, которые были установлены на B с момента разъединения этих баз.
Альтернативный способ переноса данных на чистую базу
- Базу В делаем из базы А с помощью утилиты nbackup. В начальном состоянии -- это точная копия базы А.
- Определяем зависимости на базе А.
- Все таблицы подразделяем на:
- Таблицы с целочисленным первичным ключем (без разницы, это главная таблица БО или присоединенная 1-к-1)
- Таблицы-связки для множеств
- Прочие таблицы (без ключа, с нецелочисленным ключем, со сложным ключем)
- Для хранения зависимостей нам понадобятся структуры:
- Массив M ссылок на блоки памяти. Номер ячейки в массиве соответствует идентификатору. Содержимое ячейки -- это номер блока со ссылками.
- Массив S блоков ссылок. Каждый блок имеет размер 16 байт и содержит в себе три ссылки и номер следующего блока в цепочке.
- Организуем цикл по всем таблицам в БД
- Прочие таблицы пропускаем.
- Таблицы с целочисленным ключем обрабатываем следующим образом:
- Проверяем ячейку с номером, равным идентификатору, в М. Если она пуста, то берем очередной свободный блок в S и его номер заносим в ячейку. Блок заполняем ссылками из рассматриваемой записи. Если ссылки не умещаются в один блок, то берем следующий. В каждом предыдущем блоке хранится номер следующего в цепочке. При этом, не заносим дважды повторяющиеся ключи.
- Если ячейка не пуста, то берем из нее номер первого блока в цепочке и считываем все идентификаторы (они понадобятся нам, чтобы избежать дублирования). Дописываем в цепочку блоков идентификаторы из рассматриваемой записи. При необходимости выделяем новые блоки и добавляем их в цепочку.
- Таблицы-связки обрабатываем следующим образом: заносим в цепочку идентификатор элемента множества для объекта, которому принадлежит данный атрибут типа множество.
- Все таблицы подразделяем на:
- Удаляем ключи, индексы, деактивируем триггеры.