Re: RMAN impact

Hmm... Interesting thought. Blocks sitting "unread" for long periods of time. Of course, that raises the old philosophical question: if a block on disk becomes corrupt and there is nobody there to read it, will anybody hear the operations manager's scream?

Personally, I have always held that even with good incrementals, you need to perform full (level-0) backups relatively frequently. Except for the very largest databases, I would think weekly would be the "minimum" frequency -- for something huge (e.g., in the terabyte+ range) I suppose I could maybe live with monthly. (IBM added a radical new feature to TSM -- full backups -- just for people like me, I think.) One of my reasons for this is to (help) prevent the backup infrastructure from becoming "oversubscribed".

One of the other nice features of Oracle 10g(R2?) is the ability to recover individual blocks in the even of corruption. I've never had occasion to use it myself [because only Mr. Engel's disks ever fail ;-) ] but it looks good on paper...

Should you start exporting again? Nah. You can do an RMAN "BACKUP VALIDATE DATABASE" instead. In fact, with 10g, there is an additional option "CHECK LOGICAL" that will cause RMAN to crosscheck indexes and tables, which can detect logical corruption (of the type that occurs when your disk array loses the contents of its "nonvolatile" write cache) which is otherwise undetectable by any other means.

On 10/22/06, Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl> wrote:
>
> My main concern with CBT is that a block can sit on disk 'unread' for a
> long time, depending how often full/level 0 backups are made. And disks
> don't fail, except when they're mine.
>
> In the good ol' days we were exporting databases to get blocks checked.
> With RMAN, the export became obsolete, because RMAN
> would read every block. Now RMAN stops reading every block, should we
> start exporting again?
>
> ...
>

-- 
Cheers,
-- Mark Brinsmead
   Staff DBA,
   The Pythian Group
   http://www.pythian.com/blogs

--
http://www.freelists.org/webpage/oracle-l