Antwort.

Hintergrund der Frage

Das Auftreten von großen Speicher- und Datenströmen (ETL, Migrationen) erfordert nicht nur das Laden von Hunderttausenden von Zeilen, sondern auch die Garantie, dass die Daten entweder vollständig geladen werden oder gar nichts geladen wird. In SQL wird dies durch atomare Bulk-Operationen unter Verwendung von Transaktionen realisiert.

Problem

Beim Bulk Insert besteht ein höheres Fehlerrisiko — eine fehlerhafte Zeile kann den gesamten Ladevorgang verderben oder zu einer teilweisen Einfügung führen. Dies ist in finanziellen, logistischen und anderen kritischen Systemen inakzeptabel.

Lösung

Die Praxis besteht darin, die Bulk-Operation in eine Transaktion zu wickeln, geeignete spezielle Befehle (BULK INSERT, COPY) zu verwenden und Fehler abzufangen/protokollieren. Wichtig: Bei Fehlern in einer Zeile wird der gesamte Block zurückgesetzt:

Beispiel für SQL Server:

BEGIN TRAN;
BULK INSERT Customers
FROM 'C:\data\customers.csv'
WITH (
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '
',
    FIRSTROW = 2
);
IF @@ERROR <> 0 ROLLBACK TRAN; ELSE COMMIT TRAN;

In PostgreSQL (Beispiel mit COPY):

BEGIN;
COPY products FROM '/tmp/products.csv' DELIMITER ',' CSV HEADER;
COMMIT;

Wichtige Merkmale:

Garantie für „alles oder nichts“ (Atomicität)
Hohe Ladegeschwindigkeit durch Batch-Verarbeitung
Möglichkeit zur Fehlerbehandlung mit Protokollierung problematischer Zeilen

Fangfragen.

Beeinflusst die Größe der Transaktion bei Bulk Insert die Leistung und Sperrungen?

Ja, bei zu großen Volumina kann es zu langen Sperren, Überläufen der Transaktionsprotokolle und Verlangsamungen des Servers kommen. Am besten ist es, in Chargen (Batch) zu laden, z.B. 10.000 Zeilen pro Transaktion.

Ist Bulk Insert immer standardmäßig transaktional in allen DBMS?

Nein, in einigen DBMS (z.B. MySQL) ist der Bulk-Insert-Befehl nicht immer automatisch atomar — man muss ihn manuell in BEGIN/COMMIT einwickeln, sonst kann es zu einer teilweisen Einfügung kommen.

Kann die Integrität der Fremdschlüssel bei einem Bulk Insert garantiert werden?

Ja, nur wenn die Reihenfolge der Ladung beachtet wird: zuerst die Elterntabellen, dann die Kindtabellen, oder temporär die Constraints deaktiviert werden. Ein Fehler beim Fremdschlüssel wird die gesamte Bulk-Insert-Transaktion zurücksetzen.

Typische Fehler und Anti-Pattern

Versuch, eine zu große Datei in einer Operation zu laden, was zu einem Überlauf des Speichers und der Protokolldateien führt
Nachlässigkeit bei der Protokollierung von Fehlern — schwer herauszufinden, warum die Daten inkorrekt sind
Missachtung der Ladeordnung verknüpfter Tabellen mit Fremdschlüsseln

Praxisbeispiel

Negativer Fall

Beim Laden von Kunden führte eine fehlerhafte Zeile in der Datei zu einer teilweisen Ladung — am Ende des Tages waren die Datenbank und die externe Quelle desynchronisiert.

Vorteile:

Einsparungen bei der Code-Struktur, einfache Implementierung Nachteile:
Datenverlust, der zu Ausfällen in der Geschäftslogik führt

Positiver Fall

Die Datei wird vorab auf Fehler überprüft, der Bulk Insert wird in Chargen von 5.000 Zeilen aufgeteilt, jede Charge in ihrer eigenen Transaktion. Fehlerprotokolle werden für eine spätere Analyse gespeichert.