I want know
When will we use 'backup controlfile ' in recovery.
eg) recover database using backup controlfile ;
Thanks in advance.
Printable View
I want know
When will we use 'backup controlfile ' in recovery.
eg) recover database using backup controlfile ;
Thanks in advance.
when you have lost controlfiles?!
To make point in time recovery.
Quote:
Originally posted by kgb
To make point in time recovery.
you can always performa point in time, there is no need to use a backup controlfile for that!
One instance I know of - if you do an incomplete (point-in-time) recovery... then need to restore back again, before the first point in time. With the first point in time recovery, you have to do an open resetlogs. So when you try to go back, you need to use the backup control file (the one you backed up with the db). Sounds crazy, but I had to do it TWICE this week!
Although, now that I look at the original post, I didn't use the command "..using backup controlfile". I just restored all the files, including the previous controlfile.
HTH
Jodie
you know what I do in these cases.... I copied the current control files and redo logs before I start recover, if something goes wrong I can start over and losing ZERO transactions
With your method you would lose at least one redo log transactions
Of course I'm losing transactions.. I'm restoring to a previous Point in time. But nothing "went wrong" in my case. My developers just forgot exactly what time they started their bad load! (I felt like quoting Mr. Hanky since it was at 2 in the morning! )Quote:
Originally posted by pando
you know what I do in these cases.... I copied the current control files and redo logs before I start recover, if something goes wrong I can start over and losing ZERO transactions
With your method you would lose at least one redo log transactions
BTW - I was using RMAN to do the restores:
Code:run {
set until time to_date(‘03-27-2004 18:00:00’,’MM-DD-YYYY HH24:MI:SS’)”
execute script allocate_tsm_aimprod;
startup nomount;
restore controlfile;
alter database mount; # mount database after restoring control file
restore database;
recover database;
}
As I can usually afford the time, I'd make a complete cold backup before starting restore/recovery (OK, not feasible if you've 100's of Gb). This will give me 15-20 minutes to calm down, dig out the doc and recovery plan (or write one!) and e-mail the world about what's happening.
This has the advantages that pando talks of, allows you to start again if it restore/recovery goes horribly wrong, and potentially allows the "corrupted" situation to be set up on another machine if you need to investigate it later.
I agree, a cold backup would be good. (It'd also be nice to have another machine to restore to!) But I'm in a DW-type situation. No changes exept the jobs the developer ran (which screwed up the data)Quote:
Originally posted by DaPi
As I can usually afford the time, I'd make a complete cold backup before starting restore/recovery (OK, not feasible if you've 100's of Gb). This will give me 15-20 minutes to calm down, dig out the doc and recovery plan (or write one!) and e-mail the world about what's happening.
This has the advantages that pando talks of, allows you to start again if it restore/recovery goes horribly wrong, and potentially allows the "corrupted" situation to be set up on another machine if you need to investigate it later.
Like I said, my restore didn't go wrong.. my developers just didn't know what the problem was or when it occurred. My system acts like a dw - readonly, loaded with data once a week. They ran 2 processes to load/update the data, and it didn't roll up right. We restored back between process 1 and process 2, but still bad data. So we went back to before process 1. No problem there, until my developer told me "oops... I started it Friday night, not Saturday morning." So I had to go back again.