Data Guard 11.2: Flashback Database und Snapshot … · einem Zeitpunkt in der (nahen)...

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.


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



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:



-------------------- ----------------

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


/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;




Completed: alter database convert to physical standby

Ein erneutes Durchstarten zeigt dann wieder den Status als Physical Standby Datenbank:



-------------------- ----------------

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.


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.


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:



-------------------- ----------------

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> 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:



-------------------- ----------------

READ WRITE SNAPSHOT STANDBY


SPALTE1 SPALTE2

---------- ------------------------------



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.


1 row created.


1 row created.


SPALTE1 SPALTE2

---------- ------------------------------



3 Das ist Alternativ-Eintrag 1



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>


SPALTE1 SPALTE2

---------- ------------------------------



SQL> recover managed standby database using current logfile disconnect;



SPALTE1 SPALTE2

---------- ------------------------------



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:

Abb. 2a,b: Systemänderung 1: Löschen der Logon-Gruppe (vorher/nachher)

Abb. 3a,b: Systemänderung 2: Anlegen eines neuen Mandanten (vorher/nachher)

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.

Abb. 4a,b: nach Flashback: alter Zustand wieder hergestellt.

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


/oracle/SD3/oraflash/SD3_ODRS46/flashback/o1_mf_79cwpzkv_.flb


/oracle/SD3/oraflash/SD3_ODRS46/flashback/o1_mf_79cwq113_.flb


/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:


System altered.

SQL> alter system set db_recovery_file_dest = '/oracle/SD3/oraflash'

scope=both;

System altered.



SQL> ALTER DATABASE FLASHBACK ON;

Database altered.




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


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


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


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


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.



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.


...

...

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> 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.


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.


SQL> select status from v$instance;

STATUS

------------

MOUNTED


Database altered.


...

...

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:


MM-DD HH24:MI:SS');

Flashback complete.


Database altered.


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.



Database altered.


...

...

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.



-------------------- ---------------- ------------------

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


------------------------------

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


------------------------------

ABAP Database is not available via R3trans

… anschließend kann die Datenbank wieder umgewandelt werden:

SQL> startup mount

...

Database mounted.



-------------------- ---------------- ------------------

MOUNTED SNAPSHOT STANDBY YES

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Database altered.


select OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from v$database

*

ERROR at line 1:


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


ORACLE instance shut down.

SQL> startup mount

...

Database mounted.



-------------------- ---------------- ------------------

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:


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;


-------------- ------------------ ------------------------- ---------------

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


7 rows selected.

nun Verkleinerung der DB_RECOVERY_FILE_DEST_SIZE auf „zu kleinen“ Wert (bezogen auf

obige Belegungsdaten):


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


/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798cyyyd_.flb


/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798hh64r_.flb


/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798m7ybs_.flb

...

...


/oracle/SD3/oraflash/SD3_ITRS26/flashback/o1_mf_798xlyr3_.flb


/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;


-------------- ------------------ ------------------------- ---------------

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


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

Data Guard 11.2: Flashback Database und Snapshot … · einem Zeitpunkt in der (nahen)...

Documents

Transcript of Data Guard 11.2: Flashback Database und Snapshot … · einem Zeitpunkt in der (nahen)...