Re: Hot Backup and Recovery - When to switch log files.

Paul Drake wrote:

> Howard,
>
> way off topic and not central to this thread, but ... in newer
> versions where oracle can add a datafile to a tablespace in the
> db_file_create_dest at will, do you want to count on a backup
> controlfile from 400 days ago?

Er, of course not. Firstly, OMF is the invention of the devil, and I wouldn't use it in the first place. Second, I backup all my control files, to trace, every night which obviates the need to use the 'using backup controlfile' clause in the first place.

But that wasn't the point. The point was, you can do so, and it's the 'using backup controlfile' clause that lets you do it.

Of course any physical alteration of the database renders all prior binary cntrol file backups dubious. Not just adding files, but moving them, renaming them, making them read-only, offline or what have you.

> I'd be looking for the most recent one
> that is created due to running rman (autobackup controlfile), or the
> one created as part of a scripted (data dictionary driven) hot backup
> set.
>
>

>>That's why the phrase 'using backup controlfile' is there in the 
>>command, of course. Translated, it says "please pay no attention to me 
>>at all, except for the fact that SMON can use my pointers to head 
>>directly off to the data files and check their SCNs to work out what to do".

No. The use of a binary control file backup means that it is irrelevant when the control file was created, excepting that it must be from the same incarnation. SCNs are worked out by SMON checking the headers of the data files (which is why having a control file backup which correctly points to the location of all the data files and redo logs is so important).

> anyways, sorry to waste your time away from significant things, such
> as your clustering factor paper for something as mundane as this
> topic.

I can't tell whether there's irony there or not. Backup and recovery is *infinitely* more important than clustering factors (as the clustering factor paper points out!). Which is why 'shrug the should' can't do any harm backup stuff is worrying to me.

> myths are worth busting, even if egos are bruised in the process.
> I would expect nothing less from you, I think that you've only blasted
> me once before.

That wasn't a blast at *you*. That was a blast at the guy who says 'rebuild all indexes because I've got nothing better to do and it doesn't do any harm' as well as the guy who says 'I'd throw in a log switch there because even if it's not needed, it can't do any harm'.

It was, in short, a blast at anyone who seems to casually accept not knowing, but manifests a touching faith in it all being OK in the end anyway.

Of course, none of us can ever know everything (or even anything very much) about every aspect of Oracle. Which is why, for example, you won't find me holding forth on the proper design on a PL/SQL function. Or much else. But backup and recovery, and indexes, are things I actually care about quite a bit, and which can be tested and assessed.

Regards
HJR Received on Fri May 14 2004 - 01:37:45 CDT