Thanks for the info.
-CC
Howard J. Rogers wrote:
> "Chucky" <chuck.carson_at_syrrx.com> wrote in message
> news:3DFF7D04.6070408_at_syrrx.com...
>
>>I recent book was reading did an extra step Ihave never done before when
>>performing hot backups. It temporarily disabled archive logging while it
>>copied the archivelog files to the backup destination. Won't this lose
>>transactions that occur during that window?
>>
>
>
>
> No, but it risks hanging the database. New transactions still generate their
> redo in the Log Buffer, and LGWR still transfers those successfully down to
> the online redo logs. By disabling archiving, you simply stop ARCH from
> copying the online logs to archives.
>
> The reasoning, I suppose, is that without doing this, were you to blindly
> just copy everything in your archive log destination to backup, there is a
> risk that you would be copying an archive log that ARCH is still writing to.
> A hot copy of an archive is going to be a mess, and you'll effectively have
> backed up a pile of poo in the middle of your redo stream.
>
> By switching ARCH off, you guarantee that nothing is hot, and the backup is
> therefore not at risk.
>
> It is, of course, a completely idiotic thing to do, for two main reasons.
>
> Firstly, the risk of the database hanging (albeit temporarily). Although
> you've switched off ARCH, your database remains in archivelog mode. That
> mode means 'don't over-write an online log unless it has been copied'.
> You've just switched off the one thing that does the copying. Therefore, if
> LGWR switches through all available online logs, it will loop back to the
> first one waiting to be copied by ARCH, and be unable to proceed. Result:
> nobody can start new transactions.
>
> Secondly, it is completely unnecessary. People do this, I suppose, in the
> mistaken belief that their backup will be as 'complete and up-to-date' as
> it's possible to get, and that this must be a good thing because it
> minimises the chance of data loss. What they always seem to fail to grasp is
> that backup is an on-going process, not a one-off event, and that what they
> fail to back up today will be backed up tomorrow. That it is therefore
> perfectly OK to 'miss out' the last archive log from today's backup, because
> you'll catch it again next time. That no Oracle database ever need lose a
> single committed transaction, however you backup, provided you maintain a
> continuous and uninterrupted stream of redo. And that there is therefore
> nothing to be gained by making a particular backup 'as complete as
> possible'.
>
> So, yes it is possible to do it. No, there's no need to do it. And yes, it's
> a toitally moronic procedure to include in one's regular backup procedures.
>
> Regards
> HJR
>
>
>
>
>>Thx,
>>CC
>>
>>
>>
>>-----------== Posted via Newsfeed.Com - Uncensored Usenet News
>
> ==----------
>
>> http://www.newsfeed.com The #1 Newsgroup Service in the World!
>>-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers
>
> =-----
>
>
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Received on Tue Dec 17 2002 - 14:33:16 CST
