Data Warehouse Technologien

4.5.1 Verwendung des Oracle SQL-Loader

Das Initialbefüllen des Data Warehouse und das Einbringen der externen Da-

ten aus den Quellen in den Datenbeschaffungsbereich kann durch Massenlader

(engl. Bulk-Loader) effizient gestaltet werden. Das Laden mittels Massenlader

erfolgt dabei meistens in einem speziellen Kontext des relationalen Systems.

Beispielsweise ist bei Oracle die Option DIRECTPATH im Ladeprogramm möglich.

Dabei erfolgt eine komplette Tabellensperre für den Ladezeitraum. Damit das

Einfügen schnell erfolgen kann, werden sowohl Trigger als auch Constraints

nicht beachtet. Auch die Erzeugung der zugehörigen Indexstrukturen erfolgt

erst im Anschluss. Somit steht dieser Ladevorgang nicht im transaktionalen

Kontext des Datenbankmanagementsystems. Ebenfalls ist ein Logging ausge-

schaltet. Um jedoch bei Abbrüchen während des Ladevorgangs einen hohen

Aufwand zu vermeiden und einen komplett neuen Ladevorgang zu starten, kön-

nen Checkpoints genutzt werden.

In Abbildung 4.17 ist der Oracle SQL-Loader abgebildet, vergleiche hierzu

auch die Oracle-Dokumentation [AK11].

SQL*Loader

Loader-

Kontroll-

datei

Input

Datafiles

Schlechte

Dateien

Input

Datafiles

Abgelehnte

Dateien

Datenbank

Indexe

Tabellen

Log-

Datei

Input

Datafiles

Input-

Dateien

Abbildung 4.17: Oracle sqlldr

JBeispiel 4-11I Der Ladeprozess benötigt neben den Quelldaten auch noch

eine Steuerungsdatei (Control File) als Eingabe. Der Aufbau des Control Files

ist wie folgt:

LOAD DATA

INFILE ’bier.dat’

114 4 Extraktions-, Transformations- und Ladeprozess

REPLACE INTO TABLE getraenke (

bier

_

name POSITION(1) CHAR(35),

bier

_

preis POSITION(37) ZONED(4,2),

bier

_

bestellgroesse POSITION(42) INTEGER,

getraenk

_

id "getraenke

_

seq.nextval"

)

Das zugehörige Datenfile lautet dann bier.dat und hat den folgenden exempla-

rischen Aufbau:

Ilmenauer Pils 4490 100

Erfurter Bock 6400 80

Magdeburger Weisse 1290 20

Anhaltinisch Flüssig 8800 200

2

Während des Ladevorgangs überprüft der SQL-Loader die Daten entspre-

chend der Steuerungsdatei. Hierbei werden für Checkpoints und zur Dokumen-

tation, welche Daten in die Relationen übernommen wurden bzw. welche als

schlechte markiert sind, eine Logdatei erstellt. Die nicht übernommenen Daten

werden in einer separaten Datei für die weitere Verarbeitung abgelegt. Soll-

ten einzelne Input-Daten nicht im Ladeprozess verwendet werden, so werden

diese ebenfalls extra markiert. Im Anschluss an das Laden der Daten in die

Relationen werden dann die entsprechenden Indexstrukturen angepasst.

Der Oracle-Massenlader bietet eine Vielzahl von Optionen, die einen in-

dividuellen Ladeprozess ermöglichen. Hierzu zählen unter anderem die Be-

handlung von Ausnahmen und einfache oder komplexe Datentransformatio-

nen. Auch das Festlegen von Checkpoints für das Wiederaufsetzen erfolgt mit-

tels Optionen. Außerdem sind konditionelles Laden in unterschiedliche Tabel-

len, aber auch das Laden einzelner Records möglich. Für die Entscheidung über

ein INSERT oder UPDATE der Daten stehen die Methoden REPLACE und APPEND

zur Verfügung. Auch ist es in Abhängigkeit vom Datenbankmanagementsys-

tem möglich, eine Parallelisierung des Ladevorgangs durch den SQL-Loader

zu realisieren. Schematisch ist der SQL-Loader von Oracle in Abbildung 4.18

dargestellt, siehe hierzu auch [AK11].

Während der Oracle-Server für Benutzerprozesse und generierte SQL-

Kommandos über den SQL-Loader zuerst die SQL-Befehle verarbeitet, er-

folgt im Anschluss das notwendige Speichermanagement. Für den Fall, dass

die Daten im Speicher Platz finden, werden partielle Blöcke identifiziert und

gefüllt. Überdies wird der Speicher neu angepasst. Anschließend erfolgt das

Puffermanagement. Bevor die Daten in die Datenbank geschrieben werden,

müssen Datenbankblöcke gelesen und geschrieben werden. Mittels der Opti-

on Direct Path wird über den SQL-Loader der Datenbankblock direkt in die

Datenbank geschrieben. Jedoch muss zuerst entsprechend der Datengröße der

4.5 Die Ladephase 115