DB recovery

Hov .. den nederste linie skal lige droppes :)

Before we can restore a backup from before the last resetlogs, we need to reset 
the database to the old incarnation number.

Here are the steps to reseting the correct incarnation and restoring the 
database to a point in time before the last resetlogs.

Note: Target database should be nomounted.

1. Start RMAN and connect only to the catalog database.

  % rman catalog rman/rman@rcat

2. Execute the command that lists all the incarnation values for the         
  databases in the recovery catalog.

    RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            CUR Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1      2      R815    579966833        NO  1          03-MAR-99
224    225    R815    579966833        YES 92402      05-MAY-99

We can see that one of the databases had been open with resetlogs and a new 
incarnation was started (DB_ID 579966833).  We should look at the column 
DATABASE INC KEY. We can see the original incarnation for this database was 2 
and was reset to what is still the current incarnation of 225.  2 is the 
database incarnation that has to be set in order to restore a backup from 
before the last resetlogs.

3. We first need to let RMAN know what database ID we will be dealing 
  with, so we execute the following command:
       
    RMAN> Set dbid 579966833;

4. Now we need to connect to the target instance so we can verify the 
  database ID.

    RMAN> connect target
    RMAN-06005: connected to target database: R815 (DBID=579966833)

5. Since we are connected to both the recovery catalog and target 
  database, we need to tell RMAN to reset the database incarnation to 2. 

  We do this with the following command:

      RMAN> reset database to incarnation 2;

  We can now see that the current incarnation has been set back to 2.
       
      RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            CUR Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1      2      R815    579966833        YES 1          03-MAY-99
224    225    R815    579966833        NO  92402      05-MAY-99


6.  After resetting the database, issue restore and recover commands to restore 
    and recover the database files from the prior incarnation, then open the database 
    with the RESETLOGS option. You need start from restoring a previous incarnation 
    control file when the database is in nomount state. When the database is reset to 
    the previous incarnation, the catalog will automatically picks up a right control 
    file. After restoring the control file, the database must be mounted for datafiles 
    restore. 

    run {
        set until time 'Jul 8 1999 07:55:00'; # set time to just before data was lost
        allocate channel dev1 type disk;
        shutdown abort;
        startup nomount;
        restore controlfile;
        alter database mount; # mount database after restoring control file
        restore database;
        recover database;
        alter database open resetlogs; # this command automatically resets the database
                                        # so that this incarnation is the new incarnation
    }

     
Solution Explanation: 
===================== 
 
Once we set the database to the prior incarnation, RMAN will allow a restore 
and recover of the database using a backup from before the last resetlogs.

Det var svar på dit 2. spørgmål...

Spørgmål 1:
Nej du skal ikke installere andet end din oracle software - sørg for at det er nøjagtigt samme version (incl. patches!)
Restore derefter din init.ora fra din filbackup. Så sikre du at du får startet databasen med samme parameter som før den gik ned.

Ok - jeg laver lige et par punkt spørgsmål:

1. Jeg kører ikke recovery catalog - er det et problem ?

2. Dvs. Jeg skal ikke bruge noget fra min kolde backup overhovedet udover at kopierer min init.ora over i den ny database


Det skal lige tilføjes at den backup løsning jeg ønsker egentlig kun skal bruges når serveren f.eks. en dag bryder sammen. Skulle databasen blive korrupt eller lign, vil jeg ligge hele databasen på igen, da data tab er iorden

6.  After resetting the database, issue restore and recover commands to restore 
    and recover the database files from the prior incarnation, then open the database 
    with the RESETLOGS option6.  After resetting the database, issue restore and recover commands to restore 
    and recover the database files from the prior incarnation, then open the database 
    with the RESETLOGS option

Hvilke restore og recover kommando´er er det der skal køres ? - det fremgår ikke af teksten :(

:(

Du spørger om noget der normalt kan tage op til en uge at lære noget om på et backup og recovery kursus. Det er et meget ømt punkt som kan gøre mere skade end man tror. Hvis du f.eks. ikke får redirected din backup til en anden destination end dit prod system, kan du risikere at få overskrevet prod systemet.

Men svar på dit sidste spørgsmål:
Det kunne f.eks. være "recover database until cancel" eller until time.
Og når du har recoveret til det tidspunkt du ønsker - "alter database open resetlogs"

>>1. Jeg kører ikke recovery catalog - er det et problem ?
Nej - ikke i dette tilfælde - men det kan det være i andre!

>>2. Dvs. Jeg skal ikke bruge noget fra min kolde backup overhovedet udover at kopierer min init.ora over i den ny database.
Nope.

Nu har jeg efterhånden bøvlet og bikset med backup/recovery en uges tid - og har fundet lidt info hist og pist.

Det jeg har prøvet om som faktisk er lykkedes er følgende:

Først har jeg installeret Oracle database med samme navn som på produktions databasen.

Derefter har jeg via min kolde backup kopieret database filerne over på min lokale pc.

Derefter har jeg restored min kontrolfil seneste backup sæt, hvorefter den meldte at databasen mangler recovery, da den jo kan se at de data der ligger er forældet i forhold til den seneste kontrolfil indhold.

Så laver jeg en restore database og derefter recover database og derefter kørte det. Redolog filerne fandt jeg dog ud af der skulle kopieres med over - med mindre en resetlogs havde været nok ?! ..

Hvad siger du til ovenstående ... ? .. er det helt hen i vejret rent sikkerhedsmæssigt.?

Det lyder jo som om det er lykkedes. Bare husk at brug den gamle init.ora fil!

>>er det helt hen i vejret rent sikkerhedsmæssigt.?
næh.. det er sådan man gør.