Re: RMAN/Alert_log questions

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.

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 - 04:28:36 CST