Delivering Oracle 10g R2 Administration Workshop II we had a closer look at the new recommended backup strategy for Oracle.
With Oracle 10g R2 we can recover datafile copies like we recover the real datafiles.
This gives us the oportunity to recover the entire database without having to restore it from backup first.
Which of course saves very valuable time in case of a disaster.
Here is how you could do it:
- use a “flash recovery area” to store everything needed for recovering, such as:
- an image copy of the entire database
- one incremental backup of the database
- the archived redo logs which have been created since the last incremental backup
The flash recovery area is a location on disk which you specify by the parameter db_recovery_file_dest. It can be changed dynamically without having to restart.
With the also dynamically changeable parameter db_recovery_file_dest_size you can limit the amount of disk space you want to use for this area.
Once you use it rman will create backupserts and image copies of datafiles there by default.
- create an image copy of the entire database:
RMAN > BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY DATABASE;
This will first search for a parent image copy to recover. If there is none yet, it will create one.
If there is an image copy of the database already, it will create an incremental level 1 backup.
- after you have create the first incremental backup for your image copy you can update these image copies of the datafiles by applying the incremental backup to them.
RMAN > RECOVER COPY OF DATABASE;
This is what you do every night.
Then you will have a copy of the database which is always
at least at the level of last night.
In case of a disaster you can now tell rman to just change the locations of the datafiles in the controlfile to the image copies by issuing the following:
RMAN > SWITCH DATABASE TO COPY;
You can only do this in MOUNT.
- Now you are already where you were last night and you only have to recover what has changed since last incremental update without having to restore the database at first.
This is a very handy way to perform recovery.
We were able to switch datafiles to copies before 10g already, but could not incrementally update them.
April 21, 2006 at 12:14 pm |
This is a handy tip, Lutz. Is there a way to specify a different location to recover to? In other words, what if you wanted to use the incrementally backed up files to create a clone. Is that possible?
April 21, 2006 at 12:47 pm |
Hi anonymous (why anonymous?),
the clou here is that you do not need to restore so why use a different location?
We just save a lot of time with this.
What you are thinking about is possible also:
you can use incremental backups of a production db
and use these to incrementally update a standy db or a clone db.
August 2, 2006 at 12:59 pm |
Thank you Lutz for laconic explanation, but i want to return to first comment. Can we restore all database from flashback image copy and may be in different location?
August 7, 2006 at 4:56 pm |
Hi alexandr,
pls see my email for the comprehensive explanation of this and your other questions.
You get around the restore with a switch databsae to copy and only need to recover after the switch. With this you change the information about the location of the datafiles in the controlfile. It is like a rename of all datafiles in one command.
You basically use one storage for the production and one for the flash recovery area and in case of desaster you just switch to the image copy, which should be incremantally updated every night. Then you only need to recover the changes which were made since the last incremental update of the image copy. No restore!!
=;-)
Hope this clarifies something.
Keep on switching!
Lutz
August 14, 2006 at 2:39 pm |
Hi Lutz,
I have taken the backup as suggested by you.
Now I lost my one datafile. can you please tell me how can I recover that datafile using this incremental backup.
I just want to know the steps of recovery please.
with reagrds
Anurag
August 14, 2006 at 2:41 pm |
Hi Anurag,
pls contact me by email and I will get back to you.
lutz_hartmann@yahoo.de
=;-)
June 10, 2007 at 2:32 pm |
Thank You
October 20, 2007 at 5:53 pm |
Hi
Loved the post, I am testing image rman copies comparied to a full OS backup…
First of course I shut the database down and took a full OS backup, I have been
working with RMAN for a few years but never really trusted it in full on disaster
recovery… so after I took an OS backup I erased all the files including control files
I did a
1) startup nomount pfile=/opt/app/oracle/admin/dev/pfile/init.ora.
2) alter database mount
and of course got ORA-00205: error in identifying control file
now what ….
how do I recover from the image backup without a control file?
October 20, 2007 at 6:50 pm |
Hi Jon,
you must restore a controlfile first.
RMAN> restore controlfile from autobackup;
RMAN> alter database mount;
If you have lost all mirrors of your controlfile then in real life a real desaster has happened, like your server has burnt down or stared was under water…
Normally you have the conterolfile as well as the redo log files multiplexed across multiple disks multiple controllers even across multiple SANs depending your degree of paranoia.
So if you had a desaster, restore the controlfile from somewhere, if you did not have a desaster… think about your level of security more deep and multiplex the controlfile.
=;-)
=;-)
November 9, 2007 at 10:17 pm |
Thanks for the post. much clearer than any manuals from ORACLE, especially in the fact that every nite you need to run “RECOVER COPY OF DATABASE” to make the image copy current. Even though I run “backup incremental level 1 for recover of copy database” which after the first run, will only produce a level 1 incremental based on the last Level 0 I performed.
September 1, 2008 at 1:02 pm |
Hi all,
This is a very good article, but I have a doubt on the functionnality:
isn’t it what we did in 9i by creating a physical standby on the same or other server and playing archivelog at night? We had a ‘working’ non writable database ready to be use as a main database in case of problems.
What do we gain if the server (in fact disks) is lost? Flash recovery area is usually on the same hardware.
For what you described, disk cluster do the job much easier.
But we may use this functionnality to create clone of the current database by changing the db_recovery_file_dest to the desired target directory and ease the job even if rman duplicate command does this too.
However, you opened new horizons for me, thank a lot for your job.
January 25, 2009 at 7:57 pm |
Hi!
This is a very good policy, but i have a quaestion. Is it possible, to say RECOVER COPY OF DATABASE UNTIL SCN=…..??? Can I build a consistent image of the database this way?
Thanks in advance,
Tibor.