Backup incremental level 1 for recover of copy datafile (BLOCKING?)

Hi,
I recently added a datafile copy backup to the backup strategy. This is an extra backup to supplement compressed backupsets.
The datafile copy incremental was set to run at 5 am. I noticed that a process that was set to run at the same time as the backup stalled. It normally takes a few minutes to run but it took over an hour. Enterprise Manager did not report any blocked sessions over this hour (EM is configured to do so). No notable CPU spike either during this time. this morning I have moved the datafile copy backup to
a different time so as to avoid the 5 am job and sure enough that job completed in 6 minutes.
Does backup incremental for recover block in some way?
Thanks!

The other job loads data via sql loader and PL/SQL
Actually, no blocking was detected. I could not check the waits since the job was done by the time I was aware that there was a problem. Rescheduling the backup seems to have avoided the problem. It happened twice though. I am unaware that a backup might cause this behavior. I suspect that the "for recover" might be the source of the updates being suspended. I would not expect that though since the backup copy is being recovered (not the actual datafile)

Similar Messages

  • RMAN Backup Incremental levels

    hi experts,
    This is a 10g database running in archivelog mode.
    This is the backup scheme I'm currently using:
    backup database plus archivelog; (runs once per day)
    backup incremental level 1 database; this runs every 3 hours
    All the incrementals I make are level 1.
    ** Would I be able to restore, if I have no Level 0 incremental? **
    Thanks, John

    user629010 wrote:
    Thanks for the replies.
    So I should make a level 0 backup immediately after the whole backup (backup database;) is that correct?
    No its not correct as level 0 is actually the whole backup only. This is the point which includes everything and from hereonly, you start your next batch of incremental backups. You can throw away the last backups done if you have taken a level 0 backup as it covers everything and is a complete backup.
    HTH
    Aman....

  • Difference between backup incremental level 0 Vs incremental level 1?

    I am getting confuse. I have 2 commands:
    -- Weekly full backup --
    backup incremental level 0 database plus archivelog delete all input;
    -- Daily backup --
    backup incremental level 1 cumulative database plus archvielog delete all inputs;
    What is the different if I put "level 1" in the weekly full backup and "level 0" in daily backup?
    FAN

    Its not much tricky read the doc
    http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1005.htm#sthref242What you are not getting everything is written there.
    Khurram

  • Backup incremental level 0  cumulative database

    On RMAN Level 0 backup when I say cumulative like below what the difference that command make;
    backup filesperset 1 format '<%d_%s:%t:%p:%f>.df' incremental level 0 cumulative database;Edited by: Sivaprasad S on Sep 1, 2012 12:42 AM
    Edited by: Sivaprasad S on Sep 1, 2012 12:44 AM

    In a cumulative level 1 backup, RMAN backs up all blocks used since the most recent level 0 incremental backup in either the current or parent incarnation. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups because they duplicate the work done by previous backups at the same level.

  • After "backup incremental level 0 database", where is the backup files?

    I am using the windows XP and oracle 9.2
    Is the backup file in the directory home/dbs?

    The default location is %ORALCE_HOME%\databases as mentioned before.
    BUT you should specify the location in the backup script :
    RMAN> configure channel 1 device type disk format 'C:\DIR\std_%U'';
    look in [http://www.dbsnaps.com/articles/ora_rman_script/] for proper RMAN backup script.
    Oded
    [www.dbsnaps.com]
    [www.orbiumsoftware.com]

  • Backup RMAN Incremental Level 1 without Level 0 - 10gR2

    Hi,
    I'm a bit confused after some tests.
    The Question: It's mandatory to perform backup incremental level 0 before the level 1 using Oracle 10gR2 ?
    On Oracle 11.2 it's mandatory but on Oracle 10.2.0.5 I don't know.
    Test on 11.2. If doesn't exists level 0 rman take care about it and perform automaticaly level 0 before level1
    RMAN> backup incremental level 1 database;
    Starting backup at 29-APR-11
    using channel ORA_DISK_1
    no parent backup or copy of datafile 1 found
    channel ORA_DISK_1: starting incremental level 0 datafile backup set
    channel ORA_DISK_1: specifying datafile(s) in backup set
    ...Docs said:
    Incremental backups capture only those blocks that change between backups in each datafile.
    In a typical incremental backup strategy, a level 0 incremental backup is used as a starting point. A level 0 backup captures all blocks in the datafile.
    So, on Oracle 10.2.0.5 this not happen like on 11.2:
    Perfoming backup level 1 without level 0:
    RMAN> list backup;
    RMAN> backup incremental level 1 database;
    Starting backup at 29-APR-11
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting incremental level 1 datafile backupset
    channel ORA_DISK_1: specifying datafile(s) in backupset
    input datafile fno=00001 name=+DG_ORCL/db10g/datafile/system.260.749756975
    channel ORA_DISK_1: starting piece 1 at 29-APR-11
    channel ORA_DISK_1: finished piece 1 at 29-APR-11
    piece handle=+DG_FRA/db10g/backupset/2011_04_29/nnndn1_tag20110429t190340_0.260.749761421 tag=TAG20110429T190340 comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
    channel ORA_DISK_1: starting incremental level 1 datafile backupset
    channel ORA_DISK_1: specifying datafile(s) in backupset
    including current control file in backupset
    including current SPFILE in backupset
    channel ORA_DISK_1: starting piece 1 at 29-APR-11
    channel ORA_DISK_1: finished piece 1 at 29-APR-11
    piece handle=+DG_FRA/db10g/backupset/2011_04_29/ncsnn1_tag20110429t190340_0.262.749761449 tag=TAG20110429T190340 comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:05
    Finished backup at 29-APR-11
    RMAN> backup archivelog all delete input;
    Starting backup at 29-APR-11
    current log archived
    using channel ORA_DISK_1
    Finished backup at 29-APR-11
    RMAN> shutdown abort;
    Oracle instance shut downDelete all files on ASM (except SPFILE).
    ASMCMD> cd +DG_ORCL/DB10g
    ASMCMD> ls
    PARAMETERFILE/
    spfiledb10g.oraSo, let's perfom restore of database
    oracle@butao:/home/oracle> rman target /
    Recovery Manager: Release 10.2.0.5.0 - Production on Fri Apr 29 19:06:52 2011
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    connected to target database (not started)
    RMAN> startup nomount
    Oracle instance started
    Total System Global Area     293601280 bytes
    Fixed Size                     2095872 bytes
    Variable Size                 92275968 bytes
    Database Buffers             192937984 bytes
    Redo Buffers                   6291456 bytes
    RMAN> restore controlfile from '+DG_FRA/db10g/backupset/2011_04_29/ncsnn1_tag20110429t190340_0.262.749761449';
    Starting restore at 29-APR-11
    using channel ORA_DISK_1
    channel ORA_DISK_1: restoring control file
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:05
    output filename=+DG_ORCL/db10g/controlfile/current.263.749761699
    output filename=+DG_FRA/db10g/controlfile/current.263.749761699
    Finished restore at 29-APR-11
    RMAN> startup mount
    database is already started
    database mounted
    released channel: ORA_DISK_1
    RMAN> restore database;
    Starting restore at 29-APR-11
    Starting implicit crosscheck backup at 29-APR-11
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=156 devtype=DISK
    Crosschecked 1 objects
    Finished implicit crosscheck backup at 29-APR-11
    Starting implicit crosscheck copy at 29-APR-11
    using channel ORA_DISK_1
    Finished implicit crosscheck copy at 29-APR-11
    searching for all files in the recovery area
    cataloging files...
    cataloging done
    List of Cataloged Files
    =======================
    File Name: +dg_fra/DB10G/BACKUPSET/2011_04_29/ncsnn1_TAG20110429T190340_0.262.749761449
    File Name: +dg_fra/DB10G/BACKUPSET/2011_04_29/annnf0_TAG20110429T190442_0.264.749761485
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backupset restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    restoring datafile 00001 to +DG_ORCL/db10g/datafile/system.260.749756975
    restoring datafile 00002 to +DG_ORCL/db10g/datafile/undotbs1.261.749757085
    restoring datafile 00003 to +DG_ORCL/db10g/datafile/sysaux.262.749757095
    restoring datafile 00004 to +DG_ORCL/db10g/datafile/users.264.749757107
    channel ORA_DISK_1: reading from backup piece +DG_FRA/db10g/backupset/2011_04_29/nnndn1_tag20110429t190340_0.260.749761421
    channel ORA_DISK_1: restored backup piece 1
    piece handle=+DG_FRA/db10g/backupset/2011_04_29/nnndn1_tag20110429t190340_0.260.749761421 tag=TAG20110429T190340
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:26
    Finished restore at 29-APR-11
    RMAN> recover database;
    Starting recover at 29-APR-11
    using channel ORA_DISK_1
    starting media recovery
    archive log thread 1 sequence 27 is already on disk as file +DG_FRA/db10g/onlinelog/group_3.259.749756971
    archive log thread 1 sequence 28 is already on disk as file +DG_FRA/db10g/onlinelog/group_1.257.749756963
    archive log filename=+DG_FRA/db10g/onlinelog/group_3.259.749756971 thread=1 sequence=27
    archive log filename=+DG_FRA/db10g/onlinelog/group_1.257.749756963 thread=1 sequence=28
    media recovery complete, elapsed time: 00:00:02
    Finished recover at 29-APR-11
    RMAN> alter database open resetlogs;
    database opened
    RMAN>See I don't need level 0 backup to restore level 1.
    Thanks,
    Levi Pereira

    Hi Gokhan,
    Thank you for point this.
    After spending a time studying about this I find out this:
    Your expanation apply only in Oracle 10gR1/R2.
    Because there is differences between RMAN Version 10gR1/R2 and 11gR1/R2 about Incremental Level 1 and this confuse me.
    Oracle 10gR1/R2 run only one backup incremental level 1 even if level 0 not exists .
    Oracle 11gR1/R2 run two backups incremental if level 0 not exists. i.e level 0 first and after that level 1.
    Oracle 10gR2
    If no level 0 backup is available, then the behavior depends upon the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks changed since the file was created, and stores the results as a level 1 backup. In other words, the SCN at the time the incremental backup is taken is the file creation SCN.
    http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/bkup004.htm
    Thats means wich RMAN run level 0 with name level 1. (i.e: Only one Backup) This is confuse.
    Oracle 11gR1
    If no level 0 backup is available in either the current or parent incarnation, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN behaves as it did in previous releases, by generating a level 0 backup.
    http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/rcmcncpt.htm#BRADV89500
    Oracle 11gR2
    If no level 0 backup is available in either the current or parent incarnation, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN generates a level 0 backup.
    http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmcncpt.htm#BRADV89500
    Thats means wich RMAN run (automatically) level 0 first after finish level 0 backup RMAN run level 1 backup (i.e Two Backups). This seems right.
    Regards,
    Levi Pereira

  • Block Media Recovery and RMAN Incremental Level 1 backup

    Hi
    I have read somewhere that Block Media Recovery will not work if a database is backed up using rman incremental 1. Is this true, and if so is there a work around?
    I cannot seem to find this in oralce's documentation.
    Regards
    Me

    Hi,
    1) is Full Backup = Incremental level 0 backup?
    Yes
    2) When oralce say BMR does not work with incremental, will it work in the case I put forward. becuase Im doing an incremental 0...
    But does you have the Archive logs available.. ?? If yes then it will Support.
    3) Im my case will BMR work...that is use Incr level 0 on Sunday and then use archive logs for mon, tues etc
    Yes, I believe.
    @Hemanth .. am I right.. ?? Wait for your inputs...
    - Pavan Kumar N

  • Rman incremental level 1 merge with level 0

    from my reading of the rman backup document, it seems the merger incremental level 1to level 0 for recover only apply to merge with image copy, not the backupset. Is that true? However, such backup scheme will create a huge backup image copy, almost fill up my assigned backup depository directory. Is the following script works as merging with level 0 ?
    {backup as compressed backupset incremental level 1 for recover of tag 'bk$LEVEL0' database;}
    It run without error and created a very small incr file size, but not sure it has the same meaning of "for recover of copy" as in other document.

    If that is true, why we need to create an incremental level 0 backupset as the base for recover? I have one compressed backupset level 0 at beginning, then incremental level 1 for recover. with the "recover of copy with tag", it seems to create a redundant full backup. Also Iam confused, The "recover of copy with tag" is actually an image copy of the full backupset or the image copy of the original database.
    My script as for full backup at beginning
    { backup as compressed backupset incremental level 0 cumulative device type disk tag 'Baanbk$LEVEL0' database; }
    then incremental
    { backup as compressed backupset incremental level 1 for recover of  tag 'Baanbk$LEVEL0' database; }
    Should I modify the full backupset script?

  • Restore DB from Incremental Level 0 and Level 1 Differential

    Due to aging servers, I need to move a database to a new server; therefore, I'm looking to backup source db using rman level 0 and restore it as target db on another host. While the target db is restoring from the level 0, I want to run a differential of souce db and apply it to target db once the level 0 is complete. Is this possible? I searched through rman documentation and it appears that it is not possible. I see that you can do a restore but the restore is based on the date/time of the differential, which gets the level 0. Could I run 2 restore database commands before running the recover database and alter database open resetlogs commands? The first restore database command would restore the database from the level 0 backup and the 2nd restore database command would restore from the differential backup. Any help is appreciated.
    TIA

    I have run into a Problem with my setup:
    The steps that i used to do to maintain the "standby" server are as follows:
    take a level 0 backup(backup incremental level 0 database) on sunday and recover on standby server
    take a level 1 backup(backup incremental level 1 database) on monday and recover on standby server
    take a level 2 backup(backup incremental level 2 database) on tuesday and recover on standby server
    take a level 3 backup(backup incremental level 3 database) on wednesday and recover on standby server
    take a level 4 backup(backup incremental level 4 database) on thursday and recover on standby server
    but when i was trying to take a level 5 , i realised that 5 is the limit of taking incremental backups
    does that mean i have to take level 0 ,again,on friday and carry in the above fashion
    also,
    sometimes after recovery,my system files
    Oracle Error:
    ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
    ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: 'F:\ORACLE\MPWR01\MPWR01\SYSTEM01.DBF'
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 07/22/2011 15:32:02
    RMAN-06053: unable to perform media recovery because of missing log
    RMAN-06025: no backup of log thread 1 seq 176293 lowscn 6782347405 found to rest
    ore
    RMAN-06025: no backup of log thread 1 seq 176292 lowscn 6782295731 found to rest
    ore
    RMAN-06025: no backup of log thread 1 seq 176291 lowscn 6782139901 found to rest
    ore
    RMAN-06025: no backup of log thread 1 seq 176290 lowscn 6781998071 found to rest
    ore
    RMAN-06025: no backup of log thread 1 seq 176289 lowscn 6781865569 found to rest
    ore
    RMAN-06025: no backup of log thread 1 seq 176288 lowscn 6781709167 found to rest
    ore
    the archives it asks for are expected,as they are the archives generated post incremental backup,but why does my system datafile go into recovery? i am a bit confused about that?
    it occurred after i applied level 2 on my "standby" server, when i applied level 3 over this ,then it did not occur..
    i would like a discussion on this guys!!

  • BACKUP INCREMENTAL 1 FROM SCN 2083442766 database tag 'FORSTANDBY';

    Hi all,
    While taking a incremntal backup for stadnby at primary DB, rman got failed
    RMAN> BACKUP INCREMENTAL 1 FROM SCN 2083442766 database tag 'FORSTANDBY';
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-00558: error encountered while parsing input commands
    RMAN-01005: syntax error: found "integer": expecting one of: "level"
    RMAN-01007: at line 1 column 20 file: standard inputDB-oracle 9.2.0.8

    user13389425 wrote:
    Hi all,
    While taking a incremntal backup for stadnby at primary DB, rman got failed
    RMAN> BACKUP INCREMENTAL 1 FROM SCN 2083442766 database tag 'FORSTANDBY';
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-00558: error encountered while parsing input commands
    RMAN-01005: syntax error: found "integer": expecting one of: "level"
    RMAN-01007: at line 1 column 20 file: standard inputDB-oracle 9.2.0.8First this command need write as below
    BACKUP INCREMENTAL level 1 FROM SCN 2083442766 database tag 'FORSTANDBY';But i am not sure this work or not in 9.2.0.8.

  • What is the right TAG for incremental level 1 backup?

    We have a sunday level 0 backup like this:
    run {
    backup as compressed backupset
    filesperset 1
         incremental level 0 database
         tag='LEVEL_0_BACKUP'
         include current controlfile
         plus archivelog delete input;
    SQL 'alter database backup controlfile to trace';
    And Monday to Saturday incremental level 1 backup as this:
    run {
    backup as compressed backupset
         incremental level 1 database
         tag='LEVEL_1_BACKUP'
         include current controlfile
         plus archivelog delete input;
    SQL 'alter database backup controlfile to trace';
    Those scripts existed a while ago. I wonder if level 1 tag should be same as level 0 so they can all combined together?
    Please kindly advice.

    849425 wrote:
    Thanks for all your response.
    What I think is with block change tracking enabled, is that the incremental should roll into the level 0 full backup?
    What makes you think that?  Block change tracking simply allows rman to avoid having to scan every block to see if it needs to be backed up.
    I've never heard of an incremental (level 1) "rolling into" a level 0.
    Recovery starts with restoring the files from a level 0.  Followed by restoring individual blocks from the Level 1.  Followed by applying changes from the archived redo.  Followed by (if necessary) applying changes from the online redo.
    As stated earlier, tags are just user-defined labels.  Use them however seems appropriate -- after fully understanding what they are and what they are not. User-specified tags are not even required. I'd be cautious about changing them in an already defined and running system.

  • Larger backups for cumulative incremental level 1 backups

    I am noticing some strange behaviour for backup of data files in the RMAN cumulative incremental level 1 backup for certain days. I would explain that with an elaboration- the cumulative backup sizes are around 2GB, 19GB, 19GB, 1GB for the dates of 10th Dec, 5th Dec, 3rd Dec and 28th Nov respectively.
    Can there be so much difference between the values of backup size for the RMAN cumulative incremental level 1 backup as they are fluctuating from 19GB->1GB?
    I hope, my question is clear.
    Please revert with the reply to my query.
    Regards

    975148 wrote:
    Thanks for your reply. Level 0 backup happened twice between 5th Dec and 10th Dec. I guess, a block which has changed multiple times would be backed up once with all the changes done in a backup on a particular day. The same changes should get reflected in the subsequent level 0 backup.
    Regards
    Yes, obviously any backup (of any kind, of any product) is only capable of backing up the state of things as they exist at the time of the backup.
    The recoverability of "intermediate" states (say a given block was modified 5 times between backups, the next backup only gets the 5th state of the block) is done by applying redo - archived or online, as is needed.
    So to make an example to replicate what you report
    Day 1 - backup level 0
    - block # 1 modified
    Day 2  - backup level 1 - backs up Block #1 - backup size 8k
    - block # 1 modified
    - block # 2 modified
    - block # 1 modified
    - block # 3 modified
    - block # 1 modified
    - block # 4 modified
    Day 3 - backup level 1 - backs up Blocks 1,2,3,4 - backup size 32k
    - block # 5 modified
    - block # 2 modified
    - block # 7 modified
    - block # 3 modified
    - block # 6 modified
    - block # 4 modified
    Day 4 - backup level 1 - backs up Blocks 1,2,3,4,5,6,7 - backup size 56k
    - block # 5 modified
    Day 4 - backup level 1 - backs up Blocks 1,2,3,4,5,6,7 - backup size 56k
    Day 6 - backup level 0 - all blocks - size ???
    - block # 3 modified
    Day 7 - backup level 1 - backs up block 3 - backup size 8 k

  • RMAN-05556: not all datafiles have backups that can be recovered to SCN

    Oracle 11.2.0.2 SE-One
    Oracle Linux 5.6 x86-64
    Weekly refresh of a test db from prod, using rman DUPLICATE DATABASE, failed with “RMAN-05556: not all datafiles have backups that can be recovered to SCN”
    Background Summary:
    Weekly inc 0 backup of production starts on Sunday at 0100, normally completes around 1050.  Includes backups of archivelogs
    Another backup of just archivelogs runs on Sunday at 1200, normally completes NLT 1201.
    On the test server, the refresh job starts on Sunday at 1325.  In the past this script used a set until time \"to_date('`date +%Y-%m-%d` 11:55:00','YYYY-MM-DD hh24:mi:ss')\"; -- hard-coded for ‘today at 11:55’.
    For a variety of reasons I decided to replace this semi-hard coding of the UNTIL with a value determined by querying the rman catalog, getting the completion time of the inc 0 backup.  This tested out just fine in my vbox lab, even when I deliberately drove some updates and log switches during the period the backup was running.  But the first time to go live I got the above reported error.
    Details:
    The key part of the inc 0 backup is this (run from a shell script)
    export BACKUP_LOC=/u01/backup/dbprod
    $ORACLE_HOME/bin/rman target=/ catalog rman/***@rmcat<<EOF
    configure backup optimization on;
    configure default device type to disk;
    configure retention policy to recovery window of 2 days;
    crosscheck backup;
    crosscheck archivelog all;
    delete noprompt force obsolete;
    delete noprompt force expired backup;
    delete noprompt force expired archivelog all;
    configure controlfile autobackup on;
    configure controlfile autobackup format for device type disk to '$BACKUP_LOC/%d_%F_ctl.backup';
    CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '$BACKUP_LOC/%U.rman' MAXPIECESIZE 4096 M;
    sql "alter system archive log current";
    show all;
    backup as compressed backupset archivelog all delete all input format "$BACKUP_LOC/%U.alog";
    backup as compressed backupset incremental level 0 database tag tag_dbprod;
    sql "alter system archive log current";
    backup as compressed backupset archivelog all delete all input format "$BACKUP_LOC/%U.alog";
    list recoverable backup;
    EOF
    The archivelog-only backup (runs at noon) looks like this:
    export BACKUP_LOC=/u01/backup/dbprod
    $ORACLE_HOME/bin/rman target=/ catalog rman/***@rmcat<<EOF
    configure backup optimization on;
    configure default device type to disk;
    configure retention policy to recovery window of 2 days;
    crosscheck backup;
    crosscheck archivelog all;
    delete noprompt force obsolete;
    delete noprompt force expired backup;
    delete noprompt force expired archivelog all;
    configure controlfile autobackup on;
    configure controlfile autobackup format for device type disk to '$BACKUP_LOC/%d_%F_ctl.backup';
    CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '$BACKUP_LOC/%U.rman' MAXPIECESIZE 4096 M;
    sql "alter system archive log current";
    show all;
    backup as compressed backupset archivelog all delete all input format "$BACKUP_LOC/%U.alog";
    list recoverable backup;
    EOF
    And the original refresh looked like this:
    >> a step to ftp the backups from the prod server to the test server, and some other housekeeping  <<, then
    cd /backup/dbtest
    echo "connect catalog rman/***@rmcat" >  /backup/dbtest/dbtest_refresh.rman
    echo "connect target sys/*******@dbprod" >> /backup/dbtest/dbtest_refresh.rman
    echo "connect auxiliary /"             >> /backup/dbtest/dbtest_refresh.rman
    echo "run {"                           >> /backup/dbtest/dbtest_refresh.rman
    echo "set until time \"to_date('`date +%Y-%m-%d` 11:55:00','YYYY-MM-DD hh24:mi:ss')\";"  >> /backup/dbtest/dbtest_refresh.rman
    echo "duplicate target database to DBTEST;"  >> /backup/dbtest/dbtest_refresh.rman
    echo "}" >> /backup/dbtest/dbtest_refresh.rman
    So, my mod to the refresh was
    bkup_point=`sqlplus -s rman/***@rmcat <<EOF1
    set echo off verify off feedback off head off pages 0 trimsp on
    select to_char(max(completion_time),'yyyy-mm-dd hh24:mi:ss')
    from rc_backup_set_details
    where db_name='DBPROD'
    and backup_type='D'
    and incremental_level=0
    exit
    EOF1`
    cd /backup/dbtest
    echo "connect catalog rman/***@rmcat"     > /backup/dbtest/dbtest_refresh.rman
    echo "connect target sys/*******@dbprod"    >> /backup/dbtest/dbtest_refresh.rman
    echo "connect auxiliary /"                >> /backup/dbtest/dbtest_refresh.rman
    echo "run {"                              >> /backup/dbtest/dbtest_refresh.rman
    echo "set until time \"to_date('${bkup_point}','YYYY-MM-DD hh24:mi:ss')\";"  >> /backup/dbtest/dbtest_refresh.rman
    echo "duplicate target database to DBTEST;" >> /backup/dbtest/dbtest_refresh.rman
    echo "}"                                  >> /backup/dbtest/dbtest_refresh.rman
    Now the fun begins.
    First, an echo in the refresh script confirmed the ‘bkup_point’:
    =======================================================
    We will restore to 2013-08-25 10:41:38
    =======================================================
    Internally, rman reset the ‘until’ as follows:
    executing command: SET until clause
    Starting Duplicate Db at 25-Aug-2013 15:35:44
    allocated channel: ORA_AUX_DISK_1
    channel ORA_AUX_DISK_1: SID=162 device type=DISK
    contents of Memory Script:
       set until scn  45633141350;
    Examining the result of LIST BACKUP (the last step of all of my rman scripts) the full backup shows this:
    BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
    5506664 Full 61.89M     DISK        00:00:03     25-Aug-2013 02:11:32
            BP Key: 5506678   Status: AVAILABLE  Compressed: NO  Tag: TAG20130825T021129
    Piece Name: /u01/backup/dbprod/DBPROD_c-3960114099-20130825-00_ctl.backup
      SPFILE Included: Modification time: 24-Aug-2013 22:33:08
      SPFILE db_unique_name: DBPROD
      Control File Included: Ckp SCN: 45628880455   Ckp time: 25-Aug-2013 02:11:29
    BS Key Type LV Size       Device Type Elapsed Time Completion Time    
    5507388 Incr 0 206.03G    DISK        08:30:00     25-Aug-2013 10:41:30
      List of Datafiles in backup set 5507388
      File LV Type Ckp SCN    Ckp Time             Name
      1    0 Incr 45628880495 25-Aug-2013 02:11:38 +SMALL/dbprod/datafile/system.258.713574775
      >>>>>>>>> snip lengthy list <<<<<<<<<
      74   0 Incr 45628880495 25-Aug-2013 02:11:38 +SMALL/dbprod/event_i2.dbf
      Backup Set Copy #1 of backup set 5507388
      Device Type Elapsed Time Completion Time      Compressed Tag
      DISK        08:30:00     25-Aug-2013 10:41:36 YES        TAG_DBPROD
        List of Backup Pieces for backup set 5507388 Copy #1
        BP Key  Pc# Status      Piece Name
        5507391 1   AVAILABLE   /u01/backup/dbprod/eeoi55iq_1_1.rman
        >>>>>>>>>>>>> snip lengthy list <<<<<<<<<<<
        5507442 52  AVAILABLE   /u01/backup/dbprod/eeoi55iq_52_1.rman
    Notice the slight difference in time between what is reported in the LIST BACKUP and what was reported by my query to the catalog.
    Continuing with the backup list, the second archivelog  backup in the script generated six backupsets.  The fifth set  showed:
    BS Key Size       Device Type Elapsed Time Completion Time    
    5507687 650.19M DISK        00:02:18     25-Aug-2013 10:54:53
            BP Key: 5507694   Status: AVAILABLE  Compressed: YES  Tag: TAG20130825T104156
    Piece Name: /u01/backup/dbprod/ekoi643j_1_1.alog
      List of Archived Logs in backup set 5507687
      Thrd Seq     Low SCN    Low Time             Next SCN   Next Time
      1    1338518 45632944587 25-Aug-2013 05:58:18 45632947563 25-Aug-2013 05:58:20
        >>>>>>>>>>>>> snip lengthy list <<<<<<<<<<<
      1    1338572 45633135750 25-Aug-2013 10:08:21 45633140240 25-Aug-2013 10:08:24
      1    1338573 45633140240 25-Aug-2013 10:08:24 45633141350 25-Aug-2013 10:30:06
      1    1338574 45633141350 25-Aug-2013 10:30:06 45633141705 25-Aug-2013 10:41:51
      1    1338575 45633141705 25-Aug-2013 10:41:51 45633141725 25-Aug-2013 10:41:55
    Notice the availability of the archivelogs including the referenced scn.
    Investigation of the ftp portion of the refresh script confirmed that all backup pieces were copied from the prod server.
    So what am I overlooking?  Having reverted back to the original script to get the refresh completed,

    HemantKChitale wrote:
    So, technically, you only need the database and archivelogs backed up by the database script and not the noon run of the archivelog backup.
    backup as compressed backupset archivelog all delete all input format "$BACKUP_LOC/%U.alog";
    backup as compressed backupset incremental level 0 database tag tag_dbprod;
    sql "alter system archive log current";
    backup as compressed backupset archivelog all delete all input format "$BACKUP_LOC/%U.alog";
    Yet, why does backupset 5 of the noon archivelog backup show archivelogs from 10:30 to 10:40  if they had been deleted by the database backup script which has a delete input ?  It is as if the database backup script did NOT delete the archivelogs and the noon run was the one to backup the archivelogs (again ?)
    No, that is from the morning full backup.  Note the 'Completion Time" of 25-Aug-2013 10:54:53
    However, the error message seems to point to a datafile.  Why would reverting the recovery point to 11:55 make a difference, I wonder.
    As do I.
    Also puzzling to me are the times associated with the completion of the backups.  I don't recall ever having to scrutinize a backup listing this closely so I'm sure it's just a matter of filling in some gaps in my understanding, but I noticed this.  The backup report (list backup;) shows this for the inc 0 backup:
    BS Key  Type LV Size  
    Device Type Elapsed Time Completion Time
    5507388 Incr 0  206.03G
    DISK   
    08:30:00
    25-Aug-2013 10:41:30   ------- NOTE THE COMPLETION TIME ----
      List of Datafiles in backup set 5507388
      File LV Type Ckp SCN
    Ckp Time        
    Name
      1
    0  Incr 45628880495 25-Aug-2013 02:11:38 +SMALL/dbprod/datafile/system.258.713574775
    ------ SNIP ------
      74   0  Incr 45628880495 25-Aug-2013 02:11:38 +SMALL/dbprod/event_i2.dbf
      Backup Set Copy #1 of backup set 5507388
      Device Type Elapsed Time Completion Time 
    Compressed Tag
      DISK   
    08:30:00
    25-Aug-2013 10:41:36 YES   
    TAG_DBPROD   ------- NOTE THE COMPLETION TIME ----
    List of Backup Pieces for backup set 5507388 Copy #1
    BP Key  Pc# Status 
    Piece Name
    5507391 1   AVAILABLE   /u01/backup/dbprod/eeoi55iq_1_1.rman
    ------ SNIP ------
    5507442 52  AVAILABLE   /u01/backup/dbprod/eeoi55iq_52_1.rman
    Then the autobackup of the control file immediatly following:
    BS Key  Type LV Size  
    Device Type Elapsed Time Completion Time
    5507523 Full
    61.89M
    DISK   
    00:00:03
    25-Aug-2013 10:41:47   ------- NOTE THE COMPLETION TIME ----
    BP Key: 5507587   Status: AVAILABLE  Compressed: NO  Tag: TAG20130825T104144
    Piece Name: /u01/backup/dbprod/DBPROD_c-3960114099-20130825-01_ctl.backup
      SPFILE Included: Modification time: 25-Aug-2013 05:57:15
      SPFILE db_unique_name: DBPROD   
      Control File Included: Ckp SCN: 45633141671   Ckp time: 25-Aug-2013 10:41:44
    Then the archivelog backup immediately following (remember, this created a total of 5 backupset, I'm showing number 4)
    BS Key  Size  
    Device Type Elapsed Time Completion Time
    5507687 650.19M
    DISK   
    00:02:18
    25-Aug-2013 10:54:53   ------- NOTE THE COMPLETION TIME ----
    BP Key: 5507694   Status: AVAILABLE  Compressed: YES  Tag: TAG20130825T104156
    Piece Name: /u01/backup/dbprod/ekoi643j_1_1.alog
      List of Archived Logs in backup set 5507687
      Thrd Seq
    Low SCN
    Low Time        
    Next SCN   Next Time
      1
    1338518 45632944587 25-Aug-2013 05:58:18 45632947563 25-Aug-2013 05:58:20
    ------ SNIP ------
      1
    1338572 45633135750 25-Aug-2013 10:08:21 45633140240 25-Aug-2013 10:08:24
      1
    1338573 45633140240 25-Aug-2013 10:08:24 45633141350 25-Aug-2013 10:30:06
      1
    1338574 45633141350 25-Aug-2013 10:30:06 45633141705 25-Aug-2013 10:41:51
      1
    1338575 45633141705 25-Aug-2013 10:41:51 45633141725 25-Aug-2013 10:41:55
    and the controlfile autobackup immediately following:
    BS Key  Type LV Size  
    Device Type Elapsed Time Completion Time
    5507984 Full
    61.89M
    DISK   
    00:00:03
    25-Aug-2013 10:55:07   ------- NOTE THE COMPLETION TIME ----
    BP Key: 5508043   Status: AVAILABLE  Compressed: NO  Tag: TAG20130825T105504
    Piece Name: /u01/backup/dbprod/DBPROD_c-3960114099-20130825-02_ctl.backup
      SPFILE Included: Modification time: 25-Aug-2013 05:57:15
      SPFILE db_unique_name: DBPROD
      Control File Included: Ckp SCN: 45633142131   Ckp time: 25-Aug-2013 10:55:04
    and yet, querying the rman catalog
    SQL> select to_char(max(completion_time),'yyyy-mm-dd hh24:mi:ss')
      2  from rc_backup_set_details
      3  where db_name='DBPROD'
      4  and backup_type='D'
      5  and incremental_level=0
      6  ;
    TO_CHAR(MAX(COMPLET
    2013-08-25 10:41:38
    SQL>
    which doesn't match (to the second) the completion time of either the full backup or the associated controlfile autobackp.
    Hemant K Chitale
    I hope this posts in a readable, understandable manner.  I really struggeled with the 'enhanced editor', which I normally use.  When I pasted in blocks from the rman report, it kept trying to make some sort of table structure out of it .... guess I'll have to follow that up with a question in the Community forum ....

  • RECOVER IMAGE COPY WITH INCRMENTAL BACKUP

    dear all
    i want to know what this comand do
    recover copy of datafile 4 with tag ' ';
    is this when take backup copy to datafile and i have incremental backup
    when corruption occurs i write this command
    instead of restore and recovery only this command is make the restore and applay incremental backup ???
    MANY THANKS

    there are some recovery scenarios.
    1- If you lost all datafiles
    SQL> startup mount;
    RMAN> restore database;
    RMAN> recover database;
    SQL> alter database open;
    2- if you lost a tablespace
    SQL> alter tablespace users offline;
    RMAN> restore tablespace users;
    RMAN> recover tablespace users;
    SQL> alter tablespace users online;
    if you can not offline tablespace then
    $ sqlplus “/ as sysdba”
    SQL> shutdown abort;
    SQL> startup mount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> restore tablespace users;
    RMAN> recover tablespace users;
    SQL> alter database open;
    3- if you lost a datafile
    SQL> alter database datafile '/oracle/oradata/users.dbf' offline;
    RMAN> restore datafile '/oracle/oradata/users.dbf'
    RMAN> recover datafile '/oracle/oradata/users.dbf'
    SQL> alter database datafile '/oracle/oradata/users.dbf' online;
    if you cannot offline datafile then
    $ sqlplus “/ as sysdba”
    SQL> shutdown abort;
    SQL> startup mount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> restore datafile '/oracle/oradata/users.dbf';
    RMAN> recover datafile '/oracle/oradata/users.dbf';
    SQL> alter database open;
    4- if you lost your controlfile
    $ sqlplus “/ as sysdba”
    SQL> shutdown abort;
    SQL> startup nomount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> set dbid = 3970640872;
    RMAN> restore controlfile;
    SQL> alter database mount;
    SQL> alter database open;
    you will receive an error ORA-01589 when you open database
    ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
    In this situation you must do;
    SQL> shutdown abort;
    SQL> startup mount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> recover database;
    SQL> alter database open resetlogs;
    RMAN> reset database;
    if you open database with resetlogs, SCN number will be zero. In this situation all previous backups will be invalid. You must full backup.
    5- May be a special situation. You need to incomplete recovery.
    A. Time-Based incomplete recovery;
    $ sqlplus "/ as sysdba"
    SQL> shutdown abort;
    SQL> startup mount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> restore database until time "to_date('06/05/11 12:0:00','DD/MM/YY HH24:MI:SS')";
    RMAN> recover database until time "to_date('06/05/11 12:0:00','DD/MM/YY HH24:MI:SS')";
    SQL> alter database open resetlogs;
    B. SCN-Based incomplete recovery;
    $ sqlplus "/ as sysdba"
    SQL> shutdown abort;
    SQL> startup mount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> restore database until scn 1000;
    RMAN> recover database until scn 1000;
    SQL> alter database open resetlogs;
    C. archive log sequence based incomplete recovery;
    $ sqlplus "/ as sysdba"
    SQL> shutdown abort;
    SQL> startup mount;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> restore database until sequence 9923;
    RMAN> recover database until sequence 9923;
    SQL> alter database open resetlogs;
    6- if you need some archive logs in your backup
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN> restore ARCHIVELOG FROM TIME 'SYSDATE-1' UNTIL TIME 'SYSDATE';
    Or
    RMAN> restore ARCHIVELOG FROM TIME "to_date('07/11/05 00:00:01','MM/DD/YY HH24:MI:SS')
    UNTIL TIME 'SYSDATE';
    7- if your data block is corrupted you will receive an error below.
    Hata:
    ORA-01578: ORACLE data block corrupted (file # 8, block # 13)
    ORA-01110: data file 8: '/oracle/oradata/users.dbf'
    for recover data block;
    $ rman target / catalog_user/ catalog_user_password@catalogdb
    RMAN>blockrecover datafile 8 block 13;
    For Block-Level Media Recovery - Concept & Example (Doc ID 144911.1)
    8- if you have a image copy backup and your datafile number 2 has problems then you can switch datafile number2 to image copy.
    RMAN>sql ‘alter database datafile 2 offline’;
    RMAN>switch datafile 2 to copy;
    RMAN>recover datafile 2;
    RMAN>sql ‘alter database datafile 2 online’;

  • Completeness of Prerequisites for Recovering Tables for PDBs from RMAN Backups

    Could you verify the completeness of following prerequisities on pag. 441 of the "Backup and Recovery User's Guide 12c Release 1 (12.1) E17630-14"
    Prerequisites for Recovering Tables and Table Partitions from RMAN Backups
    ■ The target database must be in read-write mode.
    ■ The target database must be in ARCHIVELOG mode.
    ■ You must have RMAN backups of the tables or table partitions as they existed at the point in time to which you want recover these objects.
    ■ To recover single table partitions, the COMPATIBLE initialization parameter for target database must be set to 11.1.0 or higher.
    According to my test Database administrator workshop: How to recover a table in a pluggable database from a backup
    those prerequisities are valid for CDBs or non-CBDs, but if you want to recover tables or table partitions in PDBs a different prerequisite is needed.
    Indeed if you have a backup of only the pluggable database including the missing table (the third prerequisite above), but you don't have any backup of the container database the command...
    recover table ... of pluggable database ... until scn ... auxiliary destination ...
    will fail with the following errors:
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 02/12/2014 12:22:18
    RMAN-03015: error occurred in stored script Memory Script
    RMAN-06026: some targets not found - aborting restore
    RMAN-06023: no backup or copy of datafile 3 found to restore
    RMAN-06023: no backup or copy of datafile 4 found to restore
    RMAN-06023: no backup or copy of datafile 1 found to restore
    So to recover table in PDBs you must have also the RMAN backups of the CDB or in the opposite way it's not sufficient to have only the backups of the pluggable database, because during the creation of the auxiliary database the SYS, SYSAUX and the UNDO tablespace are required.
    Regards,
    MarcoV

    Hi,
    Before dropping a DB we had taken an RMAN backup.I hope you were in mount mode.
    Will RMAN automatically recognize the FORMAT of the backup piece and restore ?No it won't.
    First you have to restore a controlfile in nomount mode with:
    restore controlfile from '/u04/backup/rmanbkp /02mo9fnc_1_1';
    and do alter database mount.
    Than you have to run "catalog start with '/u04/backup/rmanbkp'; " so the instance now knows where to find the pieces.
    Now you can run a restore database command.
    Than open the database with resetlogs.
    Regards,
    Tycho

Maybe you are looking for