Re: Hot backup question

  • From: Yong Huang <yong321@xxxxxxxxx>
  • To: William.Blanchard@xxxxxxxxxxxxx
  • Date: Sat, 25 Sep 2010 12:02:09 -0700 (PDT)

> what is the impact on users during a hot backup?

When the tablespace is in hot backup mode, the first change to a data block in 
buffer cache is accompanied by writing the whole before-image block to redo. So 
in general, DMLs during the hot backup create more redo.

But we should not exagerate this increase in redo. It's only the first change 
to the block when it's in buffer cache that is whole-block-logged (controlled 
by _log_blocks_during_backup); later changes, unless this block is flushed to 
disk and brought back to cache again, generate normal redo as usual. You may be 
able to take advantage of this fact by doing mostly same-block updates during 
hot backup and using a big buffer cache.

It's a common misconception that all block changes during hot backup are logged 
by writing whole blocks. See more at

message 3 at
http://groups.google.com/group/comp.databases.oracle.server/browse_frm/thread/e3a2b32fa3c68904
and
"Proof!   November 15, 2005 - 5am Central time zone" at
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:271815712711

But the most detailed description is on p.95 of Rama Velpuri's "Oracle8 Backup 
& Recovery Handbook", Oracle Press, 1998.

Blame Oracle documentation for this misconception:
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1.htm
"When a tablespace is in backup mode, each time a block is changed the database 
writes the before-image of the entire block to the redo stream before modifying 
the block."

That "each time" is gone in 11g documentation.

> how to overcome this

The best is of course don't put tablespace in hot backup mode. Use RMAN to 
backup. If you have to use a tool other than RMAN, there's no ideal solution. 
Just reduce DML to the tablespace and backup one tablespace at a time.

To borrow this thread, I have some unproved thought on this. Has anybody 
considered the possibility of split blocks if the file system I/O chunk size 
(commonly called file system block size) is the same as db_block_size? Various 
sources always seem to use mismatch of the two sizes as an example to explain 
split blocks. I think there's still a danger unless DBWn and OS tool can write 
and read, respectively, to the same block at the same moment. But it's possible 
when the two sizes match, the probability of split blocks is reduced. This of 
course assumes the datafile is on a file system.

Yong Huang


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


Other related posts: