Mit der Utility-Anweisung COPY kann der Datenbankverwalter SESAM-Sicherungsbestände der gesamten SESAM/SQL-Datenbank oder von Teilen der Datenbank wie Catalog-Space und Anwender-Spaces erstellen. Die SESAM-Sicherungsbestände legt SESAM/SQL wahlweise auf Magnetbandkassette oder Platte an. Das Erstellen eines SESAM-Sicherungsbestandes kann im Modus online oder im Modus offline erfolgen. Auch die Sicherung mit HSMS von Spiegelplatten eines lokalen oder entfernten Storage-Systems ist möglich. Ferner kann der Datenbankverwalter den SESAM-Sicherungsbestand auf formale Korrektheit prüfen und veranlassen, dass ein Anwender-Space oder der Catalog-Space nach der Erstellung der Kopie mit Logging betrieben werden. Spaces, auf denen nur Indizes liegen und die nicht in der logischen Datensicherung sind, können von der Sicherung ausgenommen werden.
Liegt die Datenbank in einer DB-Kennung, so versucht SESAM/SQL immer zuerst, den SE-SAM-Sicherungsbestand in der DB-Kennung anzulegen. Das ist nur möglich, wenn die Vorbereitungen für das Anlegen der Dateien getroffen worden sind, siehe Abschnitt „Datenbankdateien und Jobvariablen auf fremden Benutzerkennungen“. Andernfalls werden die Kopien in der DBH-Kennung angelegt.
Falls das Logging eingeschaltet ist, ist mit COPY CATALOG und COPY CATALOG_SPACE stets ein Wechsel der CAT-LOG-Datei und DA-LOG-Datei verbunden.
Bei Datenbanken, die ohne Logging betrieben werden, richtet SESAM/SQL beim ersten COPY CATALOG bzw. COPY CATALOG_SPACE die CAT-REC-Datei gemäß den Angaben in der Medientabelle ein.
Als Aufsetzpunkt für Replikate wird bei jedem COPY CATALOG und COPY CATALOG_SPACE eine CAT-REC-Kopie auf den gleichen Medien angelegt wie die CAT-LOG-Datei. Es werden keine Metadaten über diese zusätzlichen Kopien hinterlegt. Soll die CAT-REC-Kopie auf der DB-Kennung liegen, so gilt das oben Ausgeführte. Eine von einem früheren COPY vorhandene CAT-REC-Kopie wird überschrieben.
SESAM-Sicherungsbestände auf Magnetbandkassette können über die Utility-Anweisung COPY ... USING DIRECTORY wahlweise mit Hilfe der Softwareprodukte HSMS oder ARCHIVE erstellt werden (siehe Handbuch „ SQL-Sprachbeschreibung Teil 2: Utilities“). Ist eine HSMS-Parameterdatei vorhanden, wird ein für COPY ... USING DIRECTORY angegebener Name als HSMS-Archiv betrachtet. Andernfalls erfolgt die Sicherung mit ARCHIVE.
SESAM-Sicherungsbestand online oder offline erstellen
Bei der Ausführung von COPY erzeugt SESAM/SQL zunächst einen transaktionslosen Zustand auf den von COPY betroffenen Spaces (Catalog-Space bzw. Anwender-Spaces).
Bei COPY ONLINE sind folgende Effekte zu beachten:
SESAM/SQL lässt mit Beginn der Kopieerstellung wieder SQL-Anweisungen zum Abfragen und Ändern von Daten sowie CALL-DML-Anweisungen zu. Alle anderen SQL-Anweisungen und alle Utility-Anweisungen weist SESAM/SQL weiterhin mit SQL-Statuscode ab.
Soll die Online-Sicherung in ein HSMS-Archiv erfolgen, so dürfen die zu sichernden Datenbank-Dateien nicht auf Privatplatte liegen.
Alle Blöcke der zu kopierenden Anwender-Spaces, die während des Kopiervorgangs geändert werden, protokolliert SESAM/SQL vor ihrer Änderung als sog. physikalische Before Images (PBI) in der PBI-Datei (bei Plattenkopie und ARCHIVE) bzw. sie werden von HSMS in die HSMS-Arbeitsdatei protokolliert. Diese Datei wird immer in der Benutzerkennung angelegt, in der der DBH abläuft. Mit Abschluss des Kopiervorgangs beendet SESAM/SQL diese PBI-Protokollierung und gibt die betroffenen Anwender-Spaces wieder für alle Anweisungen frei.
Bei einem SESAM-Sicherungsbestand auf Platte spielt SESAM/SQL die protokollierten Before Images sofort in den SESAM-Sicherungsbestand ein, so dass dieser SESAM-Sicherungsbestand denselben Stand aufweist wie der zugehörige Anwender-Space im transaktionsfreien Zustand unmittelbar vor dem eigentlichen Kopiervorgang. Bei einem SESAM-Sicherungsbestand auf Magnetbandkassette mit ARCHIVE sichert SESAM/SQL die PBI-Datei ebenfalls auf eine separate Magnetbandkassette. Das Einspielen der Datei erfolgt in diesem Fall erst bei der Reparatur bzw. bei dem Zurücksetzen mit der Utility-Anweisung RECOVER.
Bei der Sicherung in ein HSMS-Archiv wird der zu sichernde Block von der Datenbankdatei oder von der HSMS-Arbeitsdatei gelesen und anschließend gesichert. Von einem bestimmten SESAM/SQL-DBH können gleichzeitig mehrere Utility-Anweisungen COPY ONLINE ausgeführt werden. Sie müssen sich auf die Spaces unterschiedlicher Datenbanken beziehen.Bei COPY OFFLINE hält SESAM/SQL sämtliche ändernden Zugriffe auf die von COPY OFFLINE betroffenen Anwender-Spaces bzw. den Catalog-Space zurück bis der COPY OFFLINE abgeschlossen ist.
Der Stand des SESAM-Sicherungsbestandes entspricht dem Zustand des zugehörigen Space bzw. der zugehörigen Spaces im transaktionskonsistenten Zustand unmittelbar vor dem eigentlichen Kopiervorgang.
SESAM-Sicherungsbestand mit HSMS von Spiegelplatten erstellen
Mit folgender Anweisung können Datenbank-Dateien, die auf einer Spiegelplatte liegen, sehr performant in ein HSMS-Archiv auf Platte oder Magnetbandkassette gesichert werden:
COPY ... USING DIRECTORY hsms_archiv_name {BY_ADD_MIRROR_UNIT | BY_SRDF_TARGET}
Abhängig von der örtlichen Lage der Spiegelplatte sind zwei Fälle zu unterscheiden (hier am Beispiel der Symmetrix-Funktion TimeFinder/Mirror erläutert):
BY_ADD_MIRROR_UNIT
In diesem Fall wird im laufenden Betrieb die Funktion TimeFinder/Mirror (Symmetrix Multi Mirror Facility) der Symmetrix-Systeme genutzt. Der Datenbankbetrieb läuft auf der sogenannten Normal-Unit in der Local-Symmetrix. Zur Datenspiegelung wird eine zusätzliche Platte in der Local-Symmetrix, die sogenannte Additional-Mirror-Unit, verwendet. Das Paar Normal-Unit und Additional-Mirror-Unit wird als Multi-Mirror-Paar bezeichnet.
Bild 30: Konfiguration mit TimeFinder
BY_SRDF_TARGET
In diesem Fall wird im laufenden Betrieb die Funktion SRDF (Symmetrix Remote Data Facility) der Symmetrix-Systeme genutzt. Der Datenbankbetrieb läuft auf der sogenannten Source-Unit in der Local-Symmetrix. Zur Datenspiegelung wird eine zusätzliche Platte in der (entfernten) Remote-Symmetrix, die sogenannte Target-Unit, verwendet. Das Paar Source-Unit und Target-Unit wird als Remote-Copy-Paar bezeichnet.Das Remote-Copy-Paar muss im synchronen Verarbeitungsmodus betrieben werden.Das HSMS-Archiv muss auf dem gleichen System liegen, an das die Source-Unit angeschlossen ist.Zum Erstellen eines SESAM-Sicherungsbestandes ist es erforderlich, dass der TargetUnit in der Remote-Symmetrix eine Additional-Mirror-Unit zugewiesen ist. D.h. Target-Unit und Additional-Mirror-Unit liegen beide in der Remote-Symmetrix und bilden dort ein Multi-Mirror-Paar (TimeFinder/Mirror).
Bild 31: Konfiguration mit SRDF und TimeFinder
Bemerkung: Zur weiteren Datenspiegelung in der Local-Symmetrix kann zur SourceUnit zusätzlich eine Additional-Mirror-Unit (TimeFinder/Mirror) betrieben werden. Auch von ihr könnte mit BY_ADD_MIRROR_UNIT ein SESAM-Sicherungsbestand erstellt werden (im Bild grau hinterlegt, in der weiteren Betrachtung ohne Bedeutung).
In beiden Fällen wird der SESAM-Sicherungsbestand von der Additional-Mirror-Unit mit HSMS erstellt. Die Datenbankdateien müssen auf derselben Additional-Mirror-Unit liegen.
Soweit in der folgenden Beschreibung von Spiegelplatten gesprochen wird, sind AdditionalMirror-Units (Symmetrix-Systeme) oder Clone-Units (ETERNUS DX-, Symmetrix- oder CLARiiON CX-Systeme) gleichermaßen gemeint.
Nähere Informationen zu diesen Storage-Systemen sowie zu ihren Replikations-Funktionen finden Sie im Handbuch „ SHC-OSD (BS2000)“.
Ablauf der Sicherung mit HSMS von Spiegelplatten
Die Sicherung erfolgt in drei Phasen:
Zuerst wird die Spiegelplatte von der Normal-Unit (Fall 1 im vorangehenden Abschnitt) bzw. der Target-Unit (Fall 2) getrennt. Dabei sind lesende DML-Zugriffe auf die Datenbank möglich.
Die angegebenen Datenbankdateien werden von der Spiegelplatte in das angegebene HSMS-Archiv gesichert.
Die Datenbank auf der Normal-Unit (Fall 1) bzw. der Source-Unit (Fall 2) wird vom DBH prozessiert. Die Spiegelung auf die Target-Unit (Fall 2) wird fortgeführt. Während der Dauer der Sicherung sind lesende Zugriffe (bei COPY ... OFFLINE) oder auch ändernde DML-Zugriffe (bei COPY ... ONLINE) auf die Datenbank möglich.Nachdem die Sicherung in das HSMS-Archiv erfolgt ist, werden die Spiegelplatte und die Normal-Unit (Fall 1) bzw. die Target-Unit (Fall 2) wieder synchronisiert. Auch während dieser Zeit sind lesende oder ändernde Zugriffe möglich.
SESAM/SQL nutzt bei der Ausführung der COPY-Anweisung die Funktion Concurrent Copy (CCOPY) von HSMS. HSMS nutzt seinerseits das Softwareprodukt SHC-OSD. Für die Sicherung in ein HSMS-Archiv baut SESAM/SQL die HSMS Anweisung BACKUP-FI-LES mit dem Parameter WRITE-CHECKPOINTS=*YES auf, um Wiederaufsetzpunkte zu schreiben. Damit kann nach einem Abbruch der HSMS-Sicherungslauf mit der HSMS-Anweisung RESTART-REQUESTS fortgesetzt werden (weitere Informationen dazu finden Sie im Handbuch „ HSMS (BS2000)“, Band 1).
Der Vorteil dieses Verfahrens ist, dass der Datenbankverwalter sich weder um die Trennung noch um die Synchronisation der Spiegelplatte kümmern muss.
Für diese Funktion benötigt die DBH-Task eines der Privilegien TSOS oder HSMS-ADMINISTRATION.
Bild 32: Ablauf der Sicherung mit HSMS von Additional-Mirror-Units
Initialisierungsphase: Zeit vom Beginn der COPY-Anweisung bis zur Trennung der Spiegelplatten. In dieser Phase sind nur lesende Zugriffe auf die zu sichernden Spaces möglich. Ändernde Zugriffe warten auf das Ende der Initialisierungsphase. SE-SAM/SQL baut die HSMS-Anweisung BACKUP-FILES auf.
Sicherungs- und Betriebsphase: Zeit, in der HSMS-Sicherung und Datenbankbetrieb parallel laufen. HSMS sichert die Datenbankdateien von der Spiegelplatte in ein HSMS-Archiv. Die Datenbank auf der Normal-Unit bzw. der Source-Unit wird parallel dazu vom DBH prozessiert. Ändernde DML-Anweisungen sind bei COPY ONLINE wieder zugelassen.
Synchronisationsphase: Zeit vom Ende der HSMS-Sicherung bis zum Abschluss der Synchronisation der Spiegelplatten. Nach der HSMS-Sicherung werden die Spiegelplatten wieder synchronisiert. Lesende und ändernde DML-Anweisungen sind weiter möglich.
Die Sicherung war erfolgreich, wenn die Sicherung in das HSMS-Archiv erfolgreich war und die Formalprüfung bei Angabe des Parameters CHECK FORMAL zu keinem Fehler geführt hat. Die erfolgreiche Sicherung wird in die RECOVERY_UNITS eingetragen.
Hinweise zur Sicherung mit dem Parameter CHECK FORMAL
Bei einer Online-Sicherung mit HSMS von Spiegelplatten kann der Parameter CHECK FORMAL angegeben werden. Wenn die Source- oder Normal-Unit zu einem shared Pubset gehört, dann muss der SESAM/SQL-DBH auf dem Server ablaufen, der für das shared Pubset die Master-Seite darstellt. Die formale Prüfung auf den zu sichernden Spaces wird auf der abgetrennten AdditionalMirror-Unit parallel zur Sicherung der Dateien in das HSMS-Archiv durchgeführt.
Sonst darf der Parameter bei einer Online-Sicherung auf Magnetbandkassette nicht angegeben werden.
Wird bei einer Offline-Sicherung auf Magnetbandkassette der Parameter CHECK FORMAL angegeben, so wird zuerst die formale Prüfung auf den zu sichernden Spaces durchgeführt und anschließend der Auftrag an HSMS gegeben. Dies führt dazu, dass die zu sichernden Spaces so lange gesperrt sind bis die formale Prüfung abgeschlossen ist. Erst dann wird mit der Trennung der Platten begonnen.
Deshalb sollten Sie bei entsprechenden Voraussetzungen der Online-Sicherung mit HSMS von Spiegelplatten den Vorzug geben.
Sonst wird bei einer Offline-Sicherung folgendes Vorgehen empfohlen:
Die Sicherung sollte mit NO CHECK FORMAL erzeugt werden. Anschließend sollte der Datenbankverwalter die Sicherung aus dem HSMS-Archiv wieder einspielen, die Datenbank in das SQL-Datenbankverzeichnis eines anderen DBH eintragen und die formale Prüfung durchführen.
Wird bei einer Formalprüfung ein Fehler gefunden, so war die Sicherung nicht erfolgreich; der Originalspace wird aber nicht als defekt gekennzeichnet.