Re: Online backup: Backup online redologs?

Howard,

I must say I greatly appreciate your consistently informative, clear, and entertaining posts. The amount of time you take to answer what would sometimes seem like a pretty *silly* question is to be commended. This goes for about 10 other guys/gals on the list also. I'm completely baffled at how you maintain your sanity but thanks!

• Ethan Post
• San Diego, CA

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3afd4307_at_news.iprimus.com.au...
>
>
> --
> 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 - 12:48:09 CDT