> 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