CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Mit Bulk Copy & Co. am Log vorbei

Das Kopieren von Massendaten in einer SQL-Server Datenbank kann ganz schön viel Zeit in Anspruch nehmen. Um Daten von einer Tabelle in eine andere zu schieben – zum Beispiel um Erweiterungen an einer Faktentabelle vorzunehmen – können einige Stunden ins Land ziehen. Ganz abgesehen von dem nicht unerheblichen Speicherbedarf für das Log-File.

Vor kurzem hatten wir einen Fall, bei dem es genau darauf ankam: Über 200 Mio. historisierte Datensätze in einer Faktentabelle, die wegen einer Erweiterung des Datenmodells “im Weg” waren. Nach der Anpassung des Datenmodells mit dem Modeler dauerte es fast einen ganzen Tag, bis die Daten mit der INSERT-Anweisung von der Faktentabelle in eine temporäre Tabelle und wieder zurückgespielt waren. Für die lange Laufzeit war hauptsächlich das Log-Verhalten des SQL-Servers verantwortlich.

Heute möchten wir ein paar Möglichkeiten vorstellen, wie Daten aus einer Tabelle heraus übertragen werden können, ganz ohne eine Spur im Datenbank-Log.

SELECT … INTO

Die einfachste Art, um Daten von einer Tabelle in eine neue Tabelle zu übertragen ist die SELECT … INTO-Anweisung. Damit wird auf der Basis der SELECT-Abfrage eine neue Tabelle angelegt, die genau die gleiche Spaltendefinition wie die Ursprungstabelle hat.

SELECT * INTO MyNewTable FROM T_FACT_01_MyBigFatTable [WHERE ];

Mit dieser einfachen Anweisung werden die Daten am Log vorbei von der Ursprungstabelle in eine neue Tabelle übertragen. Es können über die WHERE-Klausel sogar Einschränkungen vorgenommen werden.

Damit verkürzt sich die Zeit für die Übertragung im Gegensatz zur INSERT-Anweisung erheblich. Ein Nachteil ist jedoch, dass die Zieltabelle vorher nicht existieren darf. Sie wird auf der Basis der im SELECT-Statement angegebenen Spalten neu erstellt.

BULK COPY (bcp.exe)

Zu den Bordmitteln jeder SQL-Server Installation gehört das Hilfsprogramm bcp.exe. Damit können Daten aus einer SQL-Server Datenbank in eine Datei – und auch wieder zurück – übertragen werden.

SWITCH

Der schnellste Weg um Daten aus einer Tabelle in eine andere – strukturgleiche – Tabelle zu Übertragen ist das SWITCH-Statement. Innerhalb weniger Millisekunden werden die Daten von einer Tabelle in die andere umgehängt. Das Statement sieht auch ziemlich einfach aus:

ALTER TABLE SWITCH MySourceTable TO MyDestinationTable

Dabei müssen die Quell- und die Zieltabelle aber genau gleiche Strukturen aufweisen – sonst funktioniert es nicht. Aber um vor dem CreateSnowflake die Daten aus der Faktentabelle zu sichern und die Faktentabelle zu leeren ist dies wirklich die schnellste aller Möglichkeiten. Allerdings muss hier die Zieltabelle – anders als beim SELECT … INTO-Statement – bereits existieren.