MS SQL Server, многократная вставка

Question

Скажем, я пишу запрос:

INSERT INTO DestinationTable 
(ColumnA, ColumnB, ColumnC, etc.) 
SELECT FROM SourceTable 
(ColumnA, ColumnB, ColumnC, etc.) 

И мой источник таблица имеет 22 миллионов строк.

SQL-сервер заполняет мой жесткий диск и ошибки.

Почему SQL-сервер не обрабатывает мой запрос?

Должен ли я использовать курсор и вставлять строку за раз?

PS - это SQL Express 2005, но я мог бы попробовать полную версию.

UPDATE: Я также хочу упомянуть, что моя исходная таблица занимает около 1 ГБ памяти, когда я смотрю на нее в студии управления. И все же мое 25 ГБ свободного дискового пространства каким-то образом заполняется? Я также использую две разные базы данных Source.mdf -> Destination.mdf, я не знаю, имеет ли это значение.

Answer 1

Пакетное обновление ...

INSERT INTO DestinationTable 
    (ColumnA, ColumnB, ColumnC, etc.) 
SELECT TOP 100000 ColumnA, ColumnB, ColumnC, etc. 
FROM SourceTable 
WHERE NOT EXISTS (SELECT * 
    FROM DestinationTable 
    WHERE DestinationTable.KeyCols = SourceTable.KeyCols) 

WHILE @@ROWCOUNT <> 0 
    INSERT INTO DestinationTable 
     (ColumnA, ColumnB, ColumnC, etc.) 
    SELECT TOP 100000 ColumnA, ColumnB, ColumnC, etc. 
    FROM SourceTable 
    WHERE NOT EXISTS (SELECT * 
     FROM DestinationTable 
     WHERE DestinationTable.KeyCols = SourceTable.KeyCols) 

Есть варианты, чтобы иметь дело с контрольными точками, авторизуйтесь управлением файлами, если вам это нужно в одном TXN и т.д.

Answer 2

Этого блог post имеет информацию об импорте данных в SQL Сервер.

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

Я бы действительно проанализировал, нужны ли все данные.

Answer 3

Вы можете копировать данные в файл в собственном формате (изменение изменено с Csv на native) и импортировать его обратно в новую таблицу.

Read up the BCP utility here.

Answer 4

Вы вставляете данные таким образом, что поддерживает сделку. Невозможно отключить этот метод с помощью метода, который вы используете, однако вы можете сделать это за пределами транзакции другими способами. Читайте ниже:

http://support.microsoft.com/kb/59462

Ключевой подход заключается в следующем:

DBOPTION 'SELECT INTO' истинной

http://www.mssqlcity.com/FAQ/Devel/select_into.htm

Answer 5

Вы можете попробовать установить модель восстановления базы данных "Simple" вместо «Полный» (по умолчанию). Это делается на странице «Параметры» свойств базы данных в Management Studio. Это должно уменьшить размер журнала транзакций. После того, как вы закончите вставку, вы всегда можете вернуть модель восстановления в режим Full.

Answer 6

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

По умолчанию - для базы данных установлено значение ПРОСТОТА или ПОЛНАЯ модель восстановления.

Полная модель восстановления, которая полностью регистрирует все транзакции, предназначена для нормального использования.

Модель восстановления с объемным журналом предназначена для временного использования во время большой объемной операции - при условии, что она относится к массовым операциям, которые подвержены влиянию модели восстановления с большим объемом (для получения дополнительной информации см. Операции, которые могут быть Минимально зашел на msdn.microsoft.com/en-us/library/ms191244.aspx).

BULK_LOGGED модель восстановления минимально регистрирует транзакции

вы можете сделать это, используя ниже фрагмент кода

--Determine the recovery model currently used for the database 

    SELECT name AS [Database Name], 
    recovery_model_desc AS [Recovery Model] 
    FROM sys.databases 
    WHERE name=<database_name> ; 

    --Remember this recovery model so that you can switch back to the same later 

    --set the database recovery model to BULK_LOGGED 

    ALTER DATABASE <database_name> SET RECOVERY BULK_LOGGED; 

    --Run your heavy data insert tasks 
    INSERT INTO DestinationTable 
    (ColumnA, ColumnB, ColumnC, etc.) 
    SELECT FROM SourceTable 
    (ColumnA, ColumnB, ColumnC, etc.) 

    /*Again set the database recovery model to FULL or SIMPLE 
    (the result which we had got from first query)*/ 

    ALTER DATABASE <database_name> SET RECOVERY FULL; 
    --OR 
    ALTER DATABASE <database_name> SET RECOVERY SIMPLE; 

* Примечание - Пожалуйста, держите терпение во время операции объемной обрабатываемой * [: P]

Я сделал это много раз раньше. Сообщите мне, помогло ли это вам.

Вы можете обратиться ниже статье MSDN для деталей переключения между моделями восстановления - Соображения при переключении с полной или неполным протоколированием модели восстановления в msdn.microsoft.com/en-us/library/ms190203.aspx

Answer 7

Проблема с INSERT INTO ... SELECT (22 миллиона строк) заключается в том, что все работает как одна транзакция. Таким образом, вы, вероятно, заполните журнал транзакций, даже если база данных находится в режиме простого восстановления.

Вставка одной строки за один раз - это ужасная идея, она будет навсегда.

Экспортировать данные с помощью BCP, а импорт - как BULK INSERT, вероятно, самый быстрый способ. Но для этого требуется научиться использовать служебную программу BCP.

Если вы решили сделать это в T-SQL, вы должны разбить его на партии. Метод INSERT ... SELECT TOP (n) ... WHERE NOT EXISTS в предыдущем ответе работает, но время выполнения для предложения WHERE может складываться. Чтобы сделать его немного более эффективным и сложнее, я иногда заполняю временную таблицу значениями pk для каждых n строк, используя ROW_NUMBER() OVER (ORDER BY pk) и WHERE rn% (n) = 0. Тогда вы можете использовать цикл с INSERT INTO ... SELECT ... WHERE pk> @a AND pk < = @b с соответствующим кодом для обновления переменных на каждой итерации из таблицы temp. Просто убедитесь, что вы не пропустите ни одной строки на первой или последней итерации.

Возможно, вы захотите сделать это в Integration Services, который также может выполнять объемные вставки. Существует белая бумага Microsoft где-то около загрузки терабайт данных за 30 минут или около того. Они экспортировали (BCP?) Исходные данные в несколько файлов и создали несколько таблиц с той же структурой, что и пункт назначения. Затем вставьте каждый файл в отдельную пустую таблицу, и все они могут выполняться как минимально зарегистрированные. И все эти импортные операции выполнялись как отдельные параллельные процессы. Наконец, используйте команды разбиения таблиц, чтобы объединить каждую таблицу импорта в таблицу назначения.

нагрузки терабайт в течение 30 минут: https://technet.microsoft.com/en-us/library/dd537533(v=sql.100).aspx