Перенос данных на чистую базу (постановка)
Материал из GedeminWiki
(Различия между версиями)
SYSDBA (обсуждение | вклад) |
SYSDBA (обсуждение | вклад) (→См. также) |
||
| (не показаны 30 промежуточных версий 2 участников) | |||
| Строка 1: | Строка 1: | ||
| − | + | Принципы ускорения: | |
| − | + | * начальное создание оперативной БД физическим копированием файла исходной (архивной) БД | |
| − | + | * однопроходное последовательное неиндексированное чтение данных | |
| − | + | * отключение индексов, триггеров, ключей, ограничений для удаления устаревших записей на оперативной БД | |
| − | + | * обработка списка идентификаторов в оперативной памяти | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Пусть: | |
| − | + | * A -- исходная (архивная) база данных. | |
| − | + | * B -- оперативная база данных. | |
| − | + | Все таблицы мы подразделяем на: | |
| − | [[Category:Постановка]] | + | * Таблицу gd_document. Обрабатывается последней в два прохода. Сначала шапки, затем позиции. |
| + | * Главные таблицы БО (кроме gd_document). Только на главные таблицы могут налагаться условия переноса. | ||
| + | * Таблицы, связанные 1-к-1 в реляционной модели. Данные из этих таблиц переносятся, только если переносится главная запись. | ||
| + | * Детальные таблицы (таблицы с дополнительной информацией, таблицы с позициями документов, таблицы документов). Данные из этих таблиц переносятся, если переносится соответствующая мастер запись. Мы вычисляем такие таблицы по наличию поля masterkey или masterdockey. | ||
| + | * Таблицы-связки для атрибутов типа множество. Связки переносятся только в том случае, если переносится запись из таблицы, которой принадлежит атрибут типа множество. | ||
| + | * Прочие таблицы (без идентификатора ИД или со сложным первичным ключем). Переносятся всегда. | ||
| + | * Таблица [[GD_RUID]] (id в этой таблице будет обязательно дублироваться с одним из id из другой таблицы в БД). Из таблицы удаляются записи для ИД, которые не были перенесены. | ||
| + | * Таблицы, которые используют свои генераторы для присвоения идентификаторов (например, GD_USERGROUP). Данные переносятся всегда. | ||
| + | |||
| + | Списки таблиц упорядочиваем по возрастанию количества внешних ссылок на таблицу. | ||
| + | |||
| + | Подготовка исходной базы данных: | ||
| + | |||
| + | # отключенные внешние ключи должны быть включены | ||
| + | # блокировка периода должна быть снята | ||
| + | # кэш не должен превышать 500 Мб | ||
| + | # аудит должен быть отключен | ||
| + | # пользователю рекомендуется провести бэкап-разбэкап исходной базы перед началом процесса. | ||
| + | |||
| + | База В получается из базы А путем копирования и присвоения нового идентификатора базы данных. | ||
| + | |||
| + | Пусть: | ||
| + | |||
| + | * M -- множество идентификаторов, требуемых в базе В по условиям целостности. | ||
| + | * M2 -- множество идентификаторов записей, не удовлетворяющих условиям. | ||
| + | * L -- список пар идентификаторов, где первый -- ИД записи, второй -- ИД ссылки одного из полей этой записи. | ||
| + | |||
| + | Алгоритм обработки базы В: | ||
| + | |||
| + | # Последовательно сканируем каждую таблицу в соответствии с ее типом (см. выше). Проверяем каждую запись. | ||
| + | ## Если запись удовлетворяет условию, то ее идентификатор и идентификаторы всех ссылок из нее заносим в М. При этом, если идентификатор ссылки находится в М2, то исключаем его оттуда и заносим в М все идентификаторы ссылок для данного идентификатора записи из списка L. После чего удаляем ненужные пары из L. | ||
| + | ## Если запись не удовлетворяет условию, то ее идентификатор заносим в М2, а в L заносим пары идентификатор записи - идентификатор ссылки, для всех ссылок, которых нет в М. | ||
| + | # Таблицу gd_document обрабатываем в два прохода: | ||
| + | ## сначала только шапки, аналогично общему алгоритму обработки записей. | ||
| + | ## затем только позиции. В М добавляем ИД позиции только в том случае, если там присутствует ИД шапки. | ||
| + | # Деактивируем триггеры, удаляем индексы, удаляем внешние ключи, ограничения уникальности, первичные ключи. | ||
| + | # Из всех таблиц удаляем записи, которых нет в М. | ||
| + | # Восстанавливаем первичные ключи, ограничения уникальности, внешние ключи, индексы. Активируем триггеры. | ||
| + | |||
| + | === Замечания по реализации === | ||
| + | |||
| + | # Системные записи (ИД менее 147 000 000) и ссылки на системные записи игнорируем полностью. | ||
| + | # Подключение к базе В выполняем с отключенной сборкой мусора. | ||
| + | # Отключаем принудительную запись на базе В. | ||
| + | # М и М2 -- битовые массивы, изначальные размеры которым устанавливаем исходя из диапазона идентификаторов, вычисленного как [[GD_G_UNIQUE]] - 147000000.Используем класс TgsHugeIntSet. | ||
| + | |||
| + | ==== Работа с базой А после разделения ==== | ||
| + | |||
| + | IDA -- значение генератора из БД А на момент старта процесса. | ||
| + | IDB = IDA + 1000000 -- значение генератора в БД B, устанавливаемое на момент окончания процесса. | ||
| + | |||
| + | В базе А создается триггер на коммит транзакции, который проверяет, если значение генератора больше, чем IDB - 1000, то выдается исключение. | ||
| + | |||
| + | ==== Слияние баз А и B ==== | ||
| + | |||
| + | Сначала выполняются все отложенные операции синхронизации изменений в B. | ||
| + | |||
| + | В общем случае потребуется на базу А накатить все настройки, которые были установлены на B с момента разъединения этих баз. | ||
| + | |||
| + | ===См. также=== | ||
| + | |||
| + | * [[Полное закрытие периода (постановка)]] | ||
| + | |||
| + | [[Category:Постановка-Сделано]] | ||
| + | [[Category:Репликация]] | ||
| + | |||
| + | __NOTOC__ | ||
Текущая версия на 14:49, 2 апреля 2014
Принципы ускорения:
- начальное создание оперативной БД физическим копированием файла исходной (архивной) БД
- однопроходное последовательное неиндексированное чтение данных
- отключение индексов, триггеров, ключей, ограничений для удаления устаревших записей на оперативной БД
- обработка списка идентификаторов в оперативной памяти
Пусть:
- A -- исходная (архивная) база данных.
- B -- оперативная база данных.
Все таблицы мы подразделяем на:
- Таблицу gd_document. Обрабатывается последней в два прохода. Сначала шапки, затем позиции.
- Главные таблицы БО (кроме gd_document). Только на главные таблицы могут налагаться условия переноса.
- Таблицы, связанные 1-к-1 в реляционной модели. Данные из этих таблиц переносятся, только если переносится главная запись.
- Детальные таблицы (таблицы с дополнительной информацией, таблицы с позициями документов, таблицы документов). Данные из этих таблиц переносятся, если переносится соответствующая мастер запись. Мы вычисляем такие таблицы по наличию поля masterkey или masterdockey.
- Таблицы-связки для атрибутов типа множество. Связки переносятся только в том случае, если переносится запись из таблицы, которой принадлежит атрибут типа множество.
- Прочие таблицы (без идентификатора ИД или со сложным первичным ключем). Переносятся всегда.
- Таблица GD_RUID (id в этой таблице будет обязательно дублироваться с одним из id из другой таблицы в БД). Из таблицы удаляются записи для ИД, которые не были перенесены.
- Таблицы, которые используют свои генераторы для присвоения идентификаторов (например, GD_USERGROUP). Данные переносятся всегда.
Списки таблиц упорядочиваем по возрастанию количества внешних ссылок на таблицу.
Подготовка исходной базы данных:
- отключенные внешние ключи должны быть включены
- блокировка периода должна быть снята
- кэш не должен превышать 500 Мб
- аудит должен быть отключен
- пользователю рекомендуется провести бэкап-разбэкап исходной базы перед началом процесса.
База В получается из базы А путем копирования и присвоения нового идентификатора базы данных.
Пусть:
- M -- множество идентификаторов, требуемых в базе В по условиям целостности.
- M2 -- множество идентификаторов записей, не удовлетворяющих условиям.
- L -- список пар идентификаторов, где первый -- ИД записи, второй -- ИД ссылки одного из полей этой записи.
Алгоритм обработки базы В:
- Последовательно сканируем каждую таблицу в соответствии с ее типом (см. выше). Проверяем каждую запись.
- Если запись удовлетворяет условию, то ее идентификатор и идентификаторы всех ссылок из нее заносим в М. При этом, если идентификатор ссылки находится в М2, то исключаем его оттуда и заносим в М все идентификаторы ссылок для данного идентификатора записи из списка L. После чего удаляем ненужные пары из L.
- Если запись не удовлетворяет условию, то ее идентификатор заносим в М2, а в L заносим пары идентификатор записи - идентификатор ссылки, для всех ссылок, которых нет в М.
- Таблицу gd_document обрабатываем в два прохода:
- сначала только шапки, аналогично общему алгоритму обработки записей.
- затем только позиции. В М добавляем ИД позиции только в том случае, если там присутствует ИД шапки.
- Деактивируем триггеры, удаляем индексы, удаляем внешние ключи, ограничения уникальности, первичные ключи.
- Из всех таблиц удаляем записи, которых нет в М.
- Восстанавливаем первичные ключи, ограничения уникальности, внешние ключи, индексы. Активируем триггеры.
[править] Замечания по реализации
- Системные записи (ИД менее 147 000 000) и ссылки на системные записи игнорируем полностью.
- Подключение к базе В выполняем с отключенной сборкой мусора.
- Отключаем принудительную запись на базе В.
- М и М2 -- битовые массивы, изначальные размеры которым устанавливаем исходя из диапазона идентификаторов, вычисленного как GD_G_UNIQUE - 147000000.Используем класс TgsHugeIntSet.
[править] Работа с базой А после разделения
IDA -- значение генератора из БД А на момент старта процесса. IDB = IDA + 1000000 -- значение генератора в БД B, устанавливаемое на момент окончания процесса.
В базе А создается триггер на коммит транзакции, который проверяет, если значение генератора больше, чем IDB - 1000, то выдается исключение.
[править] Слияние баз А и B
Сначала выполняются все отложенные операции синхронизации изменений в B.
В общем случае потребуется на базу А накатить все настройки, которые были установлены на B с момента разъединения этих баз.
