Dotaz: Oracle 10g přenesení na jiný stroj.

[majales]

Zdravím, řeším přesun oracle databáze na nový stroj. Jde od 10g, konkrétně 10.2.0.4. Mám nainstalované identické prostředí na CentOS 6 ( Vím, že není podporován ). Jde o proces recovery - přenesl jsem zálohu, ale původní instance stále běží a já potřebuju udělat recovery té zálohy ( je to RAC+ DATAGUARD a nový stroj pouze SINGLE instance ) ale všude v návodech co jsem našel do internetu jsem našel že je potřeba aplikovat toto :

ALTER DATABASE OPEN RESETLOGS

To ale znamená, že ztratím sekvenci logu a abych se dostal na současný stav produkční databáze budu muset udělat zálohu znovu ( předpokládám při zastavené současné produkční databázi) a přenést a znovu udělat recovery?? Nešlo by přenést pouze rozdíl mezi tou poslední zálohou a novám stavem aplikovat pouze ten rozdíl? (DB má totiž cca 350GB)

Něvěděl by někdo jak do toho? Dík

---

---

Odpovědi

[Ivan]

K cemu to potrebujes? Pro reporting? Pro vyvoj? Na reset logs neni nic spatnyho - pokud to nechces pouzivat jako stand-by databazi.

Muzes taky prenest redology a pouzit 'recever database until cancel' anebo 'recover database until timestamp'.

Kazdopadne jakmile jednou otevres tu databazi i pro zapis, tak uz nebus moct aplikovat zadne redo-logy z primarniho systemu.

[majales]

Je to kvůli tomu že se ruší původní instalace kvůli drahému housingu a zastaralému HW bez podpory. Můžu otevřít přenesenou databázi pro zápis a pak se vrátit k timestampu a aplikovat přenesené redology z původní instalace? Právě kvůli tomu mi tam nesedí to reset logs.

[majales]

Aha ty chces udelat migraci s minimalnim downtime? A zaroven overit ze jsou data OK? Myslim, ze to co chces uplne nejde - ani kdybys pouzil flashback database. Muzes pouzit `recover database until time` (PITR). Tim se dostanes do stavu, kdy maji vschy datafajly (a controlfajly) stejne SCN. Pak muzes pouzit

ALTER DATABASE OPEN RESETLOGS, ALTER DATABASE OPEN READONLY.

AFAIK Jedine volba READONLY ti umozni cist z databaze a mit jeste moznost aplikovat redo-logy z primarniho systemu. RESETLOGS ti zvysi "incarnation number" http://docs.oracle.com/cd/B19306_01/backup.102/b14192/flashptr006.htm.

Pokud bys pouzil pouze "OPEN", tak by byl Oracle zmatenej (minimalne RMAN).

Database Incarnations

A database incarnation is created whenever you open the database with the RESETLOGS option. After complete recovery, you can resume normal operations without an OPEN RESETLOGS. After a DBPITR or recovery with a backup control file, however, you must open the database with the RESETLOGS option, thereby creating a new incarnation of the database. The database requires a new incarnation to avoid confusion when two different redo streams have the same SCNs, but occurred at different times. If you apply the wrong redo to your database, then you will corrupt it.

The existence of multiple incarnations of a single database determines how RMAN treats backups that are not in the current incarnation path. In almost all cases, the current database incarnation is the correct one to use. Nevertheless, in some cases resetting the database to a previous incarnation is the best approach. For example, you may be dissatisfied with the results of a point-in-time recovery that you have already performed and want to return the database to a time before the RESETLOGS. An understanding of database incarnations is helpful to prepare for such situations.

PS: mozna by sly delat nejaky cachry se "stand-by" controlfile ale to moc nedoporucuju.

[majales]

OK. dík za vysvětlení. Asi bude nejbezpečnější po ověření že ten backup co mám funguje zastavit současnou databázi a udělat cold backup, přenést ho do nové instalace a udělat znovu restore.

[Ivan]

Jeste dodam, ze po cross-site restore be se mel pouzit prikaz nid, aby se vygenerovalo nove dbid.

How to Rename Database/Change DB_NAME or ORACLE_SID/Instance Name [ID 15390.1] How to Change the DBID, DBNAME Using NID Utility in version 10gR2 onwards [ID 863800.1] Changing DBNAME and DBID of RAC Database Using NID [ID 464922.1] How to Change the DBID and the DBNAME by using NID [ID 224266.1]

[rich]

"Jeste dodam, ze po cross-site restore be se mel pouzit prikaz nid, aby se vygenerovalo nove dbid." to ale neni vubec nutne...

[rich]

"zastavit současnou databázi a udělat cold backup, přenést ho do nové instalace a udělat znovu restore."
vlastne taky moznost... ale muze stacit jen vytvorit novy controlfile... recovery nemusi byt potreba pokud budou datave soubory konzistentni
jinak teda restore a recovery jsou dve veci...

[rich]

"ALTER DATABASE OPEN RESETLOGS, ALTER DATABASE OPEN READONLY. AFAIK Jedine volba READONLY ti umozni cist z databaze a mit jeste moznost aplikovat redo-logy z primarniho systemu"
tak toto prave mozne NENI. Po RESETLOGS uz nelze dohrat jakoli transakce z archivnich logu, prave kvuli zmene inkarnace...
proste po preneseni db do nove lokace jsou potrebne archlogy od casu provedeni kopie do pozadovaneho casu...

[rich]

"Po RESETLOGS uz nelze dohrat jakoli transakce z archivnich logu, prave kvuli zmene inkarnace... "
a logsequence taky

[rich]

Presun muzes resit nekolika zpusoby. Duplikaci, viz. RMAN prikaz DUPLICATE. S tim, ze mas pripravenou instance, treba na jinem serveru. Podle me je to asi nejrychlejsi metoda. Dalsi moznost udelat full backup + archivni logy (ze vsech vlaken clusteru) a zkopirovat do cilove lokace. "ALTER DATABASE OPEN RESETLOGS" je vyzadovano po "incomplete recovery" (data jsou samozrejme v poradku nebo treba "flashback database" a pouze resetuje sekvenci logu a vyprazdni jeho obsah, ktery nebyl aplikovan v prubehu recovery. Taky meni inkarnaci databaze.

[mps]

A nemozes to spravit cez standby databazu , aplikovat logy az do momentu, kedy povodnu DB zhodis, prenesies posledny archivny log + redo a standby dvihnes ?