Batch-Commit bei großer INSERT-Operation in nativem SQL?

Question

Ich habe ein paar große Tabellen (188m und 144m Zeilen) Ich muss aus Ansichten zu füllen, aber jede Ansicht enthält ein paar hundert Millionen Zeilen (zusammenziehen pseudo-dimensional modellierte Daten in eine flache Form). Die Schlüssel auf jeder Tabelle sind über 50 zusammengesetzte Bytes von Spalten. Wenn die Daten in Tabellen wären, könnte ich immer daran denken, sp_rename zu verwenden, um die andere neue Tabelle zu erstellen, aber das ist nicht wirklich eine Option.

Wenn ich eine einzelne INSERT-Operation, verwendet der Prozess eine große Menge an Transaktionsprotokoll Speicherplatz, typischerweise feilte es und eine Menge Ärger mit den DBAs. (Und ja, das ist wahrscheinlich ein Job, den die Datenbankadministratoren handhaben/entwerfen/entwerfen sollten)

Ich kann SSIS verwenden und die Daten mit Batch-Commits in die Zieltabelle streamen (aber dazu müssen die Daten über das Netzwerk übertragen werden) , da wir keine SSIS-Pakete auf dem Server ausführen dürfen).

Irgendwelche anderen Dinge als den Prozess in mehrere INSERT-Operationen unter Verwendung einer Art Schlüssel aufzuteilen, um die Zeilen in verschiedene Stapel zu verteilen und eine Schleife zu machen?

Answer 1

Sie könnten Ihre Daten partitionieren und Ihre Daten in eine Cursorschleife einfügen. Das wäre fast das Gleiche wie SSIS-Batch-Insert. Aber läuft auf deinem Server.

create cursor .... 
select YEAR(DateCol), MONTH(DateCol) from whatever 

while .... 
    insert into yourtable(...) 
    select * from whatever 
    where YEAR(DateCol) = year and MONTH(DateCol) = month 
end 

Answer 2

Sie könnten den BCP-Befehl verwenden, um die Daten zu laden und die Chargengröße Parameter verwenden

http://msdn.microsoft.com/en-us/library/ms162802.aspx

zweistufiger Prozess

• BCP OUT-Daten von Ansichten in Textdateien
• BCP IN Daten von Textdateien in Tabellen mit Batch-Größe Parameter

Answer 3

Dies sieht aus wie ein Job für gute ol 'BCP.

Answer 4

Es gibt keine Pixie Staub, das wissen Sie.

Ohne genaue Informationen über das tatsächlich übertragene Schema zu erhalten, wäre eine generische Lösung genau so, wie Sie es beschreiben: Unterteilen Sie die Verarbeitung in mehrere Einfügungen und behalten Sie den/die Schlüssel im Auge. Dies ist eine Art von Pseudo-Code T-SQL:

create table currentKeys (table sysname not null primary key, key sql_variant not null); 
go 

declare @keysInserted table (key sql_variant); 
declare @key sql_variant; 
begin transaction 
do while (1=1) 
begin 
    select @key = key from currentKeys where table = '<target>'; 
    insert into <target> (...) 
    output inserted.key into @keysInserted (key) 
    select top (<batchsize>) ... from <source> 
    where key > @key 
    order by key; 

    if (0 = @@rowcount) 
     break; 

    update currentKeys 
    set key = (select max(key) from @keysInserted) 
    where table = '<target>'; 
    commit; 
    delete from @keysInserted; 
    set @key = null; 
    begin transaction; 
end 
commit 

Es wäre komplizierter, wenn man für die parallelen Reihen zulassen möge und die Schlüssel partitionieren.

Answer 5

Hat die Ansicht irgendeine Art von eindeutigen Bezeichner/Kandidatenschlüssel? Wenn ja, könnten Sie diese Zeilen in eine Arbeitstabelle mit auswählen:

SELECT key_columns INTO dbo.temp FROM dbo.HugeView; 

(Wenn es Sinn macht, vielleicht setzen diese Tabelle in einer anderen Datenbank, vielleicht mit Modell SIMPLE Recovery, von der Protokollaktivität zu verhindern stören Ihre primäre Datenbank sollte ohnehin viel weniger Protokoll generieren, und Sie können den Speicherplatz in der anderen Datenbank freigeben, bevor Sie fortfahren, für den Fall, dass das Problem darin besteht, dass nicht genügend Festplattenspeicher vorhanden ist.)

Dann können Sie etwas tun, 10.000 Zeilen zu einer Zeit eingeführt wird, und das Protokoll zwischen Sicherung:

SET NOCOUNT ON; 

DECLARE 
    @batchsize INT, 
    @ctr INT, 
    @rc INT; 

SELECT 
    @batchsize = 10000, 
    @ctr = 0; 

WHILE 1 = 1 
BEGIN 
    WITH x AS 
    (
     SELECT key_column, rn = ROW_NUMBER() OVER (ORDER BY key_column) 
     FROM dbo.temp 
    ) 
    INSERT dbo.PrimaryTable(a, b, c, etc.) 
     SELECT v.a, v.b, v.c, etc. 
     FROM x 
     INNER JOIN dbo.HugeView AS v 
     ON v.key_column = x.key_column 
     WHERE x.rn > @batchsize * @ctr 
     AND x.rn <= @batchsize * (@ctr + 1); 

    IF @@ROWCOUNT = 0 
     BREAK; 

    BACKUP LOG PrimaryDB TO DISK = 'C:\db.bak' WITH INIT; 

    SET @ctr = @ctr + 1; 
END 

Das ist alles aus der Spitze von meinem Kopf, so schneiden nicht/einfügen/ausführen, aber ich denke, die allgemeine Idee ist da.

Beachten Sie, dass Sie bei regelmäßigen Datenbank- und Protokollsicherungen wahrscheinlich eine vollständige Datenbank verwenden, um die Protokollkette erneut zu starten.

Answer 6

Ich weiß, das ein alter Thread, aber ich habe eine generische Version von Arthur Cursor Lösung:

--Split a batch up into chunks using a cursor. 
--This method can be used for most any large table with some modifications 
--It could also be refined further with an @Day variable (for example) 

DECLARE @Year INT 
DECLARE @Month INT 

DECLARE BatchingCursor CURSOR FOR 
SELECT DISTINCT YEAR(<SomeDateField>),MONTH(<SomeDateField>) 
FROM <Sometable>; 


OPEN BatchingCursor; 
FETCH NEXT FROM BatchingCursor INTO @Year, @Month; 
WHILE @@FETCH_STATUS = 0 
BEGIN 

--All logic goes in here 
--Any select statements from <Sometable> need to be suffixed with: 
--WHERE Year(<SomeDateField>)=@Year AND Month(<SomeDateField>)=@Month 


    FETCH NEXT FROM BatchingCursor INTO @Year, @Month; 
END; 
CLOSE BatchingCursor; 
DEALLOCATE BatchingCursor; 
GO 

Dies löste das Problem auf Lasten unserer großen Tabellen.