--
The views expressed are my own only, and definitely NOT those of Oracle
Corporation
"Andrey" <aakit_at_softhome.net> wrote in message
news:9djbee$ukf$1_at_josh.sovintel.ru...
> Excuse me for intervention, but why one must backup online redo files?
>
I'll take this VERY SLOWLY. One should most definitely NOT back up the
online redo files.
It's very simple: NOTHING, but nothing, in Oracle can be copied hot because
the resulting files will be an internal mess. Only if you have a
methodology for reconstructing good stuff from the mess can a hot copy be
safely taken.
Control Files: forget it. What do we have that can make a messed control
file clean? Nothing. You can't apply redo to a control file. Hence the
'backup controlfile to trace' and "backup controlfile to 'c:\blah'"
commands -Oracle will produce the copies for you. Since it understands the
internals of the file it is copying, we can be sure the copy is clean.
Data Files: they will be a pile of poo if you let the O/S copy the files...
cluster 102474 swings under the disk head, and gets copied (at SCN 1056),
cluster 576323 gets copied(at SCN 1057) and .... so on..... and eventually
the file header gets copied at SCN 2046. God knows what to make of the
mess. So Oracle invented "alter tablespace blah begin backup" so that the
SCN in the file header would get frozen at SCN 1056. Who cares what SCN
actually applies whenever the rest of the file gets copied... provided we
can supply all the redo since 1056, we'll be able to make sense of it all.
So redo makes inconsistent datafiles consistent, and recoverable (provided
we 'begin backup' before copying it).
Redo Logs: well, one (or more) of them is dead. Nothing is being written
there, so if we hot copy it, the results will be consistent. But one of
them is hot (the current log), and if we start copying that as it is being
written to... well, I'll lay odds the results will be a mess. Do we have
something to apply to the current redo log copy to make it sensible. No we
do not... you can't apply redo to the redo logs.
So... the net result is, we cannot copy the current redo log whilst it is
hot, because the resulting output will likely be a pile of nonsense, and
nothing can put it right. And forget the stuff Charles has been posting
about managing to do it: he"s merely *got away with it*, and for a very
simple reason: he makes sure his database is fairly quiescent first, so that
his current redo log is unlikely to be written to. The absolute way of
ensuring the current redo log is safe to copy is, of course, to shut the
database down completely: now it's cold, and of course the copy results will
be consistent. That's why cold backups invariably include the redo logs.
Worse. Suppose you manage to get a cleanish copy of the current redo log.
Your database then blows up, because datafile 6 is corrupted. Now you tell
Junior DBA to deal with it, because you have a major pizza to deal with.
So he restores the lot: controlfile.bkp, datafiles.bkp and redologs.bkp.
They were, after all, in your backup set ...and only having gone on the
Introduction to SQL Course in Sydney, what did he know about restores??
Guess what? The current redo log on the corrupted system WAS fine. It
could have supplied important information. It's just been over-written by a
copy taken ten hours ago. Every other log is fine (because every other log
has been archived). But not the current log. The current log is toast, and
has been replaced by very stale, hours old, toast. Net result: you've just
lost committed transactions when there was absolutely no reason for you to
have.
So no, copying hot redo logs (remember: really, there's only ever one hot
redo log, it's just that it keeps changing) is a *really bad idea*.
Charles will of course dispute this on the grounds that occidental thought
has not proven it to be so... all I can tell you is that I demo a hot copy
and a restore every backup and recovery course, and I never fail to make
mincemeat of the database as a result.
> Aren't they archived automatically by oracle's archiver?
>
All but one is (the current log). Therein lies the rub. What I think
you're saying is "why bother? they've all been archived already", and you'd
be 1000% correct, except for that current log. There is no backup of the
current log, and there can't be. It is the weakest link (So.. Charles,
Goodbye). That's why you mirror your redo log members until the cows come
home. But if you lose all your members (as it were), then your database is
toast. It can only be recovered to the end of the last inactive log.
And these are immutable facts that no amount of occidental paraphenalia and
portentious prose can eradicate. LOOK AFTER YOUR REDO LOGS!
And your original question is the reason I'm so pissed off with Charles and
his nonsense. There will now be hoardes of newbies merrily copying the
entire database, redo logs included, because one man got lucky. They
shouldn't. And if I'm wrong, Mr Lewis, Mr Bakker, Mr Souto and the rest of
the denizens of this group shall rise up and smite me (guess what: I reckon
they'll keep quiet).
Regards
HJR
>
>
Received on Sat May 12 2001 - 09:04:47 CDT
