SAP unload/load, SQL*Loader (SAP-Bibliothek - Datenbankverwaltung (Oracle) mit SAPDBA)

SAP unload/load, SQL*Loader

Verwendung

Für Export-/Import-Prozesse bietet SAPDBA neben ORACLE export/Import (Voreinstellung) die Werkzeuge SAP unload/load bzw. SAP unload/SQL*Loader (ab ORACLE 7.2) an. SAP load und SQL*Loader verwenden das gleiche von SAP unload erstellte Datenformat.

Vor dem Start des SQL*Loaders muß das ORACLE-Script catldr.sql im Verzeichnis <ORACLE_HOME>/rdbms/admin unter Unix, bzw. <ORACLE_HOME>\rdbms<nr>\admin unter Windows NT gelaufen sein.

Vorteile dieser Programme im Vergleich zu ORACLE export/import:

Beschleunigen des Exports/Imports von Objekten.

Die Daten werden automatisch nach dem Primärindex sortiert entladen und entsprechend auch wieder geladen. Somit kann beim Wiedererzeugen des Primärindexes die Option NOSORT verwendet werden, was die Phase der Indexerzeugung verkürzt. Anstelle des von SAPDBA automatisch gewählten Indexes für die Indexwiederherstellung mit NOSORT kann für jede Tabelle ein beliebiger Index (auch NONUNIQUE) manuell gewählt werden. Voraussetzung ist, daß alle Indexspalten NOT-NULL-Spalten sind. Stellen Sie dazu im Menü Transfer method for table data die Option Unload/load auf YES und die Option Index for sorted unload auf MANUALLY. Außerdem kann sich die Performance bei einigen Zugriffen auf Tabellendaten verbessern, weil die Daten sortiert vorliegen.

Kommt es zu einem Abbruch des Daten-Ladevorgangs mit SAP load oder ORACLE SQL*Loader, muß beim Restart nicht der gesamte Importvorgang wiederholt werden (wie beim ORACLE import), sondern es kann bei derjenigen Tabelle wiederaufgesetzt werden, bei der der Abbruch erfolgte.

Vereinfachte Reorganisation von Tabellen mit Feldern vom Typ LONG RAW.

Um Tablespaces zu reorganisieren, die Tabellen mit LONG RAW-Feldern beinhalten (z.B. PSAPPOOLD) mußte der DBA häufig manuell eingreifen (große Rollback-Segmente definieren, Parameter COMMIT im Script imp<TSP>.sh editieren, siehe z.B. Online-Hilfe des SAPDBA). Dieses Vorgehen ist bei Verwenden von SAP unload/SAP load bzw. SAP unload/SQL*Loader nicht mehr erforderlich, wenn die Menüoption commit=Y gewählt ist (entspricht der Voreinstellung).

SAP unload identifiziert anhand der Einträge im Script ldr<TSP>.par , welche Tabellen exportiert werden sollen. Wenn Sie SAP unload starten, können Sie anhand der Bildschirmausgabe verfolgen, wie groß die einzelnen Objekte sind und wie schnell diese exportiert werden konnten. Für die Objekte in dem entsprechenden Script ldr<TSP>.par wird von SAPDBA die durchschnittliche Rate des Entladens ermittelt. Somit können Sie sehr einfach Erfahrungswerte über die für den Export/Import benötigte Zeit sammeln.

Derzeit gibt es in Verbindung mit SAPDBA unload/SAP load bzw. SQL*Loader nicht die Möglichkeit zum Chop wie bei Export/Import, d.h. es können nur Tabellen entladen/geladen werden, deren Datenmenge im entladenen Zustand kleiner als die maximal im Betriebssystem zulässige Dateigröße ist. Immer mehr Betriebssysteme lassen Dateien >2GB (die früher übliche Grenze) zu.

Skripte/Protokolle

Eine Beschreibung der Scripte bzw. Protokolle für den Fall des Verwendens von ORACLE export/import finden Sie in Scripte/Dateien des SAPDBA bzw. Übersicht über die Protokolle. Im Folgenden finden Sie einige Hinweise zum veränderten Verhalten beim Abarbeiten der entsprechenden Scripte, wenn Sie SAP unload/SAP load bzw. SAP unload/SQL*Loader einsetzen.

Gegenüberstellung der Scripte/Protokolle bei Verwenden von:

ORACLE export/import	*SAP unload/SAP load bzw. SAP unload/SQLLoader**
exp/imp<TSP>.sh	unl/ldr<TSP>.sh (Pseudo-Shellscripte)
exp<TSP>.par	ldr<TSP>.par
exc/imc<TSP>.sh	existieren nicht, da die Komprimierung und R3chop bei Verwenden von SAP unload noch nicht unterstützt wird
exp<TSP>.dmp (Datei)	ldr<TSP>.dmp (Unterverzeichnis)
exp/imp<TSP>.log (temporäre Protokolle, wenn	ldr<TSP>.log parallel gearbeitet wird)
imx<TSP>.sh inx<TSP>.sql	existieren nicht (für SAP unload ist noch keine Check-Option implementiert)

Im Unterverzeichnis ldr<TSP>.dmp werden für jede zu reorganisierende Tabelle die folgenden Dateien erstellt:

<OWNER>_<TABLENAME>.dat	Unload Dump-Datei
<OWNER>_<TABLENAME>.ctl	Control file für SAP load/SQL*Loader
<OWNER>_<TABLENAME>.log	Detail-Protokoll des SAP unload/SAP load
<OWNER>_<TABLENAME>.ldr	Protokoll des SQL*Loaders
<OWNER>_<TABLENAME>.bad	Bei Fehlern des SQL*Loaders: Datendatei mit dem ersten fehlerhaften Satz
<OWNER>_<TABLENAME>.dsc	Bei Fehlern des SQL*Loaders: Datendatei mit dem ersten abgewiesenen Satz

Die Programme SAP unload/SAP load bzw. SAP unload/SQL*Loader erkennen anhand der Informationen in ldr<TSP>.par , welche Objekte mit SAP unload exportiert und mit SAP load bzw. SQL*Loader importiert werden sollen bzw. bereits wurden.

Phase des Entladens

Der Vorgang des Entladens mit SAP unload wird in der Restart-Datei durch das Pseudo-Script unl<TSP>.sh markiert. In diesem Script stehen (im Gegensatz zu exp<TSP>.sh ) keine expliziten Aufrufbefehle, da die Befehle zum Entladen von SAPDBA generiert werden. Das Script unl<TSP>.sh erhält in der entsprechenden Restart-Datei solange das Kennzeichen N, bis alle Objekte in ldr<TSP>.par erfolgreich abgearbeitet wurden, d.h. alle Tabellen das Kennzeichen Y erhalten haben.

Dieses Kennzeichen in ldr<TSP>.par vor dem Tabellennamen gibt an, ob das Objekt mit SAP unload erfolgreich exportiert wurde oder nicht.

N	Tabelle wurde noch nicht bearbeitet bzw. konnte nicht erfolgreich exportiert werden.
Y	Tabelle wurde erfolgreich mit SAP unload exportiert.

Konnten alle Tabellen erfolgreich mit SAP unload bearbeitet werden, erhält das Script unl<TSP>.sh das Kennzeichen Y und die Kennzeichen in ldr<TSP>.par werden für alle Tabellen wieder auf N gesetzt.

Phase des Ladens

Der Vorgang des Ladens mit SAP load bzw. SQL*Loader wird in der Restart-Datei durch das Pseudo-Script ldr<TSP>.sh markiert. In diesem Script stehen (im Gegensatz zu imp<TSP>.sh ) keine expliziten Aufrufbefehle, da die Befehle zum Laden von SAPDBA generiert werden. Das Script ldr<TSP>.sh erhält in der entsprechenden Restart-Datei das Kennzeichen S, wenn der Ladevorgang gestartet wird. Erst wenn alle Objekte in ldr<TSP>.par erfolgreich abgearbeitet wurden (d.h. alle Tabellen das Kennzeichen Y erhalten haben), wird das Kennzeichen für ldr<TSP>.sh auf Y gesetzt.

Y/N/S

Dieses Kennzeichen in ldr<TSP>.par vor dem Tabellennamen gibt an, ob das Objekt mit SAP load/SQL*Loader erfolgreich importiert wurde oder nicht.

N	Tabelle wurde noch nicht bearbeitet bzw. konnte nicht erfolgreich geladen werden.
S	Es wurde begonnen, diese Tabelle zu bearbeiten. Die Tabelle konnte jedoch nicht erfolgreich geladen werden.
Y	Tabelle wurde erfolgreich mit SAP load/SQL*Loader importiert.

Konnten alle Tabellen erfolgreich mit SAP load/SQL*Loader bearbeitet werden, erhält das Script ldr<TSP>.sh im Restart-Plan das Kennzeichen Y.

Dieses Kennzeichen in ldr<TSP>.par gibt an, mit welchem Werkzeug geladen wird. Sie können dieses Kennzeichen vor einem Restart manuell editieren.

*	SQL*Loader
-	SAP load

Informationen zum Restart einer Reorganisation finden Sie in Restart einer Reorganisation.