Archivelogs: recovery.

Hello
I have troubles with db recovery.
I have db running in archivelog mode. I backup my db every day at 2 am by dumping it. Now I wanted to try some recovery actions. The import of dumped db goes without any troubles but I want also to recover changes that have been made since dump and which are stored in archivelogs.
Here comes my problem. When I do recovery from archivelog (using SQLplus or Qbackup - additional tool) Oracle wants archivelog with file name like 00000001. The proper archivelog to start with has name about 00000480. How to make Oracle to get the proper archivelog and then go to next, next until recovery is done?

1) Thank You guys for links. I will read the docs and hope it will help me.
2)
You are unclear with your requirements. Be more >specific about your requirements to advice you.Ok, so i will describe the situation of DB system that i met and the solution that have been made and which i have to check and improve.
The Firm is using an old managing application written in clipper. The network I can show as:
[Oracle server]-[Mediator server/Oracle second]-[users]
User application connects to Mediator server and the Mediator application connects to Oracle and serves data back to users.
On the Mediator server i have second Oracle instance which is runing but not mounted. Qbackup is used to restore data base using archivelogs generated on the main db server. This is the first security level - when main Oracle server fails we can quickly set up secondary one by opening db and changing Mediator settings.
The main server also exports the db at 2 am. This is second security level and I wanted to check what can i get from this dump (which is stored on the streamer tapes). I thought that I can set up new db using import and then recover last few hours using archivelogs - but You have told me that is impossibile.
The advice i ask for is how to store db on the tapes to get as much as is possible when something bad happens.
Thank You for Help :-)

Similar Messages

  • Permissions error when starting archivelog recovery during active dup

    I am doing an active duplication from one linux server to another. The ASM system on the auxiliary server has two data groups. I just ran this same job to create a database to one of the datagroups a few days ago - no problem. Now, running the same job I got an error once the duplication got to the recovery step. The archivelogs had been laid down and do exist on the auxiliary server's asm diskgroup.
    Here is the job I am running from the target(source) server:
    $ORACLE_HOME/bin/rman <<EOF>> stagenew-2011-04-06.out
    connect auxiliary sys/abcdefg@stagenew
    connect target sys/abcdefg@xcede
    run
    allocate channel c1 device type DISK;
    allocate channel c2 device type DISK;
    allocate channel c3 device type DISK;
    allocate channel c4 device type DISK;
    allocate auxiliary channel x5 device type DISK;
    allocate auxiliary channel x6 device type DISK;
    allocate auxiliary channel x7 device type DISK;
    allocate auxiliary channel x8 device type DISK;
    duplicate target database to stage from active database NOFILENAMECHECK;
    EOF
    echo "finished"
    exit
    And here is the error:
    archived log for thread 1 with sequence 181831 is already on disk as file +DATA01/stage/archivelog/2011_04_05/thread_1_seq_181831.1615.747682059
    archived log for thread 1 with sequence 181832 is already on disk as file +DATA01/stage/archivelog/2011_04_05/thread_1_seq_181832.1614.747682059
    archived log for thread 1 with sequence 181833 is already on disk as file +DATA01/stage/archivelog/2011_04_05/thread_1_seq_181833.1645.747682067
    archived log file name=+DATA01/stage/archivelog/2011_04_05/thread_1_seq_181816.914.747681987 thread=1 sequence=181816
    released channel: c1
    released channel: c2
    released channel: c3
    released channel: c4
    released channel: x5
    released channel: x6
    released channel: x7
    released channel: x8
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of Duplicate Db command at 04/05/2011 17:31:24
    RMAN-03015: error occurred in stored script Memory Script
    RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '+DATA01/stage/archivelog/2011_04_05/thread_1_seq_181816.914.747681987'
    ORA-00308: cannot open archived log '+DATA01/stage/archivelog/2011_04_05/thread_1_seq_181816.914.747681987'
    ORA-17503: ksfdopn:2 Failed to open file +DATA01/stage/archivelog/2011_04_05/thread_1_seq_181816.914.747681987
    ORA-15055: unable to connect to ASM instance
    ORA-01031: insufficient privileges
    RMAN>
    Recovery Manager complete.
    ******* The only difference besides the name of the database being created between the duplication that was successful and this one is that the other created the database on one diskgroup and this job is using the other but as far as I can tell there is no difference between the two other than name. As I said earlier, the logs are there. Here they are:
    ASMCMD> cd data01/stage/archivelog
    ASMCMD> cd 2011_04_05/
    ASMCMD> ls
    thread_1_seq_181816.914.747681987
    thread_1_seq_181817.789.747681987
    thread_1_seq_181818.1637.747681987
    thread_1_seq_181819.1626.747681987
    thread_1_seq_181820.1622.747681995
    thread_1_seq_181821.1621.747681995
    thread_1_seq_181822.1620.747682009
    thread_1_seq_181823.1619.747682013
    thread_1_seq_181824.1612.747682015
    thread_1_seq_181825.1613.747682029
    thread_1_seq_181826.1617.747682029
    thread_1_seq_181827.1618.747682029
    thread_1_seq_181828.1611.747682037
    thread_1_seq_181829.1616.747682051
    thread_1_seq_181830.1610.747682053
    thread_1_seq_181831.1615.747682059
    thread_1_seq_181832.1614.747682059
    thread_1_seq_181833.1645.747682067
    So I would think that recovery would be running as 'SYS' and that 'SYS' does not have the permissions it needs....but ran same job for different db and no such issue. Any thoughts?

    Have you created password file and check parameter remote_login_passwordfile for asm and database home on auxiliary node.
    or
    run the command from the auxiliary node

  • Archivelog recover scenario - keep prod test in sync

    geeks and gurus...
    I am testing this db sync scenario and wanted some suggestion on best way to keep prod-test in sync by applying archivelog and using catalog
    db:11gr2
    OS: linux
    day-1:
    1. expdp - impdp prod catalog into new testdb
    2. Restore and recover (dbf, logfile, ctrlfile, archfile) connecting catalog on testdb
    3. don't open testdb database
    more archive logs generated on prod and it gets registered in ctrl file and prod catalog
    day-2: task to restore - recover all generated archivelog on prod to testdb
    1. expdp - impdp prod catalog again into testdb
    2. restore - recover newly created arch files which are registered in day-2 catalog
    Q.
    1. now my confusion is how to restore & recover all new arch files created from day1-2... bkp and archivelog file location is registered in catalog
    2. how to find what all arch files are required for recovery from catalog?
    3. how to tell rman on testdb to recover database until max log sequence from new day-2 catalog?
    I am thinking something like below to use till it gets last available log sequence;
    run {
    restore archivelog;
    recover archivelog;
    }or can I directly recover database until max logseq by connecting catalog?
    rman catalog@testdb target /
    RMAN> recover database until logseq 12345 thread 1;logseq to get from v$log_history...but not sure from prod or testdb I should get max(sequence#) ?
    thanks

    thank you hemant..
    as usual your explanation is very helpful and always makes sense...so I changed my testing procedure little bit inorder to keep different version of catalog...
    Now I am using catalog exp from prod and impdp into xyzdb and using that on day-1 and again expdp-impdp catalog-2 on day-2 into xyzdb
    backup: level-0 backup runs everyday...
    day-1:
    1. expdp - impdp prod catalog as catalog-1 into xyzdb
    2. Restore and recover files on testdb (dbf, logfile, ctrlfile, archfile) connecting catalog-1@xyzdb
    3. don't open testdb database
    more archive logs generated on prod and it gets registered in ctrl file and prod catalog
    day-2: task to restore - recover all generated archivelog on prod to testdb
    1. expdp - impdp prod catalog again into xyzdb as catalog-2
    2. restore all arch files on testdb
          rman connect catalog-2@xyzdb target /
          RMAN> restore archivelog until sequence 123456
         3. recover database
        rman connect catalog-??@xyzdb target /
        RECOVER DATABASE until sequence 123456
    my confusion / question is:
    1. on day-2 for archivelog recovery which catalog to use, is it catalog-1(original restore) or catalog-2 from day-2?
    2. on day-2 if new dbf file was recreated after level-0 then will RMAN recovery manage new addition of dbf file or I have to manually create on testdb?
    3. Will RMAN act differently creation of new dbf file on testdb if I connect via catalog-1 or catalog-2?
    I'm basically trying to handle & understand new dbf file creation which I think will stop recovery on day-2 and have to manually add file in testdb....
    I'm also testing in and let you know the result..
    spell mistake..

  • DB recovery crashes when executed from script, finishes OK manually

    Hello everybody,
    I have a DB restore script which I used/tested a lot of times. On the last run it crashed in the archivelog recovery phase, but I was able to open the instance when applying the remaining commands manually.
    DB is a 10g2 on Solaris 10, I have a full backup made with EMC NetWorker. After taking the backup, the machine was re-installed from scratch (OS, additional 3rd party software, Oracle software and backup client). A new, empty DB instance was also created.
    Restore script performs the following:
    - checks/creates directory structure needed by Oracle instance;
    - stops the listener;
    - shuts down the new instance;
    - startup mount exclusive, enable restricted session;
    - drops database instance via RMAN
    - recovers the orapw, spfile, tnsnames.ora and listener.ora files from the backupset;
    - stars the instance in nomount;
    - replicates the controlfile from a saved copy in the backupset;
    - mounts the instance;
    - starts the following RMAN sequence:
    run {
    set until $LAST_SCN_IN_BACKUPSET;
    allocate channel c3 type 'sbt_tape' parms 'ENV=(....)';
    restore database check readonly;
    recover database check readonly;
    release channel c3;
    sql 'alter database open resetlogs';
    - starts the listener.
    Almost all is performed OK, until the "recover database check readonly" command, where the recover crashes with the following messages:
    Starting recover at 18-FEB-09
    starting media recovery
    channel c3: starting archive log restore to default destination
    channel c3: restoring archive log
    archive log thread=1 sequence=17
    channel c3: reading from backup piece 09k7hb2h_1_1
    channel c3: restored backup piece 1
    piece handle=09k7hb2h_1_1 tag=TAG20090216T181752
    channel c3: restore complete, elapsed time: 00:00:36
    archive log filename=<...>/oracle/oradata/SNM/arch/arch_1_17_678643049.arc thread=1 sequence=17
    released channel: c3
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 02/18/2009 19:58:19
    ORA-00283: recovery session canceled due to errors
    RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '<...>/oracle/oradata/SNM/arch/arch_1_17_678643049.arc'
    ORA-00283: recovery session canceled due to errors
    ORA-19755: could not open change tracking file
    ORA-19750: change tracking file: '/alcatel/oracle/oradata/SNM/bct.dbf'
    ORA-27037: unable to obtain file status
    SVR4 Error: 2: No such file or directory
    Additional information: 3
    Recovery Manager complete.
    The curious thing is that when I ran the following commands manually (from RMAN), the recovery was OK:
    run {
    set until scn $LAST_SCN_IN_BACKUPSET;
    recover database check readonly;
    (finished in a couple of minutes)
    sql 'alter database open resetlogs';
    (finished after a few minutes)
    lsnrctl start (from shell) - OK.
    Could somebody point me to the possible causes of this behavior?
    Thank you all for your time,
    Adrian

    Hi Werner,
    Thank you for your reply.
    Yes, I'm using the block change tracking file. As the DB instance was re-created when the machine was installed, the bct must have been created also. However, in my script I dropped the DB instance, and the bct was, most likely, deleted, as were all the other datafiles.
    After the restore script crashed, I had no bct file in the expected location (which is the location of all the datafiles).
    I'm wondering why the bct could not have been created during the run of the restore script.
    Looking through the alert log, I realise I tried an "alter database open resetlogs" before running the recovery sequence, and at that point, the bct was created.
    Then, the second attempt to open the instance was successfull - please see below the messages from the alert log:
    Thu Feb 19 09:43:47 2009
    alter database open
    Thu Feb 19 09:43:47 2009
    CHANGE TRACKING is enabled for this database, but the
    change tracking file can not be found. Recreating the file.
    Change tracking file recreated.
    Block change tracking file is current.
    ORA-1589 signalled during: alter database open...
    Thu Feb 19 09:43:54 2009
    alter database open resetlogs
    ORA-1196 signalled during: alter database open resetlogs...
    Thu Feb 19 09:48:04 2009
    alter database recover datafile list clear
    Thu Feb 19 09:48:04 2009
    Completed: alter database recover datafile list clear
    Thu Feb 19 09:48:04 2009
    alter database recover datafile list
    1 , 2 , 3 , 4 , 5 , 6 , 7 , 8
    Completed: alter database recover datafile list
    1 , 2 , 3 , 4 , 5 , 6 , 7 , 8
    Thu Feb 19 09:48:04 2009
    alter database recover if needed
    start until change 7033941 using backup controlfile
    Media Recovery Start
    parallel recovery started with 7 processes
    ORA-279 signalled during: alter database recover if needed
    start until change 7033941 using backup controlfile
    Thu Feb 19 09:48:05 2009
    alter database recover logfile '/alcatel/oracle/oradata/SNM/arch/arch_1_17_678643049.arc'
    Thu Feb 19 09:48:05 2009
    Media Recovery Log /alcatel/oracle/oradata/SNM/arch/arch_1_17_678643049.arc
    Thu Feb 19 09:48:43 2009
    Incomplete Recovery applied until change 7033941
    Thu Feb 19 09:48:43 2009
    Media Recovery Complete (SNM)
    Completed: alter database recover logfile '/alcatel/oracle/oradata/SNM/arch/arch_1_17_678643049.arc'
    Thu Feb 19 09:49:10 2009
    alter database open resetlogs
    <....>
    Thu Feb 19 09:50:47 2009
    LOGSTDBY: Validation complete
    Starting control autobackup
    Control autobackup written to DISK device
    handle '/alcatel/oracle/oradata/SNM/flash_recovery_area/SNM/autobackup/2009_02_19/o1_mf_s_679225849_4st3tswj_.bkp'
    Completed: alter database open resetlogs
    So, to recap:
    - bct file not created at first try (restore script);
    - bct file created during the failed attempt to open the db (manual command);
    - second attempt to open the db successfull (manual command).
    The behavior doesn't seem to be systematic, as I don't think this happens every time. In this case, I'm starting to wonder if it wouldn't be a good idea to disable the bct before starting the restore, and then to enable it back when the db is opened.
    Thank you again for your idea,
    Adrian

  • Flash recovery area: archivelog file directory modification time

    Using Oracle Database 10g Release 10.2.0.3.0 - 64bit (Standard Edition) on Solaris 10, SunOS 5.10 Generic_118833-33, archivelog files in the Flash Recovery Area are still present, after the time that they should have been made redundant and therefore deleted::
    bvsmdb01-oracle10g $ date
    Thu Jan 24 16:04:46 GMT 2008
    bvsmdb01-oracle10g $ ls -lt archivelog
    total 20
    drwxr-x--- 2 oracle10g oinstall 1024 Jan 24 16:00 2008_01_24
    drwxr-x--- 2 oracle10g oinstall 512 Jan 23 23:30 2008_01_19
    drwxr-x--- 2 oracle10g oinstall 1536 Jan 23 23:04 2008_01_23
    drwxr-x--- 2 oracle10g oinstall 1536 Jan 22 23:30 2008_01_18
    drwxr-x--- 2 oracle10g oinstall 1536 Jan 22 22:53 2008_01_22
    drwxr-x--- 2 oracle10g oinstall 1024 Jan 21 23:07 2008_01_21
    drwxr-x--- 2 oracle10g oinstall 512 Jan 20 22:20 2008_01_20
    bvsmdb01-oracle10g $
    The archivelog directory for 2008_01_19 has a modification time of Jan 23 23:30 - this is almost 4 days after it was last written to.
    The current redundancy setting in RMAN is shown in the output of show all:
    RMAN> show all;
    using target database control file instead of recovery catalog
    RMAN configuration parameters are:
    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
    CONFIGURE BACKUP OPTIMIZATION OFF; # default
    CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
    CONFIGURE CONTROLFILE AUTOBACKUP ON;
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
    CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
    CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE MAXSETSIZE TO UNLIMITED; # default
    CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
    CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
    CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
    CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/10.2.0/dbs/snapcf_kierli.f'; # default
    So, the current retention policy is three days. It is 24/1 today - the archivelog directory from 19/1 should have been deleted by now, but it has not been.
    The modification time for the archivelog directory 2008_01_19 has a modification time of Jan 23 23:30 2008.
    Why is this? How can this be investigated? Does anyone have any suggestions?
    Thanks
    Jerry Mander

    From 2 Day DBA:
    Even after files in the flash recovery area are obsolete, they are generally not deleted from the flash recovery area until space is needed to store new files. As long as space permits, files recently moved to tape will remain on disk as well, so that they will not have to be retrieved from tape in the event of a recovery.
    What is the current space used in the FRA and what is the FRA disk limit ?

  • How to find what archivelogs are needed for recovery

    From Hemants sir's blog:
    http://hemantoracledba.blogspot.com/2010/03/misinterpreting-restore-database.html
    "You can query V$ARCHIVED_LOG for FIRST_CHANGE# and FIRST_TIME besides SEQUENCE#. That way, you can match SCN (FIRST_CHANGE#), Time and Sequence to determine which ArchiveLogs are need. The RMAN LIST BACKUP command shows you the Checkpoint SCN for all datafiles in a backup, so you need ArchiveLogs from the point of the earliest Checkpoint SCN in that backup set."
    How can i find the earliest checkpoint SCN from the backupsets?
    Any queries to find the earliest SCN in backupset(RC views)?
    Edited by: user9097501 on Aug 10, 2010 6:38 AM

    If i have to refresh the database from the backup of 9-AUG so the earliest SCN from where recovery would be needed is 60279026593 ?
    RMAN> list backup of datafile 1;
    List of Backup Sets
    ===================
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43210 Incr 0 13.25G DISK 03:55:03 25-DEC-2009 15:52
    List of Datafiles in backup set 43210
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 46646244284 25-DEC-2009 11:57 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43210
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 03:55:03 25-DEC-2009 15:51 YES FORCLONE
    List of Backup Pieces for backup set 43210 Copy #1
    BP Key Pc# Status Piece Name
    51423 1 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_1.bak
    51424 2 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_2.bak
    51425 3 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_3.bak
    51426 4 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_4.bak
    51427 5 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_5.bak
    51428 6 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_6.bak
    51429 7 AVAILABLE /backup/bkup_for_clone_GOCPRD_20091225_44019_7.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43367 Incr 0 15.33G DISK 03:39:25 19-FEB-2010 23:43
    List of Datafiles in backup set 43367
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 49260361949 19-FEB-2010 20:03 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43367
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 03:39:25 19-FEB-2010 23:42 YES FORCLONE
    List of Backup Pieces for backup set 43367 Copy #1
    BP Key Pc# Status Piece Name
    51819 1 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_1.bak
    51820 2 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_2.bak
    51821 3 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_3.bak
    51822 4 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_4.bak
    51823 5 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_5.bak
    51824 6 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_6.bak
    51825 7 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_7.bak
    51826 8 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/na1stg/bkup_for_clone_GOCPRD_20100219_44170_8.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43518 Incr 0 13.70G DISK 04:26:50 03-APR-2010 12:12
    List of Datafiles in backup set 43518
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 51275194891 03-APR-2010 07:46 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43518
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 04:26:50 03-APR-2010 12:12 YES FORCLONE
    List of Backup Pieces for backup set 43518 Copy #1
    BP Key Pc# Status Piece Name
    52481 1 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_1.bak
    52482 2 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_2.bak
    52483 3 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_3.bak
    52484 4 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_4.bak
    52485 5 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_5.bak
    52486 6 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_6.bak
    52487 7 EXPIRED /dnbusr1/dnbinas/dnbi_clone/backup/GOCPRD/bkup_for_clone_GOCPRD_20100403_44346_7.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43599 Incr 0 16.56G DISK 04:36:51 11-APR-2010 03:35
    List of Datafiles in backup set 43599
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 51583056741 10-APR-2010 22:58 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43599
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 04:36:51 11-APR-2010 03:35 YES FORCLONE
    List of Backup Pieces for backup set 43599 Copy #1
    BP Key Pc# Status Piece Name
    52841 1 EXPIRED /backup/bkup_for_clone_GOCPRD_20100410_44440_1.bak
    52842 2 EXPIRED /backup/bkup_for_clone_GOCPRD_20100410_44440_2.bak
    52843 3 EXPIRED /backup/bkup_for_clone_GOCPRD_20100410_44440_3.bak
    52844 4 EXPIRED /backup/bkup_for_clone_GOCPRD_20100411_44440_4.bak
    52845 5 EXPIRED /backup/bkup_for_clone_GOCPRD_20100411_44440_5.bak
    52846 6 EXPIRED /backup/bkup_for_clone_GOCPRD_20100411_44440_6.bak
    52847 7 EXPIRED /backup/bkup_for_clone_GOCPRD_20100411_44440_7.bak
    52848 8 EXPIRED /backup/bkup_for_clone_GOCPRD_20100411_44440_8.bak
    52849 9 EXPIRED /backup/bkup_for_clone_GOCPRD_20100411_44440_9.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43637 Incr 0 16.37G DISK 05:13:41 18-APR-2010 04:09
    Keep: LOGS Until: FOREVER
    List of Datafiles in backup set 43637
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 51953576598 17-APR-2010 22:56 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43637
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 05:13:41 18-APR-2010 04:09 YES FORCLONE_17APR
    List of Backup Pieces for backup set 43637 Copy #1
    BP Key Pc# Status Piece Name
    53112 1 EXPIRED /backup/bkup_for_clone_GOCPRD_20100417_44486_1.bak
    53113 2 EXPIRED /backup/bkup_for_clone_GOCPRD_20100417_44486_2.bak
    53114 3 EXPIRED /backup/bkup_for_clone_GOCPRD_20100417_44486_3.bak
    53115 4 EXPIRED /backup/bkup_for_clone_GOCPRD_20100418_44486_4.bak
    53116 5 EXPIRED /backup/bkup_for_clone_GOCPRD_20100418_44486_5.bak
    53117 6 EXPIRED /backup/bkup_for_clone_GOCPRD_20100418_44486_6.bak
    53118 7 EXPIRED /backup/bkup_for_clone_GOCPRD_20100418_44486_7.bak
    53119 8 EXPIRED /backup/bkup_for_clone_GOCPRD_20100418_44486_8.bak
    53120 9 EXPIRED /backup/bkup_for_clone_GOCPRD_20100418_44486_9.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43773 Incr 0 18.31G DISK 03:45:59 27-JUN-2010 16:23
    List of Datafiles in backup set 43773
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 58235899541 27-JUN-2010 12:37 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43773
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 03:45:59 27-JUN-2010 16:23 YES FOR_DUP
    List of Backup Pieces for backup set 43773 Copy #1
    BP Key Pc# Status Piece Name
    53784 1 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_1.bak
    53785 2 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_2.bak
    53786 3 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_3.bak
    53787 4 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_4.bak
    53788 5 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_5.bak
    53789 6 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_6.bak
    53790 7 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_7.bak
    53791 8 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_8.bak
    53792 9 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_9.bak
    53793 10 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100627_44623_10.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    43964 Incr 0 10.59G DISK 03:17:50 05-AUG-2010 03:05
    List of Datafiles in backup set 43964
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 60108165915 04-AUG-2010 23:47 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 43964
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 03:17:50 05-AUG-2010 03:05 YES FOR_DUP
    List of Backup Pieces for backup set 43964 Copy #1
    BP Key Pc# Status Piece Name
    54470 1 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100804_44966_1.bak
    54471 2 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100805_44966_2.bak
    54472 3 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100805_44966_3.bak
    54473 4 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100805_44966_4.bak
    54474 5 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100805_44966_5.bak
    54475 6 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100805_44966_6.bak
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    44020 Incr 0 19.75G DISK 04:13:42 09-AUG-2010 03:15
    List of Datafiles in backup set 44020
    File LV Type Ckp SCN Ckp Time Name
    1 0 Incr 60279026593 08-AUG-2010 23:01 +DBDATA/dnbib/datafile/system.455.675750017
    Backup Set Copy #1 of backup set 44020
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 04:13:42 09-AUG-2010 03:15 YES FOR_DUP
    List of Backup Pieces for backup set 44020 Copy #1
    BP Key Pc# Status Piece Name
    54990 1 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100808_45009_1.bak
    54991 2 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100808_45009_2.bak
    54992 3 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100808_45009_3.bak
    54993 4 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100808_45009_4.bak
    54994 5 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100809_45009_5.bak
    54995 6 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100809_45009_6.bak
    54996 7 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100809_45009_7.bak
    54997 8 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100809_45009_8.bak
    54998 9 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100809_45009_9.bak
    54999 10 AVAILABLE /backup/bkup_for_dup_GOCPRD_20100809_45009_10.bak
    RMAN>

  • Recovery process applies old archivelogs on standby database

    Right now my standby database is in sync with my primary database and is waiting for the archived log sequeuence# 8378 to arrive.
    But when I stop the recovery process (alter database recover managed standby database cancel;) and re-start it (alter database recover managed standby database disconnect), it starts all over again and starts applying archive logs starting from the sequence# 5739 (looks like its scanning thru the logs). To catchup with primary it takes 2+ hours as it need to skim thru all the logs starting from 5739 to 8377.
    Please let me know if you need any further information to fix this.
    Thank you
    Sunny boy
    Details:
    Database version: 11.2.0.3
    OS : RHEL 5
    On Standby Database
    SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
    FROM V$LOG_HISTORY
    GROUP BY THREAD#; 2 3
    THREAD# LAST_APPLIED_LOG
    1 8377
    Alert log
    alter database recover managed standby database disconnect
    Attempt to start background Managed Standby Recovery process (MNODWDR)
    Tue May 08 16:13:09 2012
    MRP0 started with pid=28, OS id=26150
    MRP0: Background Managed Standby Recovery process started (MNODWDR)
    started logmerger process
    Tue May 08 16:13:15 2012
    Managed Standby Recovery not using Real Time Apply
    Parallel Media Recovery started with 8 slaves
    Waiting for all non-current ORLs to be archived...
    All non-current ORLs have been archived.
    Completed: alter database recover managed standby database disconnect
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/arch/mnodw_1_5739_765032423.arc
    Tue May 08 16:13:48 2012
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5740.1466.781015749
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5741.1468.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5742.1474.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5743.1473.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5744.1477.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5745.1478.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5746.1472.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5747.1475.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5748.1469.781017203
    Media Recovery Log +MNODW_FRA_GRP/mnodwdr/archivelog/2012_04_19/thread_1_seq_5749.1470.781017203
    Tue May 08 16:13:57 2012
    Edited by: Sunny boy on May 8, 2012 5:29 PM

    Hello;
    V$LOG_HISTORY is the information from the control file. I would use a different query to check :
    From the Primary :
    SET PAGESIZE 140
    COL DB_NAME FORMAT A10
    COL HOSTNAME FORMAT A14
    COL LOG_ARCHIVED FORMAT 999999
    COL LOG_APPLIED FORMAT 999999
    COL LOG_GAP FORMAT 9999
    COL APPLIED_TIME FORMAT A14
    SELECT
       DB_NAME, HOSTNAME, LOG_ARCHIVED, LOG_APPLIED, APPLIED_TIME, LOG_ARCHIVED-LOG_APPLIED LOG_GAP
    FROM
    ( SELECT
       NAME DB_NAME
    FROM
       V$DATABASE
    SELECT
       UPPER(SUBSTR(HOST_NAME,1,(DECODE(INSTR(HOST_NAME,'.'),0,LENGTH(HOST_NAME), (INSTR(HOST_NAME,'.')-1))))) HOSTNAME
    FROM
       V$INSTANCE
    SELECT
       MAX(SEQUENCE#) LOG_ARCHIVED
    FROM
       V$ARCHIVED_LOG
    WHERE
       DEST_ID=1
    AND
       ARCHIVED='YES'
    SELECT
       MAX(SEQUENCE#) LOG_APPLIED
    FROM
       V$ARCHIVED_LOG
    WHERE
       DEST_ID=2
    AND
       APPLIED='YES'
    SELECT
       TO_CHAR(MAX(COMPLETION_TIME),'DD-MON/HH24:MI') APPLIED_TIME
    FROM
       V$ARCHIVED_LOG
    WHERE
       DEST_ID=2
    AND
       APPLIED='YES'
    );Change DEST_ID as needed for your system. I would also bump the parameter LOG_ARCHIVE_MAX_PROCESSES assuming its set to default to a higher value up to 30.
    Maybe instead of stopping the recovery process you should DEFER on the Primary
    alter system set log_archive_dest_state_2=defer;Change the _n from 2 to what your system requires. I use this and have watch DG catch up 200 archives in about 15 minutes.
    You have Standby Redo setup and are using the same size as your redo right?
    Have never seen the Standby try to apply twice.
    ORA-600 [3020] "Stuck Recovery" [ID 30866.1] ( But I do not see your issue )
    Metalink Note 241438.1 Script to Collect Data Guard Physical Standby Diagnostic Information
    Metalink Note 241374.1 Script to Collect Data Guard Primary Site Diagnostic Information
    Best Regards
    mseberg
    Edited by: mseberg on May 8, 2012 5:16 PM

  • Recovery in archivelog mode

    hi experts around the world.
    i have oracle 9i release 2 on server 2003. we make partitions on windows
    like
    C (windows os)
    D (oracle)
    E (oracle physical datafiles)
    F (oracle physical datafiles)
    G (oracle physical datafiles)
    H (ARCHIVE logs)
    we have similar configuration standby server. we down this standby database every sunday and make cold backup of all the datafiles.
    one more thing that we take controlfile from production database which is running
    with the command
    ALTER DATABASE BACKUP CONTROLFILE TO 'C:\control001.ctl'
    like this.
    now i wantt to ask that i have cold back up of all the drives and all the archive logs after that sundays backup.
    i restore this cold backup on the new server .
    tell me
    1. thing that from D drive (here oracle software installed) which files and folders (bcz too many folders) i will restore on new server. i search this thing but not satisfactore results
    2.will i apply the archives with RECOVER DATABASE command or some other command
    3.which controlfile will be restored which we took from production database or some other one.
    bcz many critical problems with controlfile during recovery.
    plz reply these 3 questions seperately in detail.
    regards
    rehan
    fsd pakistan
    Edited by: user10204771 on Apr 3, 2009 4:26 AM

    as i told we have production and standby configuration.
    datablock got corrupted on primary and similarly this archivelog went on standby and applied there. i think this is the
    problem.
    No you didnt told me exactly the problem you are facing,you asked for moving OS cold backup from one node to another,i replied exactly.Now you are tellling the problem with yours block corruption then this method for coping from one node to another node will no longer be helpful,its block corruption which requires BMR (Block media recovery).
    You can achiev the same by restoring FULL backup which you might have taken before the block corruptiuon.If you dont have FULL backup then you can recover block using RMAN by identifing corrupted block.
    You can recover that corrupted block provided you should have redo for that block.
    RMAN>blockrecover datafile <datafilenumber> block <blocknumber>;This is what the beauty of RMAN which backup and recover at block level.
    now the problem is both primary and standby db not working.
    What do you mean by not working ,in what sense you say db does not work ,yours database should be available ,you have corrupted block not system datafile.
    i want to restore this cold backup on new server with the same relevant drives I WILL in C drive it will be new OS and recover by applying archive logs.
    This will not work the problem will also be shifted.
    how to proceed further
    Check yours alert logfile for datablock which you got corrupted ans paste it here.
    Khurram

  • Direct-Path with (No)Archivelog and recovery

    Hi,
    In a datawarehouse environment, our database is in NOARCHIVELOG. When we do a Insert /*+ APPEND */ on a table withLOGGING attribute, a miniminal redo log is generated.
    We want to switch the database in ARCHIVELOG mode, and change the attribute of the table to NOLOGGING .
    My question is, does instance recovery will work ?
    I made a matrix of the effect of a crash while a direct-path Insert operation :
    Database mode                   Table mode               Instance recovery                      Media recovery
    NOARCHIVELOG                     LOGGING                        OK                                     NOT OK
    ARCHIVELOG                       LOGGING                        OK                                     OK
    ARCHIVELOG                       NOLOGGING                      OK                                     NOT OK
    Do you agree with this matrix ?
    Regards

    Yes instance recovery will work regardless of direct-path and nologgging usage.
    Here is an example with Oracle XE on Windows (database runs in ARCHIVELOG mode and FORCE_LOGGING is not set):
    c:\tmp>rman target /
    Recovery Manager: Release 11.2.0.2.0 - Production on Jeu. Janv. 12 20:05:32 2012
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    connected to target database: XE (DBID=2642463371)
    RMAN> report unrecoverable;
    using target database control file instead of recovery catalog
    Report of files that need backup due to unrecoverable operations
    File Type of Backup Required Name
    RMAN> exit
    Recovery Manager complete.
    c:\tmp>sqlplus xxx/xxx @nolog.sql
    SQL*Plus: Release 11.2.0.2.0 Production on Jeu. Janv. 12 20:05:48 2012
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
    SQL> select log_mode, force_logging from v$database;
    LOG_MODE     FOR
    ARCHIVELOG   NO
    SQL> drop table tnl purge;
    Table dropped.
    SQL> create table tnl(x int) nologging tablespace users;
    Table created.
    SQL> insert /*+ APPEND */ into tnl select object_id from all_objects;
    17971 rows created.
    SQL> commit;
    Commit complete.
    SQL> connect / as sysdba
    Connected.
    SQL> startup force
    ORACLE instance started.
    Total System Global Area 1071333376 bytes
    Fixed Size                  1388352 bytes
    Variable Size             658505920 bytes
    Database Buffers          406847488 bytes
    Redo Buffers                4591616 bytes
    Database mounted.
    Database opened.
    SQL> exit
    Disconnected from Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
    c:\tmp>rman target /
    Recovery Manager: Release 11.2.0.2.0 - Production on Jeu. Janv. 12 20:07:34 2012
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    connected to target database: XE (DBID=2642463371)
    RMAN> report unrecoverable;
    using target database control file instead of recovery catalog
    Report of files that need backup due to unrecoverable operations
    File Type of Backup Required Name
    4    full or incremental     C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF
    RMAN> exit
    Recovery Manager complete.
    c:\tmp>Edited by: P. Forstmann on 12 janv. 2012 20:08

  • MANAGED RECOVERY AT STANDBY DATABASE REQURING OLD ARCHIVELOGS ORA-00308

    Oracle 9.2.0.4
    HP-UX 11.11i
    The database in Archivelog mode, single standby database in managed recovery
    mode.
    keeping standby in sync with manual applying the ARCHIVELOG from primary to
    standby database.
    primary database was 3 REDO log members of 100 MB with 1 member each.
    what i did, 1 drop and re-create the INACTIVE REDO group for all three, and
    make them
    5 REDO logs of 200 MB with 1 member each,
    then in order to keep fresh copy of primary database onto standby database, i
    send the cold backup after 15 days (last week) with standby controlfile.
    now, with that standby controlfile and the database, i can mount the database
    but while to open the database, receives messages as , it requiring the
    ARCHIVELOGS generated log time ago.
    changes the REDO groups from 3 to 5 and size 100 to 200 MB at INACTIVE state
    ### Workarounds Used ###
    SQL> alter database mount standby database;
    Database altered.
    SQL> alter database open read only;
    alter database open read only
    ERROR at line 1:
    ORA-16004: backup database requires recovery
    ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: '/user01/oracle9i/oradata/iobasprd/system01.dbf'
    SQL> alter database recover automatic standby database;
    alter database recover automatic standby database
    ERROR at line 1:
    ORA-00279: change 1655989696 generated at 08/12/2005 12:46:25 needed for thread
    1
    ORA-00289: suggestion :
    /user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf
    ORA-00280: change 1655989696 for thread 1 is in sequence #16849
    ORA-00278: log file
    '/user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf' no longer needed
    for this recovery
    ORA-00308: cannot open archived log
    '/user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf'
    ORA-27037: unable to obtain file status
    HP-UX Error: 2: No such file or directory
    Additional information: 3
    SQL> archive log list
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination /user02/oracle9i/oradata/iobasprd/archive
    Oldest online log sequence 53052
    Next log sequence to archive 53056
    Current log sequence
    53056
    -----------------------AlertIOBASPRD.log----------------------------
    alter database mount standby database
    Mon Oct 24 12:05:05 2005
    Successful mount of redo thread 1, with mount id 3283884781.
    Mon Oct 24 12:05:05 2005
    Standby Database mounted.
    Completed: alter database mount standby database
    Mon Oct 24 12:05:12 2005
    alter database open read only
    ORA-16004 signalled during: alter database open read only...
    Mon Oct 24 12:05:23 2005
    alter database recover automatic standby database
    Mon Oct 24 12:05:23 2005
    Media Recovery Start
    Starting datafile 1 recovery in thread 1 sequence 52617
    Datafile 1: '/user01/oracle9i/oradata/iobasprd/system01.dbf'
    Starting datafile 2 recovery in thread 1 sequence 52617
    Datafile 2: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_005.dbf'
    Starting datafile 3 recovery in thread 1 sequence 52617
    Datafile 3: '/user01/oracle9i/oradata/iobasprd/drsys01.dbf'
    Starting datafile 4 recovery in thread 1 sequence 52617
    Datafile 132: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_002.dbf'
    Starting datafile 133 recovery in thread 1 sequence 52617
    Datafile 133: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_003.dbf'
    Starting datafile 134 recovery in thread 1 sequence 52617
    Datafile 134: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_004.dbf'
    Media Recovery Log
    Media Recovery Log /user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf
    Errors with log /user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf.
    ORA-279 signalled during: alter database recover automatic standby database...
    Mon Oct 24 12:06:01 2005
    Restarting dead background process QMN0
    QMN0 started with pid=9
    The snap of alertIOBASPRD.log can understand me that it requiring the
    ARCHIVELOG 52617 only
    and its lying in LOG_ARCHIVE_DET location also as
    $ pwd
    /user02/oracle9i/oradata/iobasprd/archive
    $ ls archive_5261*.dbf
    archive_52610.dbf archive_52613.dbf archive_52616.dbf archive_52619.dbf
    archive_52611.dbf archive_52614.dbf archive_52617.dbf
    archive_52612.dbf archive_52615.dbf archive_52618.dbf
    $
    now, even the files are lying , why ORACLE requing the old archive logs ?????

    You haven't given any usefuly information on your problem.
    show parameter log_archive_dest
    show parameter fal
    show parameter dg
    What errors are in your alert logs ?
    What command are you using to recover ?
    Check the contents of v$archived_log
    # run on primary to detect failures :-
    select destination, status, fail_date, valid_now
    from v$archive_dest
    where status != 'VALID' or VALID_NOW != 'YES';
    # run on standby to get exact position of rollforward :-
    select thread#, to_char(snapshot_time,'dd-mon-yyyy:hh24:mi'),
    to_char(applied_time,'dd-mon-yyyy:hh24:mi'),
    to_char(newest_time,'dd-mon-yyyy:hh24:mi') from V$STANDBY_APPLY_SNAPSHOT;
    Are you using dataguard broker ?

  • Recovery with missing archivelog

    I've got a client whose 10gR2 database has been running with the SYSAUX tablespace marked for "recovery" for 9 months. To properly bring SYSAUX online, they need an archivelog from 9 months ago and it no longer exists.
    They think they are in good shape, since they are in archivelog mode and are taking nightly RMAN backups.
    I contend that they are walking on very thin ice: while they can restore from last night's backup, media recovery is impossible and they risk losing up to 24 hours of data.
    Am I correct? Or is there some way to perform an RMAN "recover" operation that by-passes the SYSAUX tablespace, leaving it offline, but brings all the other datafiles up to date?
    I have performed a test using a sample database and my theory is confirmed. But I would like a reality check in case I am missing something.
    Thanks.

    SYSAUX offline and inaccessible for 9 months, really? As you probably already know, there are a ton of objects that exist in this tablespace and therefore, you are probably not able to use some database features.
    As far as recovery, you could use SKIP TABLESPACE to avoid recovery of this tablespace.

  • Applying archivelogs to test disaster recovery database

    Database: 10.2.0.2
    OS: RHEL
    Goal: (1) To test the ability to rebuild a database using backupset and archivelogs.
    (2) To roll forward the test DR database by applying archivelogs from the production database.
    I am using rman but not a catalog.
    I restored and recovered the production database to a new, separate server, making a second database with the same DBID. I felt proud of myself for a moment.
    The production database now has archivelogs past the time of the backup that was restored and recovered to the test DR database. In a simulated production database failure, I want to apply those archivelogs to the DR database in order to roll forward the DR database to the point of failure in the production database. Everyone except me seems to know how to do this. I feel a lot less proud now.
    Yes I have read the rman manuals, all of them, and several times - yes, I have read through the forums and read asktom and metalink. I must be unintentionally overlooking some crucial info and concepts.
    My production database has generated archivelogs passed the last sequence known to my DR database. I don't know how to tell the DR database to recover these new archivelogs.
    Another post on this form directs one to use the command: "recover database until cancel". I get a syntax error. So I tried recover until time, which runs, but does not apply the new archivelogs. Must I update the DR database controlfile with a post-last-backup copy from the production database in order to apply these archivelogs? Must a catalog be used?
    Thank you for any assistance.

    What seems to work is:
    1) to restore the database using the controlfile from the backup,
    2) to issue the command 'alter database recover until cancel using backup control file' from sqlplus,
    3) to respond to each ORA-00279 with 'alter database recover continue default' also from sqlplus and until all the archivelogs have been applied, including archivelogs with sequences subsequent to the backup, then 'alter database recover cancel'.
    4) to issue the command 'alter database open resetlogs'.
    The above steps allow the available archivelogs to roll the database forward beyond the point in time recorded at the time of the hot backup.
    Metalink Note:161742.1 was helpful determining this information, yet it seems to conflict with Tom Kyte's statement that one should avoid using the backup controlfile whenever possible: http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:894628342039#29824708782039
    Perhaps the conflict is due to the difference between a restore/recovery and a restore/recovery to a new server?
    Do the above steps seem to be the best practice for restoring/recovering a database to a new server?
    Thank you.

  • Recovery doesn't see old archivelog backups

    I am doing weekly full backups
    backup
    as compressed backupset
    channel=disk1
    full
    database
    include current controlfile
    plus archivelog
    delete all input;
    Point-in-time recovery worked fine using:
    set until scn $1 ;
    restore database;
    recover database delete archivelog;
    release channel c1;
    alter database open resetlogs;
    Untill today, when I tried recovering using backupset that is two weeks old.
    Restore database worked fine. But media recovery failed with errors like this:
    RMAN-03002: failure of recover command at 09/28/2006 21:06:58
    RMAN-06053: unable to perform media recovery because of missing log
    RMAN-06025: no backup of log thread 1 seq 10992 lowscn 200869768 found to restore
    RMAN-06025: no backup of log thread 1 seq 10991 lowscn 200868902 found to restore
    database recovery was unable to find archivelog backups.
    What was confusing is that 'list backup' would show me the missing backups as available:
    BS Key Size Device Type Elapsed Time Completion Time
    1653 497.50K DISK 00:00:01 17-SEP-06
    BP Key: 1868 Status: AVAILABLE Compressed: YES Tag: TAG2006_09_17
    Piece Name: /disk0/oradata/live/LIVE/backupset/2006_09_17/live_2006_09_17_archivelog_mohtfs3a_1_1.bck
    List of Archived Logs in backup set 1653
    Thrd Seq Low SCN Low Time Next SCN Next Time
    1 10992 200869768 17-SEP-06 200870470 17-SEP-06
    I tried all what I could think of to get rman to see those backups.
    Finally, I changed computer system time to two weeks ago - and recovery worked !
    Why is recovery ignoring old archivelog backups ? How to make recovery see those old files ? Is there a more elegant way to recover to a point in time that doesn't require me to change computer clock ? Using 'set until scn' is the standard way I do it but it seems to work only within a certain time frame.

    I don't think that's the problem. I use backupsets to create a copy of database on another machine. So, I never (knock on the wood) do recovery of the database that is being backed up.
    This is how the script looks like:
    set dbid 123123;
    startup nomount
    run
    allocate channel c1 device type disk;
    restore controlfile from autobackup maxdays = 100;
    alter database mount;
    set until scn 7878787;
    restore database;
    recover database delete archivelog; -- it fails when it gets to this phase, complaining about missing files
    release channel c1;
    alter database open resetlogs;
    }

  • Recovery requests archivelog from years before backup

    I'm performing a test recovery of an RMAN backup on another server. After restoring, the recovery phase requests an archivelog from 2008 with a sequence number of 1. I don't have such old archivelogs and don't see why I should need them since the backup is from this year.
    Any ideas on why this is happening? Oracle version is 11.2.0.1.0 on x86_64

    That would have been what I would have thought too, but looking at the source db, it is not the case. (Of course it is possible that at the time the backup was taken, the datafile was offline - but I don't think that was true either.)
    I am leaning towards thinking that it's just a peculiarity of a failed restore process. I'm nearly done restoring datafiles so I'll find out soon.
    Actually, I think this is it:
    SQL> select file#, creation_time from v$datafile;
         FILE# CREATION_
      1 03-AUG-07
      2 03-AUG-07
      3 03-AUG-07
      4 03-AUG-07
      5 10-DEC-08
      6 27-APR-09
      7 16-NOV-09
      8 01-JUN-10
      9 04-JUN-12
    Recovery originally asked for archivelogs from the creation time of datafile 5. Now that I made room and restored datafile 5 again, it now wants archivelogs from 27-APR-09... which is the creation time of datafile 6. I'm currently restoring that one and looking at v$datafile_header, I'll probably need to restore #8 as well. Here's hoping that does the trick.

  • Retention policy for archivelogs in the flash recovery area

    I am using the flash recovery area for all my backup files (archive logs, data and control files). I want to use the redundancy retention policy because it is easy to calculate the space requirement. However, I am not clear how the retention policy applies to archive logs.
    Say I set the retention policy to be "keeping 3 backups". How does it affect the archive logs? Will archive logs in the flash recovery area be deleted automatically or I need to do it manually. If they are deleted automatically just like dataset files, what is the "retention policy" for them? I do not have a tape device so all archive logs are going to be stay in disk.
    Thanks.

    I am using the flash recovery area for all my backup
    files (archive logs, data and control files). I want
    to use the redundancy retention policy because it is
    easy to calculate the space requirement. However, I
    am not clear how the retention policy applies to
    archive logs.
    RMAN> show retention policy
    2> ;
    RMAN configuration parameters are:
    CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups found
    RMAN> list backup
    2> ;
    RMAN>AS documentation says
    "Besides affecting datafile and control file backups, the retention policy affects archived logs and archived log backups.
    First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived
    log backups that are older than the oldest datafile or control file backup that must be retained."
    Now i connect to SQL and create two big table for filling the redo log file and then get it archived.Please
    consider it here that i am getting archived before any taking backup i.e backup database in order to make
    archive older then the oldest datafile.
    SQL> show parameter control_file_record_keep_time
    NAME                                 TYPE        VALUE
    control_file_record_keep_time        integer     7
    SQL> create table a1 as select * from all_objects
      2  /
    Table created.
    SQL> create table a2 as select * from all_objects
      2  /
    Table created.
    C:\>dir C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    Volume in drive C is khurram
    Volume Serial Number is F49D-FF2B
    Directory of C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    03/17/2008  03:44 PM    <DIR>          .
    03/17/2008  03:44 PM    <DIR>          ..
    03/17/2008  03:44 PM         9,750,528 O1_MF_1_15_3XWLVK6T_.ARC
                   1 File(s)      9,750,528 bytes
                   2 Dir(s)  62,714,875,904 bytes free
    Now i take backup
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups found
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    Report of obsolete backups and copies
    Type                 Key    Completion Time    Filename/Handle
    Archive Log          402    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\ARCHIVELOG\2008_03_17\O1_MF_1_15_3XWLVK6T_.ARCYou can see the obsolete archived files which is the older then the oldest file which has been obsolete.It also
    does'nt make sense to keep the archived log files which is older then the oldest file cause it will no longer
    be useful for recovery process.
    now back to pavillion
    RMAN> delete obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    using channel ORA_DISK_1
    Deleting the following obsolete backups and copies:
    Type                 Key    Completion Time    Filename/Handle
    Archive Log          402    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\ARCHIVELOG\2008_03_17\O1_MF_1_15_3XWLVK6T_.ARC
    Do you really want to delete the above objects (enter YES or NO)? yes
    deleted archive log
    archive log filename=C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELO
    G\2008_03_17\O1_MF_1_15_3XWLVK6T_.ARC recid=402 stamp=649611842
    Deleted 1 objects
    RMAN> delete backup
    2> ;
    using channel ORA_DISK_1
    RMAN> list backup
    2> ;
    C:\>dir C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    Volume in drive C is khurram
    Volume Serial Number is F49D-FF2B
    Directory of C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_
    03_17
    03/17/2008  03:59 PM    <DIR>          .
    03/17/2008  03:59 PM    <DIR>          ..
                   0 File(s)              0 bytes
                   2 Dir(s)  62,724,440,064 bytes freenow this time what i did i created the archived log files after first backup in order to not to make it older
    then the oldest datafile backup.
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups foundnow i come to at SQL and make redo log file filled by creating 2 big tables in order to get it archived
    SQL> create table a3 as select * from all_objects
      2  /
    Table created.
    SQL> create table a4 as select * from all_objects
      2  /
    Table created.
    C:\>dir C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    Volume in drive C is khurram
    Volume Serial Number is F49D-FF2B
    Directory of C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_
    03_17
    03/17/2008  04:09 PM    <DIR>          .
    03/17/2008  04:09 PM    <DIR>          ..
    03/17/2008  04:09 PM         9,751,552 O1_MF_1_16_3XWNCGRS_.ARC
                   1 File(s)      9,751,552 bytes
                   2 Dir(s)  62,563,205,120 bytes free
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting compressed full datafile backupset
    channel ORA_DISK_1: specifying datafile(s) in backupset
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups foundYou can see no archived logs get obsolete yet cause the archivelog O1_MF_1_16_3XWNCGRS_.ARC
    is not older then oldest datafile backup.
    But this archivelog file will get obsolete if its beyond the retention policy,lest see how ,just take one more
    backup ,as i have already taken two time backup and the moment i go to take third backup it will cross ours
    retetnion policy from the period of 2.
    RMAN> backup database
    2> ;
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    Report of obsolete backups and copies
    Type                 Key    Completion Time    Filename/Handle
    Backup Set           240    17-MAR-08
      Backup Piece       231    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\BACKUPSET\2008_03_17\O1_MF_NNNDF_TAG20080317T160604_3XWN4WTB_.B
    KP
    Backup Set           241    17-MAR-08
      Backup Piece       232    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\BACKUPSET\2008_03_17\O1_MF_NCSNF_TAG20080317T160604_3XWN6Z95_.B
    KP
    Archive Log          403    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\ARCHIVELOG\2008_03_17\O1_MF_1_16_3XWNCGRS_.ARCKhurram

Maybe you are looking for