Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: I/O activity during HOT backups

RE: I/O activity during HOT backups

From: Gaja Krishna Vaidyanatha <>
Date: Tue, 20 Jun 2000 11:52:30 -0700 (PDT)
Message-Id: <>


Yes, I have been involved in an EMC TimeFinder implementation. And you are absolutely right on, what you have outlined is exactly what occurs, i.e. put the tablespace in hot backup mode, break mirror, end hotbackup mode for tablespace, copy mirror, then resilver broken mirror with other 2 members.

The amount of time it takes to re-silver is obviously a function of the amount of change that is going on in the database. Given that backups are usually done in relatively "lean periods", the resilvering should occur very quickly. I have seen resilvering time ranging from 45 secs. - 15 minutes, based on write volume during the backup.

If at all possible, you might want to consider a backup solution that deploys triple mirroring and uses RMAN backups. That then makes the resilvering time of the mirrors a moot point - at least wrt to hot backups.

The 3rd mirror would provide the additional security for a true highly available environment, if one of the mirrors fail, and can also be used to support a "read-only reporting database" if there is a need for that. This provides segregation of "reports" from online transactions, if needed.

Obviously, if you have a "read-only database" supported by a 3rd mirror and you resilver on a nightly basis, the time to resilver may take longer. But that is not a big deal, as the mirror which was just resilvered, would be broken immediately after the resilvering, to prepare for that night's batch report run.

You are also right in your comment that the "split-block" problem goes away with RMAN. This is because RMAN reads and writes in "db_block_size" blocking-factor, and thus the split-block problem never occurs. It also performs block-level checksumming and verification to ensure that the image of the block it read, is the image that it is actually writing. If the block has changed since it read it, it will re-read it and this process occurs upto 'n' times for each block read. It is my understanding that the value of n is 16 (trying to remember from something I saw 3 years ago). At any rate, that is enough number of iterations to ensure read-and-write-integrity for the backups.

Plus, the fact that tablespaces are not put into hot backup mode while backing them up using RMAN, eliminates the extra redo generation which is now relevant only to hot backups.

Best Regards,


Received on Tue Jun 20 2000 - 13:52:30 CDT

Original text of this message