Re: Question on Incomplete Media Recovery

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Wed, 20 Oct 2004 05:19:06 +1000
Message-Id: <417568a5$0$20126$afc38c87@news.optusnet.com.au>

Rozz Williams wrote:

> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:<4174189d$0$10351$afc38c87_at_news.optusnet.com.au>...

>> Rozz Williams wrote:
>> 
>> 
>> You cannot *use* both simultaneously.
>> 
>> As is evident from the rest of your post, you know this. You know that a
>> choice has to be made. And the answer to your original question simply
>> depends on the choice that you, er, choose to make.

>
> Then I guess my question should be "which controlfile should I use and
> how would I restore based on the information I provided"
>

>> > The controlfile on Disk A is a surviving copy
>> > containing current information. The controlfile on B will be a
>> > restored copy from yesturday's backup.
>> 
>> Yes, I know that. And which do you think you should use? Possessing both
>> is not the point. The issue is which one does the intelligent DBA choose
>> to use, when he or she knows that using the old copy on disk B will
>> involve a resetlogs, and the one on disk A doesn't?

>
> Actually, both will require a resetlogs because if Disk B goes down, I
> will lose all my online redo logs and all my archived redologs from
> last backup to point of failure.

Whatever, Rozz. I don't particularly care about the minutiae of your scenario. I am trying to get you to realise the sheer stupidity involved in using a backup control file when you don't actually have to. So instead of me trying to get you to think for yourself, let me answer your original question: use the one on Disk A, and don't say 'using backup controlfile'.

>> You have a perfectly functioning controlfile on Disk A. Why on Earth
>> would you even *consider* deleting it?

>
> To use the "recover database until cancel using backup controlfile"
> command.

And why would you "want" to use this command if you didn't need to?

Don't answer that. It is designed to make you think, not attempt to justify the unjustifiable.

>> practical loss of all prior backups and archivelogs?

>
> I am not happy with it. If I had full control of this database, I
> wouldn't need to do incomplete restores.

Recoveries.

> However, I am only a
> consultant who is instructed to perform a Backup & Recovery document
> on a database in which I cannot do any modifications. For example, I
> would love to implement RMAN (since it's a 9.2.0.4 database) to make
> recovery from block corruption easier, but I am unable too.
>
> I have no choice in the matter, and unfortunately, the database will
> need incomplete recovery in the event of media failure. They are
> totally aware of this and are willing to live with the risk.

If Disk A fails, that will not require incomplete recovery. As I have been trying to get you to realise, multiplexing your controlfiles means that if the Disk B copy fails, the Disk A one can be copied to replace it, and that does not count as a backup controlfile. If the one on Disk A fails, the one on Disk B can be copied as its (non-backup) replacement. In neither case, therefore, is 'using backup controlfile' actually needed. Why you persist in "wanting" to use it, I don't know.

>> Let me put it another way. Unless you absolutely, positively *have* to
>> perform a resetlogs operation, one usually bends over backwards to make
>> sure you don't perform one at all.

>
> I agree, but when they pay you a lot of money and tell you to do
> something without making changes, one usually takes it up the tail
> pipe and keeps quiet.
>

>> > If it makes you feel better, Disk B is actually a bunch of drives
>> > running RAID 5.
>> 
>> It doesn't (make me feel better, that is). RAID 5 as a destination for
>> redo writing is a no-no. Datafiles, I could live with. Redo logs, not.

>
> I don't know if this old school thinking or not.

FYI, Raid 5 is a no-no on redo logs, and that is not "old school", whatever that is meant to mean. Of course, incompetent and short-sighted clients and their consultants will continue to think that technological progress will dig them out of their assorted holes, but they're wrong too.

> I used to put any
> write intensive OS files (such as some datafiles) off of RAID 5 to
> RAID 0+1 (where each mirrored set of disks had it own independent path
> to the drives, of course). However, with advancements with disk and
> hardware RAID technologies, I think this might be a thing in the past.

Think what you like. You're wrong. And visit www.baarf.com to find out why. Here's a clue: "datafiles" might be "write intensive", but users don't wait directly on writes to data files. Redo logs are a different matter, because a commit's not a commit until LGWR has written. Slow down LGWR, and you slow down your users. But that's the least of it, as other "old timers" such as Cary Millsap, will tell you if you bother to actually read what they write, and not approach them as some kind of 'let me show you how much I know' exercise.

Last post in the thread as far as I'm concerned.

HJR Received on Tue Oct 19 2004 - 14:19:06 CDT