Ablauf einer Reorganisation (SAP-Bibliothek - Datenbankverwaltung (Oracle) mit SAPDBA)

Ablauf einer Reorganisation

Vorbereitungsphase (Erstellung aller Scripte)

Alle Reorganisationen (außer die Optionen Resize und Move/Rename) werden durchgeführt, indem die Export-Dumpdateien der Objekte in ein oder mehrere Verzeichnisse (Angabe von Bandstationen ist ebenfalls möglich) geschrieben werden. Die Verzeichnisse (Bänder) müssen groß genug für die zu reorganisierenden Objekte sein. Die Scripte hingegen werden immer im Arbeitsverzeichnis (working directory) auf der Platte abgelegt. Der Export/Import kann parallelisiert werden, indem der Parallelitätsgrad exp_imp_degree >1 gesetzt wird und die Anzahl der Dumpdateien >1 ist. Siehe Paralleler Export/Import.

Beim Start einer Reorganisation wird geprüft, ob ein Benutzer sapr3 an die Datenbank angemeldet ist (d.h. ob ein R/3-System läuft). SAPDBA gibt entsprechende Warnungen aus.

SAPDBA erzeugt die für den Reorganisationsprozeß erforderlichen Scripte.
SAPDBA prüft dabei, ob der Speicherplatz im Tablespace ausreichend ist (z.B. könnte es sein, daß durch die Komprimierung von Extents eines Objektes in ein Extent dieses nicht angelegt werden kann, weil der größte zur Verfügung stehende Freiplatzbereich dafür zu klein ist).

Vor dem Starten des Reorganisationsprozesses prüft SAPDBA, ob die reorganisierten Daten in die zur Verfügung stehende/n Datendatei/en passen.

Besonderheiten bei Tablespace-Reorganisation mit Datendateien:

Sie können die Voreinstellungen für die Dateigröße und das Dateiverzeichnis verändern. So können Sie durch entsprechende Verteilung der Dateien Ihren Plattenplatz optimal ausnutzen.

Sie können die Anzahl der Datendateien, deren jeweilige Größe und ihren Pfad ändern. Bedingung ist, daß jede der Dateien kleiner als 2 GB ist und daß mindestens eine Datendatei angelegt wird. SAPDBA führt eine Platzprüfung in allen notwendigen Dateisystemen durch und erzeugt Links, wenn neue Verzeichnisse angegeben wurden, die nicht den SAP-Namenskonventionen genügen.

Nach erfolgreichem Ablauf aller Prüfungen können Sie entscheiden, ob und wann Sie die eigentliche Reorganisation (Hauptphase) starten wollen:

direkt ( Start script(s) immediately )

nachdem sie im Hintergrund eingeplant wurde ( Start script(s) in batch )

nicht oder zu einem späteren Zeitpunkt über die Restart-Funktion ( End (later restart is possible) )

Hauptphase (Abarbeitung der erstellten Scripte)

SAPDBA führt die Reorganisation (außer die Option Resize) gemäß der erstellten Scripte durch. Wenn ein Benutzer sapr3 an die Datenbank angemeldet ist, wird eine Reorganisation eines Tablespaces (mit oder ohne Datendateien) bei Start der Hauptphase abgebrochen.

Nach dem Export wird das zu reorganisierende Objekt aus der Datenbank gelöscht. Die physischen Datendateien werden bei einer Reorganisation mit Datendateien ebenfalls gelöscht. Da Tabellen und Indizes aus der Datenbank entfernt werden, sollten Sie sich an das Sicherungskonzept bei Reorganisationen halten.

Schließlich werden die Daten in das reorganisierte Objekt zurückimportiert. Damit ist die Reorganisation abgeschlossen.

Nach einer Strukturänderung der Datenbank (Reorganisation von Tablespaces mit Datendateien) sollten Sie eine Vollsicherung der Datenbank durchführen, mindestens jedoch den betroffenen Tablespace sichern. Siehe Sicherungskonzept bei Reorganisationen.

Besonderheiten bei Reorganisation im Hintergrund:

Wenn Sie den Reorganisationsprozeß im Hintergrund laufen lassen wollen, informieren Sie sich bitte über die dazu notwendige Konfiguration des Kommandos at (siehe z.B. Konfiguration des UNIX-Kommandos at). Die mittels at erstellten Jobs sind transparent und können demzufolge mit Betriebssystem-Mitteln angezeigt werden. Sie finden in einer solchen Datei die notwendigen Umgebungsvariablen und den Befehl
sapdba -r <vollständiger Pfad/Zeitstempel> , um die Reorganisation zu starten.

Beachten Sie, daß Tabellen und Indizes, die zwar vor der Reorganisation aber nach dem Erstellen der Scripte erzeugt wurden, bei der später im Hintergrund ablaufenden Reorganisation nicht berücksichtigt werden.
Bei einer Tablespace-Reorganisation ohne Datendateien kann dies zum Abbruch mangels Speicherplatz führen. Bei einer Tablespace-Reorganisation inklusive Datendateien gehen solche nachträglich erzeugten Objekte einschließlich ihrer Daten verloren. Planen Sie deshalb nur dann Reorganisationen für einen späteren Zeitpunkt ein, wenn Sie zwischenzeitlich keine neuen Objekte erzeugen.

Wenn Sie mehrere Reorganisationen hintereinander zu einem späteren Zeitpunkt einplanen, ist darauf zu achten, daß das nur dann risikolos möglich ist, wenn:

die Export-Dumpdateien für die einzelnen Reorganisationen auf verschiedenen Platten liegen.
bei einer Reorganisation mit Datendateien die alten und neuen Dateien der Tablespaces jeweils auf verschiedenen Platten liegen.

Beim Einplanen mehrerer Reorganisationen hintereinander sollten die Zeitabstände so gewählt werden, daß sich die einzelnen Prozesse nicht überlappen. Ein paralleles Durchführen mehrerer Reorganisationen ist weiterhin nicht erlaubt, da es möglicherweise zu Engpässen im ORACLE-Dictionary oder zu falscher Platzprüfung kommen kann.

Beim Einplanen der Reorganisation helfen Ihnen die Laufzeiteinträge im zentralen Protokoll reorg<DBSID>.log (siehe Zentrales Protokoll).

Siehe auch Abläufe im Detail.