data guard 11.2: flashback database und snapshot … · einem zeitpunkt in der (nahen)...
TRANSCRIPT
Data Guard 11.2: Flashback Database und Snapshot
Standby im SAP-Umfeld
Dr. Thimo Bastuck
Freudenberg IT
Weinheim
Claudia Hüffer
Oracle Deutschland B.V. & Co. KG
Hamburg
Schlüsselworte:
Oracle 11gR2, SAP, Flashback Database, Oracle Data Guard, Physical Standby Datenbank, Snapshot
Standby
1. Einleitung
Bei der Freudenberg IT, dem einzigen SAP Global Hosting Partner mit einer klaren Mittelstands-
ausrichtung, kommt Oracle bereits seit Jahren in zahlreichen gehosteten Kundenumgebungen
erfolgreich unter SAP zum Einsatz.
Seit Frühjahr 2010 unterstützt SAP die Oracle Datenbank 11g R2 für SAP Produkte basierend auf dem
SAP Kernel 6.40, 7.x und höher. Mit Oracle 11g R2 Enterprise Edition für SAP stehen den SAP
Kunden neben bewährten Technologien auch einige neue Funktionen und Optionen zur Verfügung.
Im Bereich Hochverfügbarkeit können hier unter anderem Flashback Database und Oracle Data Guard
Snapshot Standby genutzt werden. Flashback Database ist eine Komponente der Oracle Flashback
Funktionalitäten und ermöglicht ein schnelles Zurücksetzen der gesamten Datenbank auf einen Punkt
in der näheren Vergangenheit. Die Snapshot Standby Datenbank ist eine Teilfunktionalität der Oracle
Data Guard Physical Standby Datenbank. Sie erlaubt, das Standby Datenbank System temporär lesend
und schreibend (!) öffnen zu können. Während dieser Phase ist nun auch ein Zugriff über einen SAP-
Applikationsserver auf die „Standby Seite“ möglich. Dadurch werden Fehleranalyse oder Applika-
tionstests möglich. Im Anschluss an die Tests können durch ein Kommando alle durchgeführten
Änderungen verworfen werden, und die Umgebung kann wieder als Physical Standby Datenbank
betrieben werden. Oracle Data Guard Snapshot Standby ist auch mit Flashback Database
kombinierbar.
Im Rahmen des Vortrages werden beide Technologien zunächst erläutert. Vor dem Hintergrund von
gehosteten SAP Kundensystemen auf Basis der Oracle Datenbank werden verschiedene mögliche
Einsatzszenarien diskutiert.
2. Freudenberg IT
Freudenberg IT ist der international agierende Lösungsanbieter für Outsourcing und Consulting für
SAP und MES (Manufacturing Execution System).
Vorkonfektionierte Lösungen bieten die Sicherheit global funktionierender Standards. Freudenberg IT
kombiniert diese Standards mit maßgeschneiderten Elementen, um sie an die jeweiligen
Kundenbedürfnisse anzupassen. Das Unternehmen konzipiert, implementiert und optimiert IT-
Infrastrukturen, betreibt SAP im Applikationshosting und liefert entsprechende Application
Management Services. Mit der adicom® Software Suite bietet die Freudenberg IT mittelständischen
und großen Unternehmen eine ganzheitliche MES-Lösung für die Planung und Steuerung in den
Bereichen Produktion und Personal.
Freudenberg IT ist Teil der Unternehmensgruppe Freudenberg. Sie ist an 18 Standorten in Europa,
Amerika und in Asien vertreten und beschäftigt weltweit rund 600 Mitarbeiter.
3. Überblick Flashback Database und Snapshot Standby
Flashback Database ist eine Funktion der Flashback-Technologien der Oracle Datenbank. Snapshot
Standby ist Bestandteil von Oracle Data Guard, der Standby Datenbank Technologie. Die Flashback
Technologien und Oracle Data Guard sind Bestandteil der Oracle Hochverfügbarkeits-Lösungen.
Die meisten Flashback Technologien und Oracle Data Guard setzen die Oracle Enterprise Edition
voraus.
a. Flashback Database
Oracle Flashback Database ist Teil der Oracle Flashback Technologien. Diese Flashback
Technologien ermöglichen ein sehr flexibles Reagieren auf menschliche Fehler, die laut verschiedenen
Studien etwa 40% der Applikationsausfälle verursachen. In vielen Fällen führen diese Fehler zu
logischen Korruptionen der Daten, d.h. das eigentliche SQL-Statement ist aus Datenbanksicht
syntaktisch gültig und valide, führt jedoch auf Ebene der Applikation zu logischen Inkonsistenzen.
Beispiele typischer Benutzerfehler sind das irrtümliche Löschen von Datensätzen, das fehlerhafte
Verändern von Datensätzen oder das versehentliche Löschen von Tabellen. Die verschiedenen
Flashback Technologien von Oracle ermöglichen die Sicht auf historische Datenbestände, die
Durchführung von Änderungsanalysen, das Zurückholen bereits gelöschter Tabellen sowie das
schnelle Zurücksetzen der gesamten Datenbank auf einen Zeitpunkt in der Vergangenheit. Mit Oracle
9i wurde zunächst die Flashback Query Funktionalität eingeführt, die das Abfragen von Tabellen zu
einem Zeitpunkt in der (nahen) Vergangenheit ermöglicht. In Oracle 10g wurde die Flashback
Technologie dahingehend erweitert, dass nun ein Flashback durch alle Ebenen hindurch möglich
wurde: Datenbank, Tabelle, Zeile, Transaktion. Die mit Oracle 10g eingeführten Flashback
Erweiterungen sind: Flashback Database, Flashback Table, Flashback Drop, Flashback Versions
Query, Flashback Transaction Query.
Mit Oracle 11g wurde zusätzlich das Flashback Data Archive zur Aufbewahrung von Langzeit-
historischen Informationen über einzelne Tabellen und deren Änderungen eingeführt.
Der Vorteil der Flashback Technologien liegt darin, dass je nach Fehlersituation ganz gezielt ein
bestimmter Bereich der Datenbank quasi mit chirurgischen Mitteln repariert werden kann, ohne dass
ein globales Media-Recovery notwendig ist.
Folgende Flashback Technologien sind derzeit verfügbar:
Flashback Query: Flashback Query wurde mit Oracle 9i eingeführt und erlaubt die Abfrage
von Tabelleninhalten zu einem Zeitpunkt in der Vergangenheit. Die dafür relevanten
Informationen werden aus dem UNDO-Tablespace der Datenbank selektiert. Die Größe des
UNDO-Tablespace und die eingestellte Retention-Time (UNDO_RETENTION) sind ein Maß
dafür, wie weit eine Benutzerabfrage in die Vergangenheit zurückgehen kann. Voraussetzung
für die Verwendung von Flashback Query ist, dass die UNDO-Tablespaces verwendet werden
(UNDO_MANAGEMENT =AUTO). Mit Flashback Query kann man Daten, wie sie in der
(nahen) Vergangenheit existierten, selektieren, Vergleiche zwischen altem und aktuellem
Datenbestand durchführen und im Fehlerfall sehr einfach den alten Datenbestand
wiederherstellen. Das SQL-Statement für eine Flashback Query sieht folgendermaßen aus: „SELECT * FROM employee AS OF TIMESTAMP TO_TIMESTAMP(‟19-APR-05
02:00:00 PM‟) WHERE ...”.
Flashback Versions Query: Flashback Versions Query ermöglicht das Anzeigen aller
Änderungen an einem bestimmten Datensatz seit einem bestimmten Punkt in der (nahen)
Vergangenheit bis zum aktuellen Datum. Dafür werden alle comitteten Zwischenzustände der
jeweiligen Zeile zur Anzeige gebracht. Auf diese Weise kann ermittelt werden, wie es zu dem
derzeitigen Stand der Zeile gekommen ist. Die dafür notwendigen Informationen ermittelt die
Datenbank ebenfalls aus den UNDO Segmenten. Das SQL-Statement für eine Flashback
Versions Query sieht wie folgt aus: „SELECT * FROM employee VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP(‟19-APR-05 02:00:00 PM‟) AND TIMESTAMP
TO_TIMESTAMP(‟19-APR-05 03:00:00 PM‟) WHERE ...”
Flashback Transaction Query: In der Regel werden in einer Transaktion mehrere Datensätze
verändert. Flashback Transaction Query erlaubt die Anzeige aller durch eine Transaktion
veränderten Datensätze und gibt auch Informationen über ein eventuell notwendiges UNDO-
Statement. Eine typische Abfrage wäre: „SELECT * FROM
FLASHBACK_TRANSACTION_QUERY WHERE XID = „000200030000002D‟;” Die
Transaktions-ID könnte man zuvor mit Hilfe einer Flashback Versions Abfrage ermitteln.
Auch bei dieser Technologie werden die Informationen aus den UNDO-Segmenten selektiert.
Flashback Transaction: Im Gegensatz zu den vorgenannten Flashback xy Query Verfahren,
bei denen lediglich Informationen über alte Stände oder Transaktionen selektiert werden, kann
beim Flashback Transaction in die Datenbank eingegriffen werden. Mittels Flashback
Transaction kann gezielt eine bereits abgeschlossene Transaktion und ggf. davon abhängige
Transaktionen zurückgerollt werden. Dazu muss die PL/SQL Prozedur
DBMS_FLASHBACK.TRANSACTION_BACKOUT() verwendet werden. Die notwendigen
Informationen werden aus dem UNDO-Tablespace ermittelt.
Flashback Table: Mit Hilfe der Flashback Table Funktionalität kann eine einzelne Tabellen
auf einen Stand in der Vergangenheit zurückgesetzt werden. Dies geschieht z.B. mit
folgendem SQL-Statement: „FLASHBACK TABLE orders, order_items TIMESTAMP
TO TIMESTAMP(‟07-APR-2005 02:33:00 PM‟);“ Die notwendigen Informationen
werden aus dem UNDO-Tablespace ermittelt.
Flashback Drop: Beginnend mit Oracle 10g wird eine Tabelle beim Löschen in der Regel
zunächst in einem sogenannten Recyle Bin der Datenbank verschoben. Dies geschieht durch
Änderung eines Data Dictionary Eintrages beim DROP-Befehl. Die eigentliche Tabelle bleibt
dabei im Ursprungs-Tablespace gespeichert und wird intern umbenannt. Solange dieser Platz
nicht anderweitig benötigt wird, kann die gelöschte Tabelle über ein Flashback Drop-
Kommando restauriert werden. Das folgende SQL-Statement zeigt ein Beispiel: „FLASHBACK
TABLE employee TO BEFORE DROP;“ (Der Einsatz des Recycle Bin ist im
Zusammenhang mit SAP-Systemen derzeit jedoch seitens SAP nicht erlaubt.)
Flashback Database: Diese Technologie wurde mit Oracle 10g eingeführt und ermöglicht das
Zurücksetzen der gesamten Datenbank auf einen Zeitpunkt in der Vergangenheit. Zuvor muss
die Fast Recovery Area und die Retentionzeit konfiguriert worden sein. Ist dies der Fall,
schreibt die Datenbank neben den archivierten Redo Logs regelmäßig sogenannte Flashback-
Logs in die Flash Recovery Area. Diese werden dann in Kombination mit den archivierten
Redo Logs für ein Flashback Database verwendet. Das SQL-Statement dafür ist: „FLASHBACK DATABASE TO TIMESTAMP TO_TIMESTAMP(‟19-APR-05 02:05:00 PM‟);“
Flashback Data Archive: Besteht für bestimmte Tabellen z.B. aus Revisionsgründen die
Anforderung, alle Änderungen, die an dieser Tabelle in der gesamten Lebenszeit der Tabelle
stattfinden, mitzuprotokollieren, so kann diese im so genannten Flashback Data Archive
abgelegt werden. Dazu wird zunächst ein eigener Tablespace erstellt, der als Flashback Data
Archive dient. Dann wird ein Flashback Data Archive darin angelegt: „CREATE FLASHBACK
ARCHIVE archiv1 TABLESPACE tbs1 RETENTION 5 YEAR;“. Im Flashback Data
Archive werden alle UNDO-Informationen der betroffenen Tabellen bis zur definierten
Zeitspanne vorgehalten. Jetzt wird die zu protokollierende Tabelle entsprechend modifiziert:
„ALTER TABLE emp FLASHBACK ARCHIVE archiv1;“. Der Zugriff auf die historischen
Langzeit-Informationen erfolgt dann in Form einer Flashback Query, wie oben erläutert. Die
Datenbank protokolliert nun alle Änderungen, die an dieser Tabelle stattfinden, unabhängig
vom UNDO-Tablespace oder den Einstellungen für Flashback Database. Diese Funktionalität
wurde mit Oracle 11g eingeführt.
Flashback Query ist Bestandteil der Oracle Standard Edition, alle anderen Flashback Technologien mit
Ausnahme von Flashback Data Archive sind Bestandteil der Oracle Enterprise Edition. Flashback
Data Archive ist Bestandteil der Total Recall Option. Im SAP-Umfeld ist Flashback Table im Notfall
erlaubt, wenn die anwendungsseitige Konsistenz sichergestellt werden kann (SAP-Hinweise 105047,
937492). Flashback Database ist erlaubt (SAP-Hinweis 966117). Die Verwendung der Total Recall
Option ist SAP seitig erlaubt, aber ohne SAP-Support.
Die Bedienung der verschiedenen Flashback Technologien erfolgt entweder über SQL*Plus oder über
den graphischen Enterprise Manager.
Im Folgenden wird der Einsatz von Flashback Database näher erläutert.
Bevor man eine Datenbank mit einem flashback database Kommando als Ganzes in die
Vergangenheit zurückversetzen kann, muss Flashback Database eingerichtet werden.
Dazu muss zunächst eine FRA (Oracle 10g Flash Recovery Area, ab Oracle 11g Fast Recovery Area)
eingerichtet werden. Die FRA stellt eine zentrale Stelle für alle Backup/Recovery relevanten Dateien
dar. In der FRA werden bei Verwendung der Flashback Database Funktionalität die Flashback Logs
gespeichert. Ferner können die Archivelogs und Backups oder Image Copies der Datenbank in diesem
Bereich abgelegt werden. (Laut SAP Hinweis 966073 ist das native Verwenden der FRA für
Archivelogs (USE_DB_RECOVERY_FILE_DEST bei log_archive_dest_n) im SAP-Umfeld jedoch
nicht zulässig.)
Zur Konfiguration der FRA müssen folgende init.ora Parameter definiert werden: DB_RECOVERY_FILE_DEST = directory | disk group
DB_RECOVERY_FILE_DEST_SIZE = integer [K | M | G]
DB_FLASHBACK_RETENTION_TARGET = integer (Minuten)
DB_REOVERY_FILE_DEST gibt an, wo die FRA liegen soll. Das kann ein Verzeichnis im Filesystem
oder eine Diskgruppe in ASM (Automatic Storage Management) sein. Bei Einsatz des RAC (Real
Application Clusters) haben alle Instanzen denselben Wert für DB_RECOVERY_FILE_DEST.
DB_RECOVERY_FILE_DEST_SIZE gibt an, wieviel Platz die Datenbank für die FRA verwenden darf.
DB_FLASHBACK_RETENTION_TARGET gibt an, wie weit ein flashback database im günstigsten
Fall zurückreichen soll. „Günstigster Fall“ deshalb, weil diese Zeitangabe für die Datenbank nicht
zwingend ist, sondern vom in der FRA zur Verfügung stehenden Platzangebot abhängig ist. Kommt es
in der FRA zu einem Engpass im Plattenplatz (space pressure), werden ältere Flashback Logs
zugunsten neuerer Logs oder Dateien mit höherer Priorität, wie DB Backups oder Archive-Logs
automatisch gelöscht.
In einem zweiten Schritt muss nun die Flashback Database Technologie aktiviert werden.
Standardmäßig ist Flashback Database ausgeschaltet. Den Status kann man mit folgender Abfrage
ermitteln:
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
Flashback Database wird aktiviert mit (auf der Standby Datenbank muss zuvor das Apply gestoppt
werden):
SQL> alter database flashback on;
Database altered.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
Folgende Data Dictionary Views geben wertvolle Informationen zu Flashback Database:
Informationen über den Zeitpunkt in der Vergangenheit zu dem die Datenbank maximal zurückgesetzt
werden kann: V$FLASHBACK_DATABASE_LOG
SQL> select * from V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN OLDEST_FL RETENTION_TARGET FLASHBACK_SIZE
-------------------- --------- ---------------- --------------
ESTIMATED_FLASHBACK_SIZE
------------------------
874089 06-OCT-11 1440 16384000
0
Information über die bisher angelegten Flashback Logs: V$FLASHBACK_DATABASE_LOGFILE
SQL> select * from V$FLASHBACK_DATABASE_LOGFILE;
NAME
--------------------------------------------------------------------------------
LOG# THREAD# SEQUENCE# BYTES FIRST_CHANGE# FIRST_TIM TYPE
---------- ---------- ---------- ---------- ------------- --------- ---------
/u01/recovery_area/PFEFFER/flashback/o1_mf_78v65x33_.flb
1 1 1 8192000 874089 06-OCT-11 NORMAL
/u01/recovery_area/PFEFFER/flashback/o1_mf_78v65xwd_.flb
2 1 2 8192000 879252 06-OCT-11 NORMAL
/u01/recovery_area/PFEFFER/flashback/o1_mf_78v9mn38_.flb
3 1 3 4096000 884975 06-OCT-11 NORMAL
Auskunft über den Füllgrad der FRA: V$FLASH_RECOVERY_AREA_USAGE
SQL> select FILE_TYPE, PERCENT_SPACE_USED, NUMBER_OF_FILES from
V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED NUMBER_OF_FILES
-------------------- ------------------ ---------------
CONTROL FILE 0 0
REDO LOG 0 0
ARCHIVED LOG 1.3 11
BACKUP PIECE 0 0
IMAGE COPY 0 0
FLASHBACK LOG .39 2
FOREIGN ARCHIVED LOG 0 0
7 rows selected.
Flashback Database kann in Data Guard Umgebungen auf der Primär-Seite und/oder der Standby-
Seite eingerichtet werden. Flashback Database ermöglicht in Fehlersituationen das Zurücksetzen der
Datenbank auf einen Punkt in der nahen Vergangenheit ohne ein Backup der DB einspielen zu
müssen.
Wenn man, wie dies bei der Freudenberg IT in vielen Kundensystemen der Fall ist, bereits eine
Physical Standby Datenbank an die Produktionsdatenbank angeschlossen hat, so bietet es sich an,
Flashback Database auf der Standby Datenbank einzurichten, um in Fehlersituationen schneller
reagieren zu können. Wird das Standby-System genutzt, um mittels Flashback Database fehlerhaft
manipulierte oder gelöschte Daten wieder zu rekonstruieren, kann das Produktionssystem auf nicht
vom Fehler betroffenen Strukturen weiterarbeiten. (Ein flashback database Kommando kann nur
im gemounteten Zustand der Datenbank durchgeführt werden.) Nach einem erfolgten flashback
database Kommando wird die Datenbank read only geöffnet um zu überprüfen, ob man den
richtigen Zeitpunkt erreicht hat. Ist der gewünschte Zeitpunkt früher, kann man durch ein erneutes
flashback database Kommando weiter in die Vergangenheit gehen. Ist der Zeitpunkt zu weit in
der Vergangenheit, kann man mit einem recover ... until-Kommando bis zum korrekten
Zeitpunkt vorwärtsrollen. Solange die Datenbank nur read only geöffnet wird, kann man vorwärts
und zurückrollen.
Im SAP Umfeld erfordert eine SAP Instanz einen read/write Zugriff auf die Datenbank, um
Informationen mit SAP Mitteln selektieren und exportieren zu können. Daher wird bei der
Freudenberg IT Flashback Database in Kombination mit Snapshot Standby betrachtet.
b. Snapshot Standby
Snapshot Standby Database ist ein besonderer Betriebsmodus der Physical Standby Datenbank.
Physical Standby Datenbank ist eine der beiden Arten Standby Datenbank, die mit Oracle Data Guard
möglich sind. Diese beiden Typen (Physical Standby Datenbank und Logical Standby Datenbank)
unterscheiden sich durch das Apply des Änderungsprotokols (Redo Log-Information). Auf die Logical
Standby Datenbank wird in diesem Papier nicht näher eingegangen – ihr Einsatz ist im SAP-Umfeld
ohnehin nicht erlaubt.
Abb. 1: Oracle Data Guard Architektur
Bei der Physical Standby Datenbank ist der MRP (Managed Recovery Process) für das Apply
verantwortlich. D.h. die Änderungen, die auf der Primär-Datenbank stattgefunden haben, werden
durch ein Recovery in der Physical Standby Datenbank nachgezogen. Daher ist die Physical Standby
Datenbank blockweise 1:1 identisch mit der Primär-Datenbank und erlaubt zum einen einen optimalen
Desaster-Schutz, zum anderen kann die Physical Standby Datenbank für Backups herangezogen
werden und somit das Primärsystem entlasten.
Neben dem reinen Desaster-Schutz kann eine Physical Standby Datenbank auch für Applikations-Test
verwendet werden. Dazu wird die Physical Standby Datenbank temporär lesend und schreibend
geöffnet. Bis Oracle 10g Release 2 war dafür die Definition eines Guaranteed Restore Points
erforderlich, der es ermöglicht hat, nach Abschluss der Tests die Standby Datenbank wieder
zurückzusetzen. Während dieser Testphase war in Oracle 10g ein automatisches Übertragen der Redo
Log Information von der Primär Datenbank zur Standby Datenbank nicht möglich, so dass der
Desaster-Schutz nicht erhalten blieb. Beginnend mit Oracle 11g Release 1 wurde die Technologie
dahingehend erweitert, dass die Standby Datenbank auch dann die Änderungen der Primär Datenbank
empfangen kann, wenn sie temporär für Testzwecke lesend und schreibend geöffnet ist. Diese
Anwendungsmöglichkeit nennt man „Snapshot Standby“.
Damit man eine Physical Standby Datenbank in eine Snapshot Standby Datenbank umwandeln kann,
muss man eine FRA eingerichtet haben. Die Flashback Database Funktionalität muss für Snapshot
Standby Database nicht notwendigerweise eingerichtet sein.
Eigenschaften einer Snapshot Standby Datenbank:
- Snapshot Standby Datenbank erhält und archiviert Redo Log Daten von der Primary, ohne diese
einzuspielen
- Redo-Informationen werden nach Rückumwandlung und Restart des Apply automatisch eingespielt
- Desaster-Schutz bleibt erhalten
- Snapshot Standby kann kein Ziel für ein Switchover/Failover sein
- Snapshot Standby kann nicht Bestandteil einer Maximum Protection Data Guard Umgebung sein
Die Umwandlung einer Physical Standby Datenbank in eine Snapshot Standby Datenbank erfolgt mit
folgenden Befehlen im Mount-Status:
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
MOUNTED PHYSICAL STANDBY
Stopp des Apply:
SQL> recover managed standby database cancel;
Media recovery complete.
Umwandlung in Snapshot Standby Datenbank:
SQL> alter database convert to snapshot standby;
Database altered.
Während der Umwandlung wird die Datenbank „dismounted“ und muss durchgestartet werden.
Im Alert.log wird das implizite Anlegen eines Guaranteed Restore Points angezeigt:
Completed: ALTER DATABASE RECOVER managed standby database cancel
Tue Oct 11 12:25:44 2011
alter database convert to snapshot standby
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_10/11/2011 12:25:44
krsv_proc_kill: Killing 3 processes (all RFS)
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after complete recovery through change 917338
Resetting resetlogs activation ID 2628314358 (0x9ca8e4f6)
Online log /u02/oradata/SALZ/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u02/oradata/SALZ/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u02/oradata/SALZ/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 917336
Tue Oct 11 12:25:46 2011
Setting recovery target incarnation to 7
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
Nach Neustart der Snapshot Standby Datenbank sieht man den geänderten Datenbank-Status und den
Restore Point in den Dictionary-Views:
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ WRITE SNAPSHOT STANDBY
SQL> select * from V_$RESTORE_POINT;
SCN DATABASE_INCARNATION# GUA STORAGE_SIZE
---------- --------------------- --- ------------
TIME
---------------------------------------------------------------------------
RESTORE_POINT_TIME PRE
--------------------------------------------------------------------------- ---
NAME
--------------------------------------------------------------------------------
917337 2 YES 8192000
11-OCT-11 12.25.44.000000000 PM
YES
SNAPSHOT_STANDBY_REQUIRED_10/11/2011 12:25:44
Während die Snapshot Standby Datenbank gestartet ist, werden Redo Log Informationen von der
Primary entgegen genommen, archiviert aber nicht eingespielt:
Tue Oct 11 12:28:47 2011
Archived Log entry 39 added for thread 1 sequence 45 ID 0x9ca8e4f6 dest 1:
RFS[1]: Selected log 4 for thread 1 sequence 47 dbid -1666634762 branch 763732985
Tue Oct 11 12:28:51 2011
Archived Log entry 40 added for thread 1 sequence 46 ID 0x9ca8e4f6 dest 1:
SQL> select sequence#, archived, applied from v$archived_log;
SEQUENCE# ARC APPLIED
---------- --- ---------
40 YES YES
41 YES YES
42 YES YES
43 YES NO
44 YES NO
45 YES NO
Zur Rückumwandlung muss die Snapshot Standby Datenbank gestoppt und in den Mount Status
gebracht werden. Danach wandelt man die Snapshot Standby Datenbank mit dem folgenden
Kommando zurück in eine Physical Standby Datenbank:
SQL> startup mount;
ORACLE instance started.
Total System Global Area 552402944 bytes
Fixed Size 1345488 bytes
Variable Size 343935024 bytes
Database Buffers 201326592 bytes
Redo Buffers 5795840 bytes
Database mounted.
SQL> alter database convert to physical standby;
Database altered.
Im Hintergrund wird dabei ein flashback database auf den Restore Point gemacht, alle
entstandenen Flashback Logs und der Guarenteed Restore Point gelöscht sowie die Datenbank
„dismounted“.
Tue Oct 11 12:30:31 2011
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (SALZ)
krsv_proc_kill: Killing 3 processes (all RFS)
Flashback Restore Start
Flashback Restore Complete
Drop guaranteed restore point
Guaranteed restore point dropped
Deleted Oracle managed file
/u02/recovery_area/SALZ/flashback/o1_mf_78vjoh9x_.flb
Deleted Oracle managed file
/u02/recovery_area/SALZ/flashback/o1_mf_78v67lmp_.flb
Clearing standby activation ID 2628847246 (0x9cb1068e)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Completed: alter database convert to physical standby
Ein erneutes Durchstarten zeigt dann wieder den Status als Physical Standby Datenbank:
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY PHYSICAL STANDBY
SQL> select * from V_$RESTORE_POINT;
no rows selected
Nach Start des Recovery werden dann alle bisher angefallenen Redo Logs eingespielt.
SQL> select sequence#, archived, applied from v$archived_log;
SEQUENCE# ARC APPLIED
---------- --- ---------
40 YES YES
41 YES YES
42 YES YES
43 YES YES
44 YES YES
45 YES YES
46 YES YES
c. Kombination Flashback Database und Snapshot Standby am Beispiel
Beide oben ausgeführten Technologien lassen sich auch kombinieren. Dies ist gerade vor dem
Hintergrund von Applikationen interessant, die aufgrund der Applikationsstruktur keinen read only
Datenbank Zugriff ermöglichen. Dazu gehört auch SAP. Wenn man mit einer SAP Instanz auf die
Datenbank zugreifen möchte, muss die Datenbank read/write geöffnet werden.
Voraussetzung ist neben einer eingerichteten FRA auch ein aktiviertes flashback database auf
der Standby Datenbank Seite.
Überprüfung der Voraussetzungen: SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
SQL> show parameter recovery_file
NAME TYPE VALUE
------------------------------------ ----------- --------------------------
db_recovery_file_dest string /u02/recovery_area
db_recovery_file_dest_size big integer 4002M
SQL> select * from V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN OLDEST_FL RETENTION_TARGET FLASHBACK_SIZE
-------------------- --------- ---------------- --------------
ESTIMATED_FLASHBACK_SIZE
------------------------
896156 10-OCT-11 1440 56311808
119857152
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------------- ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 2.12 0 45
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 1.34 0 10
FOREIGN ARCHIVED LOG 0 0 0
7 rows selected.
Sind die Vorausetzungen erfüllt, werden für das folgende Beispiel auf der Primärseite eine Test-
Tabelle im Schema SCOTT erzeugt und 5 Zeilen eingefügt. Das Flashback-Kommando kann man
entweder Zeitorientiert (to timestamp) oder SCN-basiert (to SCN) ausführen. Der Einfachheit
halber wird in dem gezeigten Beispiel nach jedem insert die aktuelle SCN abgefragt. Sie dient
später als Flashback-Punkt.
SQL> create table scott.doag (spalte1 number, spalte2 varchar2(30));
Table created.
SQL> insert into scott.doag values (1,'Das ist der erste Eintrag');
1 row created.
SQL> commit;
Commit complete.
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
925365
SQL> insert into scott.doag values (2,'Das ist der zweite Eintrag');
1 row created.
SQL> commit;
Commit complete.
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
925368
SQL> insert into scott.doag values (3,'Das ist der dritte Eintrag');
1 row created.
[...]
SQL> insert into scott.doag values (5,'Das ist der fuenfte Eintrag');
1 row created.
SQL> commit;
Commit complete.
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
925377
Wenn die Physical Standby Datenbank im Active Data Guard Mode läuft, kann man die Ergebnisse
direkt auf der Standby-Seite ansehen:
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY WITH APPLY PHYSICAL STANDBY
SQL> select * from scott.doag;
SPALTE1 SPALTE2
---------- ------------------------------
1 Das ist der erste Eintrag
2 Das ist der zweite Eintrag
3 Das ist der dritte Eintrag
4 Das ist der vierte Eintrag
5 Das ist der fuenfte Eintrag
Im nächsten Schritt soll nun die Standby-Datenbank auf den Stand nach dem Einfügen der zweiten
Zeile gebracht werden. Dazu muss man zunächst das Apply stoppen und die Datenbank in den mount-
Status bringen. Anschließend wird die Datenbank auf die SCN nach der zweiten Zeile zurückgesetzt:
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database close;
Database altered.
SQL> flashback database to scn 925368;
Flashback complete.
Tests haben gezeigt, dass man nach erfolgtem Flashback Database die Standby-Datenbank zunächst
einmal durchstarten und in den Mount-Status bringen sollte, bevor man die Umwandlung zur
Snapshot-Standby wie oben beschrieben vornimmt. Eine direkte Umwandlung könnte sonst zu einem
ORA-600 führen:
Thu Oct 06 16:36:33 2011
Errors in file
/u01/app/oracle/diag/rdbms/salz/SALZ/trace/SALZ_dbrm_4880.trc
(incident=4857):
ORA-00600: internal error code, arguments: [2662], [0], [886967], [0],
[887336], [0], [], [], [], [], [], []
Incident details in:
/u01/app/oracle/diag/rdbms/salz/SALZ/incident/incdir_4857/SALZ_dbrm_4880_i4
857.trc
Use ADRCI or Support Workbench to package the incident.
Nach der Umwandlung zur Snapshot Standby kann man das System nun nutzen, um entweder alte
Datenstände zu exportieren oder temporäre Manipulationen an den Daten vorzunehmen (z.B. Test von
Skripten/Applikationen).
Im Beispiel erkennt man, dass die Daten auf den Stand nach dem zweiten insert zurückgesetzt
worden sind:
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ WRITE SNAPSHOT STANDBY
SQL> select * from scott.doag;
SPALTE1 SPALTE2
---------- ------------------------------
1 Das ist der erste Eintrag
2 Das ist der zweite Eintrag
Nun können für Applikations-Tests neue Daten erfasst werden:
SQL> insert into scott.doag values (3,'Das ist Alternativ-Eintrag 1');
1 row created.
SQL> insert into scott.doag values (4,'Das ist Alternativ-Eintrag 2');
1 row created.
SQL> insert into scott.doag values (5,'Das ist Alternativ-Eintrag 3');
1 row created.
SQL> select * from scott.doag;
SPALTE1 SPALTE2
---------- ------------------------------
1 Das ist der erste Eintrag
2 Das ist der zweite Eintrag
3 Das ist Alternativ-Eintrag 1
4 Das ist Alternativ-Eintrag 2
5 Das ist Alternativ-Eintrag 3
Alle durchgeführten Änderungen werden bei der Rückumwandlung in eine Physical Standby
Datenbank wieder verworfen und nach Start des Apply die zwischenzeitlich auf der Primary
durchgeführten Änderungen eingespielt:
SQL> alter database close;
Database altered.
SQL> alter database convert to physical standby;
Database altered.
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 552402944 bytes
Fixed Size 1345488 bytes
Variable Size 348129328 bytes
Database Buffers 197132288 bytes
Redo Buffers 5795840 bytes
Database mounted.
Database opened.
SQL>
SQL> select * from scott.doag;
SPALTE1 SPALTE2
---------- ------------------------------
1 Das ist der erste Eintrag
2 Das ist der zweite Eintrag
SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.
SQL> select * from scott.doag;
SPALTE1 SPALTE2
---------- ------------------------------
1 Das ist der erste Eintrag
2 Das ist der zweite Eintrag
3 Das ist der dritte Eintrag
4 Das ist der vierte Eintrag
5 Das ist der fuenfte Eintrag
6 Das ist der sechste Eintrag
4. Einsatz-Szenarien Flashback Database und Snapshot Standby bei der Freudenberg IT
a. Generelles Data Guard Konzept
Bei Freudenberg IT wird Data Guard schon seit vielen Jahren (seit SAP Freigabe des Releases
Oracle 9i) im SAP-Umfeld bei gehosteten Kundensystemen eingesetzt. Data Guard ist hier Teil des
Hochverfügbarkeitskonzeptes. Um insbesondere den wichtigen Schutz vor logischen Fehlern zu
realisieren, wurde die Standby Seite stets mit einem Zeitversatz hinter der Primärseite laufen gelassen,
der als Kompromiss zwischen „Umschaltgeschwindigkeit im Desaster-Fall“ und „abgedeckter
Zeitraum in der Vergangenheit“ gewählt wurde: gerade bei großen Systemen, bei denen auch Redo
Log-Raten von weit über 10 GB/h keine Seltenheit sind, kann das Nachfahren der Redo Logs bei einer
Umschaltung signifikante Zeit in Anspruch nehmen. Als typische Richtgröße hat sich hier bei
Systemen in der Größenordnung von wenigen TB mit um/über tausend SAP-Usern ein Zeitversatz von
vier Stunden bewährt, der im Katastrophenfall meist in weniger als einer halben Stunde wieder
„aufzuholen“ ist (Redo Apply), so dass eine komplette Umschaltung der SAP-Umgebung auf die
Standby Seite in weniger als einer Stunde zu realisieren ist.
Ein Zeitversatz von vier Stunden ist andererseits auch eine Zeit, in der ein gravierender logischer
Fehler meist schon erkannt wird, so dass die Standby Seite rechtzeitig gestoppt und „noch ohne
Fehler“ für die weitere Fehlerbehebung zur Verfügung steht.
Da SAP stets schreibenden Zugriff auf eine Datenbank benötigt, wurde in solchen Fehlerfällen bis
Oracle 10g zunächst versucht, mit Datenbankmitteln die „intakten Daten“ aus der Standby zu „retten“
und dem Live-System danach (mit SAP-Standard-Methoden) wieder zur Verfügung zu stellen. Das
Öffnen der Standby zum Schreiben (und damit zum Starten einer SAP-Instanz) hatte, wie im
Abschnitt 3.b. schon erwähnt, die Einschränkung, dass keine weiteren Redo Informationen mehr
übertragen wurden. Somit wurde einerseits der Katastrophenschutz temporär ausgesetzt, andererseits
waren die notwendigen Maßnahmen mit einer Reihe von manuellen Schritten verbunden.
Mit Oracle 11g kann hier nun die „Snapshot Standby“ Funktionalität genutzt werden, um die
Datenbank bei weiter laufendem Redo Transfer temporär schreibend zu öffnen. Somit ist das Starten
einer SAP Instanz auf der Standby Seite nun erheblich einfacher geworden.
Da inzwischen die Wiederverfügbarkeit der Systeme im Katastrophenfall immer wichtiger wird und
man somit „im Vergleich“ eher Zeit zum „Zurückfahren der Standby“ im Falle eines logischen Fehlers
hat, findet Data Guard vermehrt Einsatz mit „synchronem Apply“ und aktivem Flashback Database
auf der Standby Seite, um hiermit im Falle eines logischen Fehlers wieder „schnell in die
Vergangenheit“ zu kommen. Insbesondere mit den neuen Features von Oracle 11g ist es darüber
hinaus besonders einfach geworden, die Standby Seite im Bedarfsfall – wie einen Kassettenrekorder –
rückwärts/vorwärts zu „spulen“, ggf. beliebig oft, bis man den richtigen Zeitpunkt gefunden hat – und
das Ganze Dank Snapshot Standby sogar mit der Möglichkeit, jeweils direkt eine SAP Instanz zur
Analyse zu starten. Diese Flexibilität bietet keine andere Backup/Restore-Technologie. (Dort kann
man zwar ggf. mehr oder weniger schnell auf vordefinierte Zeitpunkte in der Vergangenheit
zurückspringen, jedoch niemals in beliebig kleinen Schritten einfach „vor und zurück“ bis zum
gesuchten Ziel.)
b. Allgemeiner Einsatz von Flashback Database
Über den eben beschriebenen Einsatz im Zusammenhang mit Data Guard hinaus wird Flashback
Database bei Kundensystemen nicht standardmäßig aktiviert. Hauptgrund hierfür ist, dass es in der
Regel bei Produktivsystemen keine Option ist, im Fehlerfalle das Live-System in die Vergangenheit
zurückzusetzen (Datenverlust, unüberschaubare Abhängigkeit zu allen möglichen angebundenen
Systemen, die nicht zurückgesetzt werden können). Aus diesem Grund verzichtet man dann auch auf
den „Overhead“, den das eingeschaltete Flashback Database mit sich bringen würde.
In besonderen Situationen wie z.B. vor kritischen Systemumstellungen (Upgrade, Applikations-
änderungen etc.), kann der Einsatz des Flashback Database unabhängig davon jedoch hilfreich sein,
um mit einem „Guaranteed Restore Point“ Zeit im Restore-Fall zu sparen. Flashback Database ersetzt
hier natürlich nicht die üblichen Datenbank-Backups, die ja zur Absicherung eines physikalischen
Defektes (Hardware-Ausfall) weiterhin benötigt werden – es dient vielmehr dazu, einen rein aus
„logischer Sicht“ (Applikation) nötigen Restore erheblich zu beschleunigen.
c. Technische Umsetzung
Data Guard kommt im SAP-Umfeld generell nur in Zusammenhang mit einer Physical Standby
Datenbank zum Einsatz (SAP-Vorgabe). Bei Freudenberg IT wird darüber hinaus zum einfacheren
Management der Data Guard Broker konfiguriert und insbesondere für geplante Switchover bzw.
erforderlichenfalls bei einem Failover eingesetzt. Die Standby Datenbank wird mit gleichem Namen
auf einer anderen Hardware betrieben, die sich darüber hinaus sogar in einem anderen Rechenzentrum
befindet (Katastrophenschutz!).
Die SAP-Zentralinstanz wird auf dem gleichen Knoten installiert wie die Primärseite bzw. eine
analoge Instanz auf der Standby Seite vorbereitet. Um prinzipiell zu jedem Zeitpunkt in der Lage zu
sein, eine eigene, unabhängige SAP-Instanz auf der Standby-Seite starten zu können, werden für die
SAP-spezifischen Filesysteme /sapmnt/<SID>, /usr/sap/trans_<SID> usw. keine shared Filesysteme
verwendet, sondern jeweils lokale Filesysteme auf den beiden Knoten (Primary + Standby) – dies
bietet darüber hinaus zusätzliche Sicherheit gegen „Ausfall“ eines Filesystems, da es die Daten
tatsächlich in voneinander unabhängigen Filesystemen gibt (auf verschiedenen Knoten, in
verschiedenen Rechenzentren). Im normalen Betrieb hat dies zur Folge, dass die Filesysteme
synchronisiert werden müssen, um auf aktuellem Stand zu bleiben; außerdem muss sichergestellt sein,
dass alle weiteren SAP-Applikationsserver diese Filesysteme von der aktiven Primärseite mounten –
insbesondere muss dies bei einem switchover/failover umgeschaltet werden (erfolgt skriptbasiert).
Bei der Installation/Konfiguration der SAP Zentralinstanz kann SAP-seitig ein „virtueller Hostname“
verwendet werden (insbesondere im Falle eines Java-Stacks wichtig), um bei einer Umschaltung die
ansonsten notwendigen Änderungen der Hostnamen in den SAP-Profilen sowie innerhalb einzelner
SAP-Transaktionen zu vermeiden.
Die Fast Recovery Area wird (soweit gewünscht) auf beiden Seiten schon konfiguriert. Flashback
Database wird i.d.R. auf der Primärseite wie schon erwähnt nicht eingeschaltet, wohl aber auf der
Standby Seite, soweit das zeitlich synchrone Nachfahren gewünscht ist. Technische Details
(Namenskonventionen/Parameter) sind hierzu in SAP „Hinweis 966073 – Oracle Flash Recovery
Area/Fast Recovery Area“ vorgegeben, Flashback im SAP-Umfeld ist darüber hinaus in „Hinweis
966117 – Oracle Flashback Database Technologie“ ausführlich beschrieben.
d. Einsatzbeispiele
Demo-System für die folgenden Beispiele:
SAP Release: ECC 6.0 ABAP
Oracle Release: 11.2.0.2
SID: SD3
Primary: odrs46
Standby: itrs26
Data Guard: SYNCH, NO DELAY
aa. Einsatz von Flashback Database für „Restore“ mit Guaranteed Restore Point
Typischer Einsatz: vor „kritischer“ Systemänderung (Applikationsumstellung, Releasewechsel,
tiefgreifende Datenänderung, usw.). „Zurücksetzen“ soll bis zum Abschluß der Änderung mittels
Flashback ermöglicht werden.
Dies ist unabhängig vom Vorhandensein einer Standby; es wird also kein Data Guard benötigt und
betrifft somit im Beispiel „SD3“ ausschließlich die Primary.
Vorgehensweise:
Schritt 1: Fast Recovery Area (FRA) konfigurieren, soweit noch nicht geschehen.
Dazu entsprechendes Filesystem '/oracle/SD3/oraflash' anlegen und in Datenbank konfigurieren:
SQL> alter system set db_recovery_file_dest_size = 5000M scope=both;
System altered.
SQL> alter system set db_recovery_file_dest = '/oracle/SD3/oraflash'
scope=both;
System altered.
Die „DB_RECOVERY_FILE_DEST_SIZE“ (und zugehöriges Filesystem) muss ausreichend groß
sein, da es ansonsten zu einem Einfrieren der Datenbank kommen kann (vergleichbar mit Archiver
Stuck)!
Schritt 2: Guaranteed Restore Point setzen:
SQL> CREATE RESTORE POINT vor_upgrade GUARANTEE FLASHBACK DATABASE;
Restore point created.
Schritt 3: Systemänderungen…
Hier als Beispiel: Löschen der Logon-Gruppen und Anlegen eines neuen Mandanten:
Info zu Guaranteed Restore Point inzwischen:
SQL> SELECT NAME, SCN, STORAGE_SIZE FROM V$RESTORE_POINT WHERE
GUARANTEE_FLASHBACK_DATABASE = 'YES';
NAME SCN STORAGE_SIZE
-------------------- ---------- ------------
VOR_UPGRADE 28609613 8192000
Schritt 4: Zurücksetzen auf den definierten Guaranteed Restore Point nach Erkennen eines Fehlers.
Dazu
1. SAP samt Datenbank stoppen
2. DB mounten
3. Flashback
4. Datenbank mit Resetlogs öffnen
5. SAP wieder starten:
odrs46:sd3adm 1> stopsap
SQL> startup mount
...
Database mounted.
SQL> FLASHBACK DATABASE TO RESTORE POINT vor_upgrade;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
odrs46:sd3adm 2> startsap
Ergebnis: SAP sieht wieder aus wie vor den Änderungen. Das Resultat ist das gleiche wie bei einem
Point-in-time-Restore, jedoch mit weit geringerem Aufwand und i.d.R. geringerer Laufzeit.
Schritt 5: Der nicht mehr benötigte Restore Point sollte wieder gelöscht werden, um den Platz wieder
freizugeben und die Datenbank nicht unnötig zu „belasten“:
SQL> DROP RESTORE POINT vor_upgrade;
Restore point dropped.
Die Datenbank löscht dabei die angelegten Flashback Logs selbständig, wie im alert.log protokolliert
wird: Wed Oct 12 22:45:31 2011
Drop guaranteed restore point VOR_UPGRADE
Stopping background process RVWR
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ODRS46/flashback/o1_mf_79cwpzkv_.flb
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ODRS46/flashback/o1_mf_79cwq113_.flb
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ODRS46/flashback/o1_mf_79cy0bdg_.flb
...
...
Guaranteed restore point VOR_UPGRADE dropped
bb. Verhalten der Standby nach Flashback der Primary
Ist Data Guard im Einsatz, so merkt die Standby Datenbank, wenn auf der Primary ein „open
resetlogs“ durchgeführt wird. Prinzipiell kann die Standby Datenbank auch über einen solchen Punkt
hinweg weiter betrieben werden; je nachdem, ob die Standby sich bereits auf einem Zeitpunkt nach
dem Restore Point des Flashbacks befindet oder nicht, muss sie ggf. ebenfalls in die Vergangenheit
zurückgesetzt werden. Dies kann auf der Standby dann wiederum mittels Flashback erfolgen
(entweder mit aktiviertem normalen Flashback, oder ggf. auch dort mit zuvor angelegtem garantierten
Restore Point). Wird das Recovery dann wieder aktiviert, fährt die Standby selbständig über den
Resetlogs hinweg in die „neue Richtung“ weiter.
Im oben gezeigten Beispiel (Flashback SAP System) wurde Flashback auf der Standby bereits vorher
eingerichtet und das normale Flashback Database eingeschaltet:
SQL> alter system set db_recovery_file_dest_size = 5000M scope=both;
System altered.
SQL> alter system set db_recovery_file_dest = '/oracle/SD3/oraflash'
scope=both;
System altered.
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> ALTER DATABASE FLASHBACK ON;
Database altered.
SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
Die Standby „merkt“ den „open resetlogs“ und stellt dabei fest, dass sie sich selbst nun in einer
„falschen Zukunft“ befindet, wie im alert.log zu sehen:
Wed Oct 12 22:23:47 2011
RFS[5]: Assigned to RFS process 58589596
RFS[5]: New Archival REDO Branch: 764375014 Current: 742840207
Primary database is in MAXIMUM PERFORMANCE mode
RFS[5]: Selected log 24 for thread 1 sequence 3 dbid 42322127 branch
764375014
Wed Oct 12 22:23:48 2011
RFS[6]: Assigned to RFS process 58327418
RFS[6]: Selected log 25 for thread 1 sequence 2 dbid 42322127 branch
764375014
RFS[6]: Physical Standby in the future of Branch(resetlogs_id) 764375014
RFS[6]: Standby database SCN: 0:28612328 Primary branch SCN: 0:28609615
Use FLASHBACK DATABASE command to resynchronize this standby with indicated
primary database branch
RFS[6]: New Archival REDO Branch(resetlogs_id): 764375014 Prior: 742840207
RFS[6]: Archival Activation ID: 0x3cebd29 Current: 0x3c34f89
RFS[6]: Effect of primary database OPEN RESETLOGS
RFS[6]: Managed Standby Recovery process is active
RFS[6]: Incarnation entry added for Branch(resetlogs_id): 764375014 (SD3)
Wed Oct 12 22:23:48 2011
Setting recovery target incarnation to 4
Das noch laufende Recovery mit Real Time Apply wird automatisch beendet, nachdem die Standby
realisiert, dass sie sich in der „falschen Zukunft“ befindet: Wed Oct 12 22:23:48 2011
MRP0: Incarnation has changed! Retry recovery...
Errors in file
/oracle/SD3/saptrace/diag/rdbms/sd3_itrs26/SD3/trace/SD3_pr00_38011152.trc:
ORA-19906: recovery target incarnation changed during recovery
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Wed Oct 12 22:23:50 2011
started logmerger process
Wed Oct 12 22:23:50 2011
Managed Standby Recovery starting Real Time Apply
Warning: Recovery target destination is in a sibling branch
of the controlfile checkpoint. Recovery will only recover
changes to datafiles.
Datafile 1 (ckpscn 28612328) is orphaned on incarnation#=1
MRP0: Detected orphaned datafiles!
Recovery will possibly be retried after flashback...
Errors in file
/oracle/SD3/saptrace/diag/rdbms/sd3_itrs26/SD3/trace/SD3_pr00_58065174.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/oracle/SD3/sapdata1/system_1/system.data1'
Managed Standby Recovery not using Real Time Apply
Slave exiting with ORA-19909 exception
Errors in file
/oracle/SD3/saptrace/diag/rdbms/sd3_itrs26/SD3/trace/SD3_pr00_58065174.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/oracle/SD3/sapdata1/system_1/system.data1'
Recovery Slave PR00 previously exited with exception 19909
Wed Oct 12 22:24:11 2011
MRP0: Background Media Recovery process shutdown (SD3)
Unabhängig davon geht der Logtransfer von der Primary zur Standby jedoch im Hintergrund weiter,
auch wenn diese aktuell nicht appliziert werden können. Beispiel:
Primary: SQL> alter system archive log current;
System altered.
Standby: Wed Oct 12 22:32:52 2011
RFS[5]: Selected log 25 for thread 1 sequence 4 dbid 42322127 branch
764375014
Wed Oct 12 22:32:52 2011
Archived Log entry 6988 added for thread 1 sequence 3 ID 0x3cebd29 dest 1:
Um die Standby nun wieder zu synchronisieren, muss sie selbst in die Vergangenheit zurückgesetzt
werden. Aufgrund des aktiven Flashback Database ist dies nun einfach möglich. Hierzu ist zunächst
der passende Punkt zu ermitteln (falls man sich diesen nicht schon vor Beginn gemerkt hat):
Auf Primary RESETLOGS_CHANGE# ermitteln: SQL> select RESETLOGS_CHANGE# from v$database;
RESETLOGS_CHANGE#
-----------------
28609615
Somit auf der Standby also Flashback auf 28609615-2 = 28609613 und Recovery wieder starten:
SQL> FLASHBACK DATABASE TO SCN 28609613;
Flashback complete.
SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.
Damit ist die Standby Seite wieder synchron, ohne dass ein Restore/Neuaufbau nötig war. Während
der ganzen Zeit war der Katastrophenschutz gewährleistet, da weiterhin alle Redo Informationen
lückenlos übertragen wurden, auch wenn sie zeitweilig noch nicht appliziert werden konnten.
cc. Einsatz von Flashback Database auf Standby zur Suche nach Fehlerzeitpunkt
Ist Data Guard im Einsatz, so kann bei Auftreten eines Fehlers im SAP System dieser am „Zustand
vorher“ auf der Standby Seite analysiert werden. Ist der genaue Fehlerzeitpunkt nicht bekannt und
kann nicht mit anderen Mitteln ermittelt werden (SAP Logs, Logminer, usw.), so kann die Standby
Seite im Rahmen der in der FRA gesicherten Flashback Logs Informationen beliebig „vor- und
zurückgespult“ werden, bis man den korrekten Zeitpunkt gefunden hat.
Zur Demonstration wird eine Tabelle angelegt (um 13:15 h):
SQL> CREATE TABLE test_flash ( "NR" number, "ZEIT_CHAR" VARCHAR2(20),
"TIME" date ) tablespace PSAPDATUSR;
Table created.
SQL> insert into test_flash ( select count(*), to_char(sysdate,'YYYY-MM-DD
HH24:MI:SS'), sysdate from test_flash);
1 row created.
SQL> commit;
Commit complete.
... (mehrmals wiederholt)
SQL> select * from test_flash;
NR ZEIT_CHAR TIME
---------- -------------------- ---------------
0 2011-10-06 13:15:21 06-OCT-11
1 2011-10-06 13:15:55 06-OCT-11
2 2011-10-06 13:15:56 06-OCT-11
3 2011-10-06 13:16:00 06-OCT-11
... (per Skript jede Sekunde weitere solcher inserts...)
Auf der Standby Seite kann die synchrone Übertragung der Zeilen geprüft werden… SQL> alter database open read only;
Database altered.
SQL> select * from test_flash;
...
...
NR ZEIT_CHAR TIME
---------- -------------------- ---------------
158 2011-10-06 13:22:31 06-OCT-11
159 2011-10-06 13:22:32 06-OCT-11
160 2011-10-06 13:22:33 06-OCT-11
161 2011-10-06 13:22:34 06-OCT-11
162 2011-10-06 13:22:35 06-OCT-11
163 2011-10-06 13:22:36 06-OCT-11
164 rows selected.
… nun kann „vor- und zurückspulen“ auf der Standby getestet werden, um das Suchen nach einer
bestimmten Veränderung zu simulieren (es ist jetzt „nach 14:00 h“):
Versuch 1: zurück auf 13:00 Uhr:
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> FLASHBACK DATABASE TO TIMESTAMP TO_DATE('2011-10-06 13:00:00','YYYY-
MM-DD HH24:MI:SS');
Flashback complete.
SQL> alter database open read only;
Database altered.
SQL> select * from test_flash;
select * from test_flash
*
ERROR at line 1:
ORA-00942: table or view does not exist
die Tabelle existiert nicht mehr – wurde ja auch erst später angelegt.
Versuch 2: ab hier weiter vorgehen auf 13:30 Uhr:
Dies erfolgt wie ein normales Point-in-Time-Recovery auf der Standby; die DB wird dabei
automatisch wieder in den Mount Status zurückgesetzt:
SQL> recover standby database until time '2011-10-06:13:30:00';
ORA-00279: change 26681338 generated at 10/06/2011 13:00:01 needed for
thread 1
ORA-00289: suggestion : /oracle/SD3/oraarch/SD3arch1_7691_742840207.dbf
ORA-00280: change 26681338 for thread 1 is in sequence #7691
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
...
Log applied.
Media recovery complete.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open read only;
Database altered.
SQL> select * from test_flash;
...
...
NR ZEIT_CHAR TIME
---------- -------------------- ---------------
565 2011-10-06 13:29:56 06-OCT-11
566 2011-10-06 13:29:57 06-OCT-11
567 2011-10-06 13:29:58 06-OCT-11
568 2011-10-06 13:29:59 06-OCT-11
569 rows selected.
Tabelle ist hier also da, mit den Einträgen bis 13:30 h, wie erwartet.
Versuch 3: ab hier doch nochmal 10 Minuten zurück, also auf 13:20 h:
SQL> FLASHBACK DATABASE TO TIMESTAMP TO_DATE('2011-10-06 13:20:00','YYYY-
MM-DD HH24:MI:SS');
Flashback complete.
SQL> alter database open read only;
Database altered.
SQL> select * from test_flash;
NR ZEIT_CHAR TIME
---------- -------------------- ---------------
0 2011-10-06 13:15:21 06-OCT-11
1 2011-10-06 13:15:55 06-OCT-11
2 2011-10-06 13:15:56 06-OCT-11
3 2011-10-06 13:16:00 06-OCT-11
4 2011-10-06 13:19:43 06-OCT-11
5 2011-10-06 13:19:44 06-OCT-11
6 2011-10-06 13:19:45 06-OCT-11
...
...
18 2011-10-06 13:19:58 06-OCT-11
19 2011-10-06 13:19:59 06-OCT-11
20 2011-10-06 13:20:00 06-OCT-11
21 rows selected.
Tabelle hat den erwarteten Inhalt: nur noch Einträge bis 13:20 h.
Versuch 4: und hier nochmal 3 Minuten vor, also auf 13:23 h:
SQL> recover standby database until time '2011-10-06:13:23:00';
ORA-00279: change 26683085 generated at 10/06/2011 13:20:01 needed for
thread 1
ORA-00289: suggestion : /oracle/SD3/oraarch/SD3arch1_7691_742840207.dbf
ORA-00280: change 26683085 for thread 1 is in sequence #7691
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
Log applied.
Media recovery complete.
SQL> alter database open read only;
Database altered.
SQL> select * from test_flash;
...
...
NR ZEIT_CHAR TIME
---------- -------------------- ---------------
181 2011-10-06 13:22:56 06-OCT-11
182 2011-10-06 13:22:57 06-OCT-11
183 2011-10-06 13:22:58 06-OCT-11
184 2011-10-06 13:22:59 06-OCT-11
185 rows selected.
Tabelle hat nun also wieder die Einträge bis 13:23 h.
An jedem dieser Punkte könnte nun auch eine SAP Instanz auf der Standby Seite gestartet werden
(vgl. nächsten Abschnitt), so dass man hiermit also auch das gesamte SAP System „hin- und
herspulen“ kann.
dd. Einsatz von Snapshot Standby zum Starten einer SAP-Instanz
Um auf der Standby Seite eine SAP Instanz starten zu können, muss die Standby schreibend geöffnet
werden und wird daher zunächst in eine „Snapshot Standby“ konvertiert.
Im Anschluß müssen evtl. noch SAP Profile auf der Standby angepasst werden, falls sie durch
Replizierung mit der Primary identisch sind und kein virtueller Hostname verwendet wurde. Im
folgenden Beispiel ist genau dies der Fall (kein virtueller Hostname, um die Hosts von Primary und
Standby im Beispiel besser unterscheiden zu können).
Vor dem Starten der SAP Instanz sind je nach Anwendungsfall evtl. noch weitere Dinge zu beachten,
z.B.
- Filesystem-Replizierung stoppen, um temporär autarke SAP-Instanz zu ermöglichen (insb.
auch mit eigenen Profilen etc.)
- Batch-Prozesse sollten im Instanzprofil auskommentiert werden, damit kein „produktiver“ Job
loslaufen kann. (Dabei darf es im SAP natürlich keine Betriebsart geben, die fälschlicherweise
mit zu wenig Prozessen definiert ist und nun zufällig auf die geringere Gesamtzahl der
Workprozesse passt, da dies zu einer ungewünschten Umschaltung von Prozessen nach BTC
führen könnte.) Wenn gewünscht, könnte mit etwas mehr Aufwand sogar die Instanz-Nr. des
Systems geändert werden, um neue Ports zu verwenden.
- Falls es kritische Netzwerk-Verbindungen nach außen gibt (Schnittstellen), könnten diese vor
dem Start deaktiviert werden – solange keine Jobs loslaufen können, sollte dies jedoch
unkritisch sein.
- Wenn für die nachfolgende „Fehlerbehebung innerhalb SAP“ Batch-Prozesse zwingend
benötigt werden (z.B. um Transporte erzeugen/freigeben zu können), so sollte dennoch das
System zunächst ohne BTC gestartet werden und erst eine „Job-Bereinigung“ im System
erfolgen (z.B. durch Report BTCTRNS1 und evtl. Deaktivierung kritischer Schnittstellen).
Das produktiv arbeitende SAP System auf der Primary bleibt von allen Aktionen auf der Standby
unberührt.
Die essentiellen Schritte auf der Standby hier im Beispiel sind:
Schritt 1: Konvertierung der Standby in eine Snapshot Standby und öffnen (schreibend):
Das Recovery ist hier durch Rückfahren auf einem bestimmten Zeitpunkt schon gestoppt – ansonsten
müsste dies noch gestoppt werden. Flashback Database ist hier eingeschaltet – zur Konvertierung in
eine Snapshot Standby würde bereits die Konfiguration der FRA ohne aktives Flashback genügen.
SQL> select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database;
OPEN_MODE DATABASE_ROLE FLASHBACK_ON
-------------------- ---------------- ------------------
MOUNTED PHYSICAL STANDBY YES
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
Database altered.
SQL> alter database open;
Database altered.
SQL> select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database;
OPEN_MODE DATABASE_ROLE FLASHBACK_ON
-------------------- ---------------- ------------------
READ WRITE SNAPSHOT STANDBY YES
Schritt 2: SAP-Konfiguration auf Standby anpassen, um System startbar zu machen – also durch
Replizierung „falschen“ Hostnamen ändern:
itrs26:sd3adm 1> cd /sapmnt/SD3/profile
itrs26:sd3adm 2> sed 's/odrs46/itrs26/g' SD3_DVEBMGS15_odrs46 >
SD3_DVEBMGS15_itrs26
itrs26:sd3adm 3> sed 's/odrs46/itrs26/g' START_DVEBMGS15_odrs46 >
START_DVEBMGS15_itrs26
itrs26:sd3adm 4> sed 's/odrs46/itrs26/g' DEFAULT.PFL > DEFAULT.PFL_itrs26
itrs26:sd3adm 5> mv DEFAULT.PFL_itrs26 DEFAULT.PFL
Schritt 3: Batch-Prozesse auskommentieren:
itrs26:sd3adm 7> grep btc SD3_DVEBMGS15_itrs26
#rdisp/wp_no_btc = 3
Schritt 4: SAP Instanz starten:
Optionaler Test: itrs26:sd3adm 1> R3trans -d
This is R3trans version 6.14 (release 700 - 09.04.10 - 11:26:00).
unicode enabled version
R3trans finished (0000).
Start: itrs26:sd3adm 2> startsap
Checking SD3_itrs26 Database
------------------------------
ABAP Database is running
Starting SAP-Collector Daemon
------------------------------
...
Starting SAP Instance DVEBMGS15
------------------------------
Startup-Log is written to /home/sd3adm/startsap_DVEBMGS15.log
Instance Service on host itrs26 started
Instance on host itrs26 started
Schritt 5: Anmeldung an SAP möglich, Fehlerbehebungen etc.
Abb. 5: SAP Instanz auf Snapshot Standby gestartet.
Bei der Fehlerbehebung sollte beachtet werden, dass diese nicht „beliebig lange“ dauern darf, da nun
Primary und Standby zeitlich „auseinanderlaufen“ und somit die Zeit für ein Failover im
Katastrophenfalle mit zunehmendem Zeitversatz länger wird (die zwischenzeitlich anfallenden Redo
Informationen müssen ja nach Zurückumwandeln der Snapshot Standby noch alle appliziert werden,
wobei auch die Zurückumwandlung selbst länger dauern kann, wenn „viel“ in der SAP Instanz
geändert wird.)
Schritt 6: Re-Aktivierung der normalen Physical Standby nach Beendigung der Fehlerbehebung:
Hierzu wird die SAP Instanz gestoppt; Filesystem-Replizierung etc. kann wieder gestartet werden.
itrs26:sd3adm 1> stopsap
Checking SD3_itrs26 Database
------------------------------
ABAP Database is running
Stopping the SAP instance DVEBMGS15
----------------------------------
Shutdown-Log is written to /home/sd3adm/stopsap_DVEBMGS15.log
Instance on host itrs26 stopped
Waiting for cleanup of resources....................
Running /usr/sap/SD3/SYS/exe/run/stopdb
Trying to stop SD3_itrs26 database ...
Log file: /home/sd3adm/stopdb.log
SD3_itrs26 database stopped
/usr/sap/SD3/SYS/exe/run/stopdb completed successfully
Checking SD3_itrs26 Database
------------------------------
ABAP Database is not available via R3trans
… anschließend kann die Datenbank wieder umgewandelt werden:
SQL> startup mount
...
Database mounted.
SQL> select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database;
OPEN_MODE DATABASE_ROLE FLASHBACK_ON
-------------------- ---------------- ------------------
MOUNTED SNAPSHOT STANDBY YES
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
Database altered.
SQL> select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database;
select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database
*
ERROR at line 1:
ORA-01507: database not mounted
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted
Die Datenbank ist nach der Konvertierung zunächst nicht gemounted und muss zum Mounten auch
erst gestoppt werden:
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
...
Database mounted.
SQL> select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database;
OPEN_MODE DATABASE_ROLE FLASHBACK_ON
-------------------- ---------------- ------------------
MOUNTED PHYSICAL STANDBY YES
Wenn der Data Guard Broker aktiv ist, wird nun beim Mounten auch das Managed Recovery sofort
wieder gestartet und alle inzwischen angefallenen Redo Logs der Primary nachgefahren. Ohne Data
Guard Broker wird dies nun manuell gestartet.
e. Fehlersituationen im Umfeld Flashback Database / Snapshot Standby
Im folgenden werden einige mögliche Fehlersituationen kurz dargestellt. Im SAP-Umfeld können
viele Funktionalitäten im Umfeld Flashback Database auch mit den SAP „BR*Tools“ ausgeführt
werden, womit das Fehlerrisiko reduziert wird. So übernehmen die „BR*Tools“ beispielsweise auch
das Redo Log-Handling (Restore zusätzlich benötigter Redo Logs, falls bereits archiviert und
gelöscht). Auf diese Tools wird in diesem Vortrag jedoch nicht näher eingegangen.
aa. Fehlende Redo Logs
Die Datenbank prüft beim Absetzen eines Flashback Database Kommandos zunächst, ob alle
benötigten Redo Logs für das im Hintergrund auszuführende Point-in-Time-Recovery verfügbar sind.
Fehlen Redo Logs, wird das Flashback nicht gestartet:
SQL> FLASHBACK DATABASE TO TIMESTAMP TO_DATE('2011-10-06 13:17:00','YYYY-
MM-DD HH24:MI:SS');
FLASHBACK DATABASE TO TIMESTAMP TO_DATE('2011-10-06 13:17:00','YYYY-MM-DD
HH24:MI:SS')
*
ERROR at line 1:
ORA-38754: FLASHBACK DATABASE not started; required redo log is not
available
ORA-38762: redo logs needed for SCN 26679152 to SCN 26684180
ORA-38761: redo log sequence 7691 in thread 1, incarnation 1 could not be
accessed
Mit dieser Information kann ermittelt werden, welche weiteren Redo Logs fehlen.
Erstes Redo Log: SQL> select distinct THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# from
V$ARCHIVED_LOG where 26679152 between FIRST_CHANGE# and NEXT_CHANGE#-1;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 7690 26678852 26680922
Letztes Redo Log: SQL> select distinct THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# from
V$ARCHIVED_LOG where 26684180 between FIRST_CHANGE# and NEXT_CHANGE#-1;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 7691 26680922 26684181
in diesem Fall müßten also die Redo Logs mit Sequenz-Nr. 7690 bis 7691 zunächst restored
werden.
bb. FRA zu klein für garantierten Restore-Punkt
Insbesondere beim Setzen eines garantierten Restore-Punktes auf der Primärseite (Produktivsystem)
muss darauf geachtet werden, dass die Fast Recovery Area groß genug dimensioniert ist. Ansonsten
kommt es zum Einfrieren des Systems wie bei einem Archiver Stuck – SAP-User sehen dann „die
Sanduhr“, im alert.log wiederholen sich Meldungen der Art:
Wed Oct 12 23:02:08 2011
*************************************************************
Unable to allocate flashback log of 486 blocks from
current recovery area of size 52428800 bytes.
Recovery Writer (RVWR) is stuck until more space
is available in the recovery area.
Unable to write Flashback database log data because the
recovery area is full, presence of a guaranteed
restore point and no reusable flashback logs.
Abhilfe in diesem Fall:
- entweder FRA vergrößern (DB_RECOVERY_FILE_DEST_SIZE), dabei auf genügend Freiplatz
im Filesystem achten
- oder Restore-Punkt verwerfen (drop restore point …)
cc. FRA zu klein für „retention target“
Wenn im Falle von aktiviertem „normalen“ Flashback die FRA für die vorgegebene Aufbewahrungs-
zeit DB_FLASHBACK_RETENTION_TARGET nicht ausreicht, verwirft die Datenbank automatisch
die ältesten Flashback Logs, da mit dem „target“ keine Garantie verbunden ist. Es passiert also „weiter
nichts“, als dass ein möglicher Flashback eben nicht mehr so weit in die Vergangenheit zurückgehen
kann, wie ursprünglich avisiert.
Ebenso kann die DB_RECOVERY_FILE_DEST_SIZE jederzeit verkleinert werden. Auch hier
werden nötigenfalls die ältesten Logs verworfen, auch wenn dann DB_FLASHBACK_RETEN-
TION_TARGET nicht mehr eingehalten werden kann.
Beispiel:
Status vor Verkleinerung (bei DB_FLASHBACK_RETENTION_TARGET=1440, also 1 Tag):
SQL> SELECT OLDEST_FLASHBACK_SCN, TO_CHAR(OLDEST_FLASHBACK_TIME,
'YYYY-MON-DD HH24:MI:SS'), TO_CHAR(SYSDATE, 'YYYY-MON-DD HH24:MI:SS')
FROM V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN TO_CHAR(OLDEST_FLASHBACK_T TO_CHAR(SYSDATE,'YYYY-MON-
-------------------- -------------------------- --------------------------
28466770 2011-OCT-06 15:05:20 2011-OCT-12 16:18:30
man käme also mehrere Tage zurück.
SQL> SELECT * FROM V$RECOVERY_FILE_DEST;
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------ ----------- ---------- ----------------- ---------------
/oracle/SD3/oraflash 5242880000 1206337536 513589248 303
die Datenbank könnte sogar noch 500M Files löschen, um das „target“ noch eizuhalten (ca. 700M
würden dann noch verbleiben).
SQL> SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------- ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 0 0 0
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 23.01 9.8 303
FOREIGN ARCHIVED LOG 0 0 0
7 rows selected.
nun Verkleinerung der DB_RECOVERY_FILE_DEST_SIZE auf „zu kleinen“ Wert (bezogen auf
obige Belegungsdaten):
SQL> alter system set db_recovery_file_dest_size = 500M scope=both;
System altered.
Die DB setzt dies um, löscht entsprechend die ältesten Flashback Logs und warnt, dass FRA voll, wie
im alert.log zu sehen ist:
Wed Oct 12 16:20:44 2011
ALTER SYSTEM SET db_recovery_file_dest_size='500M' SCOPE=BOTH;
Wed Oct 12 16:20:44 2011
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798cyyyd_.flb
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798hh64r_.flb
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798m7ybs_.flb
...
...
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798xlyr3_.flb
Deleted Oracle managed file
/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798xlz0g_.flb
Errors in file
/oracle/SD3/saptrace/diag/rdbms/sd3_itrs26/SD3/trace/SD3_m000_40108294.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 524288000 bytes is 99.48%
used, and has 2736128 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Mit den obigen Abfragen sieht man, dass man nun nicht mehr so weit wie gewünscht zurück kommen
kann, und dass die FRA „voll“ ist:
SQL> SELECT OLDEST_FLASHBACK_SCN, TO_CHAR(OLDEST_FLASHBACK_TIME,
'YYYY-MON-DD HH24:MI:SS'), TO_CHAR(SYSDATE, 'YYYY-MON-DD HH24:MI:SS')
FROM V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN TO_CHAR(OLDEST_FLASHBACK_T TO_CHAR(SYSDATE,'YYYY-MON-
-------------------- -------------------------- --------------------------
27365709 2011-OCT-11 18:57:47 2011-OCT-12 16:23:06
man käme also nur noch ca. 21 Stunden statt 1 Tag zurück und FRA ist praktisch voll:
SQL> SELECT * FROM V$RECOVERY_FILE_DEST;
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------ ----------- ---------- ----------------- ---------------
/oracle/SD3/oraflash 524288000 521551872 0 131
SQL> SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------- ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 0 0 0
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 99.48 0 131
FOREIGN ARCHIVED LOG 0 0 0
7 rows selected.
5. Zusammenfassung
Seit der SAP-Freigabe für Oracle 11g Release 2 im Frühjahr 2010 setzt auch Freudenberg IT dieses
Release bei Kundensystemen ein. Mit diesem Release kamen im Data Guard Umfeld wieder einige
interessante Neuerungen hinzu. In Kombination mit dem bereits seit Oracle 10g verfügbaren
Flashback Database stehen nun eine Reihe von Möglichkeiten zur Verfügung, in Fehlerfällen ein SAP-
System ohne Restore auf einen früheren Stand zurückzusetzen. Dank der Snapshot Standby
Funktionalität kann man jetzt auch sehr bequem „Einblick in einen früheren Stand“ mittels SAP-
Oberfläche erhalten. Da dies auf der Standby Seite geschieht, bleibt das Produktivsystem selbst stets
unangetastet und trotz des lesenden und schreibenden Einsatzes auf der Standby Seite ein
eingerichteter Desaster-Schutz aktiv. Die Kombination Flashback Database mit Snapshot Standby
bietet eine Flexibilität, die keine andere Backup/Restore-Technologie leisten kann.
6. Kontaktadressen:
Dr. Thimo Bastuck
Freudenberg IT
Höhnerweg 2 – 4
D-69469 Weinheim
Telefon: +49(0) 6201 80-8000
Fax: +49(0) 6201 88-8000
E-Mail: [email protected]
Internet: http://www.freudenberg-it.com
Claudia Hüffer
Oracle Deutschland B.V. & Co. KG
Kühnehöfe 5
D-22761 Hamburg
Telefon: +49(0) 40 89091-135
Fax: +49(0) 40 89091-250
E-Mail: [email protected]
Internet: http://www.oracle.com