Re: RMAN/Alert_log questions

From: jw <jw_at_hotmail.com>
Date: Fri, 24 Dec 2004 14:37:40 GMT
Message-ID: <Xns95C94E2FF2407jwhotmailcom@198.80.55.250>

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in news:41cbef56$0$6541$afc38c87_at_news.optusnet.com.au:

> jw wrote:

>> Thanks for the response.
>> 
>> Here are my observations:
>> 
>> 1. I have two Arch processes.  but I only see that "unable ..."
>> message when I started "BACKUP DATABASE PLUS ARCHIVE LOG" from RMAN. 
>> The RMAN first did a Log Switch and backup the Archive Log files.  It
>> seems this is the time it quoted the message.  For other time of the
>> day, I didn't see the message.
>> 
>> 2. For the Fractured Block, I saw it several times in a week (I did a
>> daily rmAN backup at 3:00).  And it happened at the same dba; and
>> quoted "found valid data" after reread.  As the data file is for
>> index tablespace, I am not sure I need to do anything as a proactive
>> action. 

>
>
>
> Regarding your Point 2: this is not only normal RMAN behaviour, it's
> RMAN's strong point! Blocks will likely always be fractured when
> copied hot by an operating system. Being hot means they're in use.
> Oracle will therefore be modifying bits of them whilst the O/S is
> copying other bits of them. Result: complete mess. That is why
> user-managed backups have to start with the command 'alter tablespace
> X begin backup'. One of the first things this command does is to cause
> the first SQL that modifies an Oracle block to write the *entire*
> Oracle block into the redo stream in its unmodified state. That way,
> however, fractured the block in the datafile copy gets, there is a
> clean image of it in the redo logs. Trouble is, trivial DML now
> generates block-sized redo.

Thanks guys.
JW

>
> RMAN's great claim to fame is that it doesn't cause SQL commands to
> generate vast quantities of redo. And the reason it doesn't do so is
> that it is an Oracle utility, and therefore can spot a fractured block
> when it sees one -at which point, it will simply keep re-reading it
> until it gets a clean image of the block (once it's quieted down a
> bit).
>
> In short, fractured blocks are completely expected when doing hot
> backups. So, too, is RMAN's response to them: keep re-reading them
> until a non-fractured image can be captured. It's what makes RMAN
> RMAN.
>
> Oh -and your point one is pure coincidence.
>
> Regards.
> HJR
>
Received on Fri Dec 24 2004 - 08:37:40 CST