Schlüsselworte Data Guard, Standby Datenbank, RMAN, Backup, Restore, Recovery

Transkript

1 Betrifft Standby Datenbanken Backup Art der Info Lösungskonzept (November 2002) Autor Irina Flegler Martin Wunderli Quelle Beratungstätigkeit Schlüsselworte Data Guard, Standby Datenbank, RMAN, Backup, Restore, Recovery Die Idee Die Belastung eines Datenbankservers lässt sich im Wesentlichen mit der I/O Belastung und der Belastung der CPU messen. Dabei spielt in der Regel die I/O Belastung eine grössere Rolle und bildet den Flaschenhals bezüglich der Gesamtperformance des Systems. Der DBA wird also immer versuchen, die I/O Belastung soweit wie möglich zu reduzieren. Standby Datenbanken (sei es in der klassischen Form bis Oracle8i oder unter der Obhut des Data Guards ab Oracle9i) bieten hierzu eine interessante Möglichkeit: Das Backup der Datenbank auf dem Standby Server durchführen und nicht auf dem Primary Server. Primary Standby Online Archived Archived Es ist offensichtlich: Bis auf die Applizierung der archivierten Dateien (eine physische Standby Datenbank befindet sich im Recovery Modus) oder die Applizierung der extrahierten DML Statements (im Falle der logischen Standby Datenbank) tut die Standby Datenbank eigentlich nichts. Unser Ziel ist also, die Arbeit etwas gleichmässiger zu verteilen. Die Implementation Wir empfehlen, zur Sicherung der Standby Datenbank den Recovery Manager (RMAN) zu benutzen. Damit hat man neben dem quasi geschenkten Corruption Check der gesicherten

2 Datenbankblöcke die Möglichkeit, inkrementelle Backups durchzuführen und bei korrupten Blöcken diese online reparieren zu können. Wir konzentrieren uns in diesem Artikel daher auch ausschliesslich auf RMAN Sicherungen und gehen von einem RMAN Grundverständnis aus (Mehr zu Backup/Recovery im Allgemeinen und RMAN im Speziellen in unserem Kurs 'Backup und Recovery'). To Catalog or not to catalog Wir können unser Sicherungskonzept mit und ohne RMAN Katalog implementieren. Grundsätzlich ist ja ein RMAN Katalog weder für die Sicherung noch für die Recovery notwendig (selbst wenn die Sicherung mit Katalog durchgeführt wurde), er macht aber das Handling der Backups und Recoveries gerade in nicht-trivialen Szenarien (Point-In-Time Recoveries, Verlust der Controlfiles etc.) sehr viel einfacher. Arbeiten wir also mit einem Katalog, so muss die Primary Datenbank im Katalog registriert werden. register database; Die Standby Datenbank kann man übrigends nicht registrieren, register bricht hier mit dem Fehler 'controlfile is not current or backup' ab. Backup Um die Standby Datenbank zu sichern, muss sie zumindest als Standby Datenbank gemounted sein. Wir sichern hier die Datenbankdateien und die archivierten Dateien (für das Löschen der archivierten Dateien auf dem Primary Server muss man zusätzlich sorgen!). backup database format '/u00/app/oracle/admin/db4/backup/full_%d_%t_s%s_p%p'; backup archivelog all delete input format '/u00/app/oracle/admin/db4/backup/arc_%d_%t_s%s_p%p'; Das Controlfile kann man auf der Standby Datenbank nicht sichern: ORA-00236: snapshot operation disallowed: mounted controlfile is a backup Auf der Primary Datenbank ist das natürlich kein Problem: backup current controlfile format '/u00/app/oracle/admin/db4/backup/ctl_%d_%t_s%s_p%p';

3 Dadurch, dass wir mit einem Katalog verbunden sind, wird eine RMAN Session auf der Primary Database die auf der Standby Database gemachten Backups sehen: RMAN> list backup of database; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time Full 149M DISK 00:03:02 02-DEC-02 BP Key: Status: AVAILABLE Tag: TAG T Piece Name: /u00/app/oracle/admin/db4/backup/full_db4_ _s29_p1 List of Datafiles in backup set File LV Type Ckp SCN Ckp Time Name Full DEC-02 /u00/oradata/db4/system01db4.dbf 2 Full DEC-02 /u00/oradata/db4/undo01db4.dbf 3 Full DEC-02 /u00/oradata/db4/tools01db4.dbf 4 Full DEC-02 /u00/oradata/db4/users01db4.dbf 5 Full DEC-02 Analoges gilt für Controlfiles und archivierte Dateien. Was ist aber, wenn wir keinen Katalog benutzen? Die erstellten Backups sind dann ja nur im Standby Controlfile registriert und sonst nirgends! Genau dieses Controlfile können wir mit dem RMAN aber nicht sichern (siehe oben). Spätestens hier sollte auch der grösste RMAN Katalog Hasser aufgeben und einen Katalog erstellen. Es gibt aber doch eine Möglichkeit, das Standby Controlfile zu sichern: Im SQLPLUS. alter database backup controlfile to '/u00/app/oracle/admin/db4/backup/ctl_%d_%t_s%s_p%p'; Zu beachten ist hier, dass ein Standby Controlfile gesichert wird, kein normales. D.h. es kann nicht direkt für die komplette Recovery einer Primary Datenbank verwendet werden! Recovery Im einfachsten Fall eines Dateiverlustes auf der Primary Datenbank braucht es gar kein Restore durch den RMAN: Man kopiert einfach die entsprechende Datei von der Standby Datenbank zur Primary Datenbank und recovered im RMAN. Fertig (Aber nicht dass jemand jetzt auf die Idee kommt, mit einer Standby Datenbank bräuchte es keine Backups mehr! ). Stehen die Dateien der Standby Datenbank für die Recovery nicht zur Verfügung, so kann ganz normales, klassisches RMAN Restore/Recovery mit Katalog durchgeführt werden. Für den Fall einer incomplete Recovery muss man die Standby Datenbank danach wieder neu aufsetzen. Selbstverständlich ist es auch möglich, die Standby Datenbank zu aktivieren (Failover) und danach eine neue Standby Datenbank aufzusetzen. Dies ist aber je nach Umgebung nicht wünschenswert/machbar.

4 Bei dem im letzten Abschnitt beschriebenen Setup ohne Katalog und Sichern des Standby Controlfile aus SQLPLUS, kann die Recovery der Primary Datenbank folgendermassen durchgeführt werden: Systemparameter DG_BROKER_START=FALSE Controlfiles sichern (falls noch vorhanden) Standby Controlfile restaurieren Datenbankinstanz starten und als Standby mounten Datenfiles und archivierte Dateien restaurieren Instanz stoppen, vorher gesicherte Controlfiles (falls vorhanden) zurückholen und Recovery durchführen Datenbank öffnen Systemparameter DG_BROKER_START=TRUE, falls Datenbank nicht mit RESETLOGS geöffnet wurde (andernfalls Standby Datenbank neu aufbauen) Wir hoffen, dass dieses Vorgehen abschreckt und zum Katalog motiviert! Ein Problemchen noch Erzeugt man auf der Primary Datenbank einen neuen Tablespace, führt einen Logfile Switch durch und möchte diesen Tablespace auf der Standby Datenbank sichern, so bricht RMAN in der Version mit einem Fehler ab: RMAN> backup tablespace test;... ORA-19573: cannot obtain sub-shared enqueue for datafile 6 Dieses Verhalten wurde inzwischen als Bug (TAR ) akzeptiert. Es gibt aber einen Workaround: Stoppen und Starten der Standby Datenbank, danach funktioniert das Backup. Fazit Wie wir gesehen haben, erfordert die Verlagerung des Backups auf den Standby Server nur einen geringen Aufwand. Der Nutzen der Reduzierung des I/Os ist daher sehr günstig erkauft und sollte unbedingt in Betracht gezogen werden. Wie immer im Bereich von Backup und Recovery gilt aber: 'Üben, üben, üben' sowie 'Testen, testen, testen'! Die Verteilung der I/O Last kann man übrigends noch weiter treiben: Reports, die keine Änderungen an der Datenbank bewirken, können auf eine logische Standby Datenbank ausgelagert werden, eine Datenbank, die gleichzeitig Änderungen applizieren und Anfragen bearbeiten kann. Doch dazu im nächsten Newsletter mehr. Falls Sie an weiteren Informationen zu Hochverfügbarkeit interessiert sind, empfehlen wir Ihnen unseren 3-tägigen Kurs AI9-B-DBA. Wir sind auch gerne bereit, In-House ein 1- tägiges Seminar zum Thema Oracle9i Release 2 Hochverfügbarkeit durchzuführen.

5 Irina Flegler und Martin Wunderli Trivadis GmbH Irina Flegler Mail: Max-Lang Strasse 56 Tel: D Leinfelden-Echterdingen Fax: Trivadis AG Dr. Martin Wunderli Mail: Kanalstrasse 5 Tel: CH-8152 Glattbrugg Fax: Internet: