Re: Online backup: Backup online redologs?

"Charles Fisher" <charles.fisher_at_alcoa.com> wrote in message news:3AEEC5A4.9080901_at_alcoa.com...
> Howard J. Rogers wrote:
>
> >>>>> See above. It makes no sense to backup the online redo logs.
 They've
> >>>>> already all been backed up to the archives, with the exception of
 the
> >>>>> current log. If you are that concerned, then a switch log file will
> >>>>> cause
> >>>>> that to be archived, and by backing up that last archive, you've got
> >>>>> the
> >>>>> lot.
 

> >> EXCEPT that you cannot execute the output of 'ALTER DATABASE
> >> BACKUP CONTROLFILE TO TRACE' without the presence of the
> >> redolog files, one of which must be marked as active.
 

> > You shouldn't take a reply to one person's query out of context. That
 reply
> > was referring to a worry about not having the very last transactions in
 a
> > given hot backup, and had nothing to do with cloning a database.
>
> Then why was it part of your reply?

Because the *original* poster wanted to know whether he should be backing up online redo logs for the purposes of performing complete recovery. As such, that reply makes perfect sense.

>
> I also shouldn't take hot backups of the redo logs,
> but that seems to work pretty well, doesn't it?

Er, no. We may be at cross purposes here, in which case I haven't a clue what you are on about. But hot backups of redo logs are invariably useless for any purpose you care to mention. They are internally inconsistent, and there is nothing that can make them consistent.

> The emphasis here stressed the discontinuity of your reply.
>

Like I say, I haven't got a clue what you are on about.

> >> What is really the difference between a restore with a hot
> >> copy of the redo and a recovery of a crashed instance which
> >> corrupts a number of tablespaces?
> >> Wouldn't each situation
> >> introduce the same sort of corruption?
 

> > Yes, sort of. Both sorts of files will be internally inconsistent
 (corrupt,
> > if you prefer). Corruption is corruption is corruption. It's what you
 can
> > *do* about the corruption that makes the difference, and there's sod-all
 you
> > can do about corruption in redo logs.
>
> Either it is the same or it is different; you must choose.
>

I don't have to do anything. My reply is accurate. Both sorts of files will be internally inconsistent. In your terms, that means they both have been introduced to 'the same sort of corruption' (inconsistency should be distinguished from true corruption, but practically they result in the same grief). But one you can fix, and the other you can't.

> >> It would make much more sense if there were an option to the
> >> CREATE CONTROLFILE statement to create blank redologs. Oracle
> >> should struggle to make this easy; this ambiguity is not useful.
 

> > Where's the ambiguity? "You cannot take hot copies of redo logs" is
 pretty
> > unambiguous. And "mirroring (or multiplexing iof you prefer) was
 invented
> > precisely so that you would never be in a position of losing all members
 of
> > a redo log group" is likewise fairly clear-cut.
>
> In a cloning situation, *I only want to apply the redo
> that is in the archived logs.* I could care less about
> the online redo - really, absolutely, I don't want it,
> and I don't want to have to worry about it.
>

In a cloning situation, you are supposed to shut the thing down first.

> Actually, I feel mostly the same about backing up to tape.
> I just don't care about unarchived redo.
>
> But, as I said, *YOU CANNOT CREATE A NEW SET OF CONTROLFILES
> WITHOUT THE REDOLOGS*, which implies to me that cloning from
> a set of hotbackups is not supported with a controlfile
> trace. If this is so, then what is the point of hotbackups?

Er, because they permit total or incomplete data recovery without having to shut down the database first. Mirroring is the protection for online redo logs, not backing up.

> It might as well be Microsoft Notepad with a SQL interface.
> Oracle's tremendous flexibility with datafile manipulation is
> negated by the lack of proper management of this single component.
>

I rather think the problem is your expectations, not Oracle, at least in this particular regard. You are trying to conflate the issues of hot backup and cloning. They are two separate issues, and the techniques that apply in the one don't apply in the other.

> Whether I am cloning or backing up to tape, I want to hold
> in my hand all required components to COMPLETELY restore
> the database. 99% is not satisfactory.
>

Define your terms. You start out wanting to clone a database, and now you're talking about wanting to do a complete restore. You can't have it both ways (or rather, you can, provided you do two different sorts of things).

If you really want to clone a database without the iffyness of having to shut it down first, why not investigate transportable tablespaces?

> >> I don't understand why people are so evasive on this issue.
 

> > I don't understand why certain people can't simply approach this issue
 with
> > logic and clarity, instead of seeking to do the impossible by utterly
> > illogical means.
>
> Yes, at this point, it appears that cloning from hot backups
> using a controlfile trace is impossible FROM AN ORACLE
> SUPPORT PERSPECTIVE, nevermind that it is demonstrated to
> work in practice in at least certain situations (actually, in
> every situation that I've seen).
>

Well, you beat me there. I've never seen it done hot in practice, and theory suggests that it isn't possible. There are, however, hidden parameters that will allow you to open any database with inconsistent redo logs. The particular one escapes me for now, but even if I could remember it, I wouldn't vouch for the results afterwards. And the end result would most definitely NOT be a "clone" in the strict sense of the word.

> The third Oracle support technician that I spoke with slyly
> implied that this method would never cause trouble, so I've
> heard answers all over the map on this question, most of them
> wrong (as I previously demonstrated). Pardon me for my scepticisim.
>
> Honestly, I don't understand why this process isn't better
> addressed in the documentation and better understood by
> support personnel. What is the purpose of a hotbackup if you
> can't restore it?
>

I really don't understand your problem! Hot backups are taken to ensure complete database recovery in the event of media failure, or incomplete recovery in the event of user error, without the need to shutdown the entire database whilst taking the backup. The resulting backup set is internally inconsistent, but the application of redo will make it consistent. Since you cannot apply redo to redo logs, hot copied redo logs will remain internally inconsistent. That's perfectly straightforward, and easy to live with, I should have thought.

You want to clone a database? Then follow the well-documented cloning procedures (which involve a cold copy of all datafiles and redo logs).

> In any case, I don't want to argue; let's try a lateral approach.
> Assuming that I have a backup controlfile produced by
> "ALTER DATABASE BACKUP CONTROLFILE TO '/CONTROL.BAK';", what
> is the procedure to recreate a set of online redologs (including
> an active thread)?

I may be wrong, and I don't have a database to hand on which to test this out, but since the commands to create or drop redo logs are all variations on a theme of 'alter database', I would have thought that they can be issued in the mount stage -which means you can take your binary version of the control file, created as you just described, get to the mount stage, add two new redo log groups, drop all reference to the existing groups, and alter database open resetlogs. The trace file method of course relies on the (consistent) presence of the existing logs, because the controlfile has to gets its SCN from somewhere. Using the binary file, you're just performing boring old incomplete recovery because of a gap in your redo stream.

I wouldn't consider the resulting database a clone, though, because of that resetlogs. But your view might differ.

>Of course, I would rather not do it this way -
> the controlfile trace will allow me to make many changes to the
> positioning of the datafiles in one go, including the system
> tablespace. But assuming that I am willing to endure the lesser
> quality, how are the redologs recreated?
>

Alter database add logfile group 3 "blah/blah.rdo' size 1m (repeat for group 4)
Alter database drop logfile group 1 (repeat for group 2)

Regards
HJR Received on Tue May 01 2001 - 10:59:41 CDT