Oracle9i: Frage zu Recovery mit RMAN

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo,

Am Wochenende soll eine Applikation umgestellt werden (produktiv), wobei
nicht feststeht, ob am Montag der Stand von Freitag doch wiederhergestellt werden muss.
Es wird gefordert, dass die DB so schnell wie möglich wieder zur Verfügung steht.

Es handelt sich um ORACLE 9.2 auf Solaris und gesichert wird mit dem RMAN.

Mein Chef möchte nun die Sicherung der Prod-DB (Stand Freitag nachmittag)
auf einen anderen Server hochfahren .
Läuft die Umstellung schief, soll am Montag auf die 2.DB mit dem Freitagstand umgeschaltet werden.
Da beide Server in einem Veritas Cluster liegen, bekäme der anderen Server dieselbe IP und man bräuchte
die TNSNAMES.ORA nicht umzustellen.

Leider habe ich noch nie mit dem RMAN gearbeitet und hier kennt sich auch keiner richtig aus.
In der Doku habe ich gelesen, dass es mehrere Möglichkeiten gibt:
-) Restore auf einen anderen Host(mit nocatalog-Option)
-) Duplicate (wobei die DB eine neue DBID bekommt)
-) Duplicate for Standby (wobei die DB dieselbe DBID besitzt wie die produktive)

Welche Option muss ich in meinem Fall benutzen?
Muss ich dieselbe DBID nachher besitzen, hat es irgendwelche Auswirkungen, wenn ich eine andere DBID
bekomme? Kann man eine Standby-DB erstellen, danach runterfahren (so dass der Freitagstand konserviert wird)
und im Notfall am Montag einfach diese hochfahren, ohne dass die Änderungen vom Wochenende drin enthalten sind?

Ich hatte eigentlich gedacht, ich könnte mit dem RMAN am Montag ein „restore database“ absetzen
und die DB danach hochfahren, ohne ein „recover database“ abzusetzen, um die Files des Backups an ihre Stelle zu kopieren.
Ist eine 2.DB eine bessere/schnellere Lösung?

viele Grüsse
Regine

#2

Hallo Regine

Hallo,

Am Wochenende soll eine Applikation umgestellt werden
(produktiv), wobei
nicht feststeht, ob am Montag der Stand von Freitag doch
wiederhergestellt werden muss.
Es wird gefordert, dass die DB so schnell wie möglich wieder
zur Verfügung steht.

Wie schnell? Darf es etwas kosten?
Wie schnell muss das Backup gehen?
Wie schnell das Recovery?
Hast du Tapes oder genug Disk-Space?
Wie schickst du die Daten auf die Tapes?
Wie gross ist die DB?

Es handelt sich um ORACLE 9.2 auf Solaris und gesichert wird
mit dem RMAN.

Mein Chef möchte nun die Sicherung der Prod-DB (Stand Freitag
nachmittag)
auf einen anderen Server hochfahren .
Läuft die Umstellung schief, soll am Montag auf die 2.DB mit
dem Freitagstand umgeschaltet werden.
Da beide Server in einem Veritas Cluster liegen, bekäme der
anderen Server dieselbe IP und man bräuchte
die TNSNAMES.ORA nicht umzustellen.

Leider habe ich noch nie mit dem RMAN gearbeitet und hier
kennt sich auch keiner richtig aus.
In der Doku habe ich gelesen, dass es mehrere Möglichkeiten
gibt:
-) Restore auf einen anderen Host(mit nocatalog-Option)
-) Duplicate (wobei die DB eine neue DBID bekommt)
-) Duplicate for Standby (wobei die DB dieselbe DBID besitzt
wie die produktive)

da gibt es gute Fallstudien dazu:
$ORACLE_HOME/case1.rcv
$ORACLE_HOME/case2.rcv
$ORACLE_HOME/case3.rcv
$ORACLE_HOME/case4.rcv

Welche Option muss ich in meinem Fall benutzen?
Muss ich dieselbe DBID nachher besitzen, hat es irgendwelche
Auswirkungen, wenn ich eine andere DBID
bekomme?

Alte RMAN backups sind nichts mehr wert.

Kann man eine Standby-DB erstellen, danach

runterfahren (so dass der Freitagstand konserviert wird)
und im Notfall am Montag einfach diese hochfahren, ohne dass
die Änderungen vom Wochenende drin enthalten sind?

Das ist nicht der Job einer StandBy DB.

Ich hatte eigentlich gedacht, ich könnte mit dem RMAN am
Montag ein „restore database“ absetzen
und die DB danach hochfahren, ohne ein „recover database“
abzusetzen, um die Files des Backups an ihre Stelle zu
kopieren.

Braucht ein PITR via RMAN mit resetlogs.

Ist eine 2.DB eine bessere/schnellere Lösung?

Ohne etwas Praxis: Finger weg!
Wenn du die casestudies durchgespielt hast, dann kannst du’s versuchen.

Der sichere, halt nicht so elegante Weg:

  • DB runterfahren
  • alle db files inkl. control, redo, logs, *.ora etc, etc, sichern und dann bei Bedarf wieder alles damit überklatschen.

Noch mehr Möglichkeiten:

  • Point in Time Recovery via rman
  • Wenn du Platz für eine StandBy DB hast, warum nicht einen Klon erstellen, die Leute Wochenende in einem produktiven Test darauf arbeiten lassen? Dann kannst du die heisse DB in Ruhe lassen.

Gruss, Ulrich

#3

Hallo,

ist jetzt vielleicht etwas spät: aber ich würde auf jeden Fall auch ein Export der DB machen. Das lässt sich später viel einfacher und sicherer wieder einspielen.

Gruß

Peter

#4

Hallo,

erstmal danke für Eure Antworten.
Leider konnte ich sie für dieses Wochenende nicht mit einbeziehen, da wir am Freitag um 15:00 Uhr loslegten.

Ich machte vorher Tests mit der Duplicate-Option des RMANs, was zum Schluss auch funktionierte. Erst hatten wir Probleme, die Duplicate-DB hochzufahren. Mein Chef erinnerte sich dann an einen „undokumentierten“ Init.ora-Parameter, den er vor geraumer Zeit aufgrund des Rates des Oracle-Supportes für einen Restore auf einen anderen Server benutzte. Der Parameter „_allow_resetlogs_corruption=true“. Über diesen Parameter konnten wir die neue DB mit open resetlogs öffnen.

Am Freitag mittag also machten wir über den RMAN ein Backup der Produktiv-DB, kopierten das BAckupSet auf den anderen Server und duplizierten die Produktiv-DB über den RMAN auf dem anderen Server.
Diese DB wurde dann im RMAN registriert und eine Sicherung davon gezogen. Alles funktionierte gut. Der Plan war, wenn am Montag etwas schief geht, in der TNSNAMES.ORA der Applik-Server den Host-Eintrag zu ändern (dies musste doch gemacht werden) und die neue DB produktiv zu schalten.
Dann wurde ich nach Hause geschickt, da mein Teil beendet war. In die Aktion am Wochenende wurde ich leider nicht mit einbezogen (ich habe dort erst neu angefangen und vertraut wurde mir bis jetzt noch kein Stück.)

Stand im RMAN-Catalog:
SQL> select * from rc_database;
DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOG

101021 101022 896985542 DIRAYA 1 13/04/04
211180 211181 3681984305 DPDIRAYA 5,3770E+12 11/03/05

Und heute morgen fand ich folgende Situation vor:

Die neue DB war im Einsatz, allerdings nicht so wie vorher geplant.
Die Produktiv-Übergabe der Applikation ging so schief, dass schon am Samstag zurückgefahren werden sollte.
Da am Samstag nicht der Zeitdruck bestand, wie er am Montag morgen bestanden hätte, wurde die 2.DB nicht aktiviert, sondern auf den 1.Server tranferiert und dann aktiviert.
Dabei sind die 2 DBAs am Samstag so vorgegangen:

-) es wurde eine Sicherung des modifizierten Standes der produktiven DB über den RMAN gezogen (DB: DIRAYA, Server: 15k1a)
-) die prod-DB DIRAYA wurde dann gelöscht
-) die DB-Files der duplizierten DB (DB: DPDIRAYA, Server: 15k2a) wurden auf Server-1 gemoved und hochgefahren
(DB-Name immernoch DPDIRAYA, Instance-Name: DIRAYA, Server 15k1a)
-) ohne die DBID zu ändern wurde diese DB dann im RMAN registriert.

In RC_DATABASE findet man immernoch dieselben Einträge, aber RC_DATABASE_INCARNATION sieht wie folgt aus:

SQL> select * from RC_DATABASE_INCARNATION;
DB_KEY DBID DBINC_KEY NAME RESETLOGS_CHANGE# RESETLOG CUR PARENT_DBINC_KEY

101021 896985542 101022 DIRAYA 1 13/04/04 YES
211180 3681984305 211181 DPDIRAYA 5,3770E+12 11/03/05 YES
211180 3681984305 211207 UNKNOWN 1 13/04/04 NO

Über den RMAN kann man keine der DBs mehr erreichen.
…und bis 14:00 hatten wir keine verwendbare Sicherung der z.Z. produktiven DB :frowning:

Die 3 alten DB-Einträge wurden aus dem RMAN entfernt (über unregister), die aktuelle DB neu registriert und eine Sicherung gezogen.

Diese Sicherung wird jetzt wieder auf den 2.Server kopiert und nach der Siesta geht das Spektakel weiter (hier in Andalusien lassen wir mittags nur die Server arbeiten). Es wird wieder die akt. DB dupliziert und darauf die „Übergabe getestet“.

Soweit der Stand
viele Grüße
Regine

#5

Hallo Regine
Da gibt’s ja viel dabei zu lernen.
Die DB scheint ja ziemlich klein zu sein, darum ist mir nicht klar, warum bei einem derart riskanten Vorgehen nicht einfach die DB offline, auf OS-Ebene, gesichert wurde.
So wie’s aussieht, sollte die 2. DB gar nicht in Betrieb genommen werden.
Auch dann noch haette sie offline via OS auf den 2. Server mit dem gleichen DB Namen und der gleichen Physik kopiert und wenn noetig, sofort in Betrieb genommen werden koennen.
RMAN ist zwar grundsaetzlich interessant und zu bevorzugen, in diesem Fall ist er aber nur Balast.

Weiterhin viel Erfolg.
Vertrauen in Neue? Das kann auch bei uns Jahre dauern.

Gruss, Ulrich