Эффективная передача большого количества (84 миллиона строк) данных

У меня около 84 миллионов строк. Из них все они должны быть перенесены в отдельную базу данных на одном сервере, затем я удаляю, чтобы удалить около 60 миллионов строк из исходной базы данных.

84 миллиона строк находятся в одной таблице. Одна только эта таблица составляет 90% всей базы данных.

Итак ... Источник: 84 миллиона строк -> 24 миллиона строк Назначение: 0 строк -> 84 миллиона строк

Источник работает в режиме полного восстановления, пункт назначения будет работать просто.

Мне интересно, что было бы наиболее эффективным способом сделать это?

План А:

1) ВСТАВИТЬ В НАЗНАЧЕНИЕ ВЫБРАТЬ * ОТ источника

2) источник TRUNCATE

3) INSERT INTO source SELECT * FROM destination WHERE keep_condition = 1

План B:

1) Восстановите резервную копию исходной базы данных в качестве целевой базы данных.

2) Удалите все таблицы, кроме той, которая нужна в целевой базе данных.

3) источник TRUNCATE

4) INSERT INTO source SELECT * FROM destination WHERE keep_condition = 1

План C:

1) ВСТАВИТЬ В НАЗНАЧЕНИЕ ВЫБРАТЬ * ОТ источника

2) УДАЛИТЬ источник, ГДЕ keep_condition = 0

или что-то другое?

Спасибо

Я хотел бы добавить, что, как бы вы ни подошли к этому, вам нужно будет пакетировать эти транзакции . В последнее время мне очень повезло с этой статьей, и я ценю то, как она использует индексы в отличие от большинства пакетных решений, которые я вижу.

Даже при минимальной регистрации это большие транзакции , и вы могли бы потратить много времени, чтобы разобраться с последствиями ненормального роста журнала (VLF, усечение, правильное изменение размера и т. Д.).

Спасибо

«Эффективный» может применяться к использованию файла журнала, производительности ввода-вывода, времени процессора или времени выполнения.

Я попытался бы достичь минимально зарегистрированной операции, которая была бы довольно эффективной с точки зрения регистрации. Это должно сэкономить вам некоторое время выполнения в качестве бонуса. Если у вас есть место в базе данных tempdb, вам может помочь следующее.

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

Для выполнения операции с минимальным протоколированием должно быть выполнено несколько условий, включая отсутствие резервных копий, работающих в данный момент, базу данных, установленную в BULK_LOGGEDрежим восстановления, и, в зависимости от ваших индексов, таблица назначения может быть пустой. Некоторые из этих действий также изменились (улучшены) с SQL Server 2005 на 2008.

Опять же, не зная специфики вашей таблицы и данных, любой из ваших других вариантов может работать лучше. Попробуйте использовать

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. и посмотрим, что работает лучше всего.

РЕДАКТИРОВАТЬ : при выполнении операций с массовой регистрацией убедитесь, что вы делаете резервную копию (полный или журнал транзакций) до и после операции, если вам требуется возможность восстановления на определенный момент времени, и вы подозреваете, что в базе данных могут выполняться другие действия на в то же время, когда ваша работа ETL выполняется.

Я написал пост в блоге о минимально зарегистрированных операциях некоторое время назад, там есть ссылки на другие посты и документацию.

Почему не BCP?

1. Резервное копирование источника
2. Изменить sourcedb на массовую регистрацию

3. Открыть командную строку

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. проверить данные

8. Из SSMS Обрезать исходную таблицу
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. Заменить sourcedb обратно на полный

Не думайте, что вам следует рекомендовать изменить модель восстановления без полного резервного копирования базы данных или резервного копирования t-log до и после . Одна из особенностей модели восстановления BULK_LOGGED заключается в том, что вы потеряете возможность выполнять восстановление на определенный момент времени для t-журналов, содержащих операции с массовой регистрацией. Классический сценарий: еженедельное полное резервное копирование, ежечасные резервные копии t-log. Вы изменяете модель восстановления для массовой регистрации и запускаете свою работу. Что-то идет не так, и транзакция откатывается (или вы еще не использовали). Однако вы не уверены, что еще происходило в базе данных, поэтому вы хотите восстановить до известного хорошего момента.

Когда вы можете восстановить? Последнее ежечасное резервное копирование t-log, которое не содержит операций с массовой регистрацией, что может привести к потере n минут транзакций. Полная резервная копия или резервная копия t-журнала перед изменением модели восстановления создаст резервную точку. Какой из них вы выберете, зависит от вашего RTO.

Удаление разделов из таблицы - это действительно быстрый и экономически эффективный способ удаления больших порций данных из таблицы. Если бы эта таблица была разделена таким образом, который поддерживает разделение на источник / место назначения, ответом было бы восстановить копию, удалить избыточные таблицы и избыточные разделы из пункта назначения и удалить дополнительные разделы из источника.

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