Administrace komentářů

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.