Hot Backups

[ Article crossposted from comp.databases.oracle ]
[ Author was Jonathan Lewis ]
[ Posted on Wed, 19 Apr 1995 09:12:54 +0000 ]

In article <D79F3K.887_at_eskimo.com> lparsons_at_eskimo.com "Lee Parsons" writes:

: In article <D78GMr.1yL_at_lanier.com>, Don Vick <dvick_at_lanier.com> wrote:
: >When a tablespace is in backup status, Oracle saves all
: >update activity in the redo logs and catches up the data files after the
: >backup is done. Redo logs cannot be archived if they contain active data,
: >so you run the risk of running out of online redo logs and stalling your
: >system (i.e., blocking udpates). (I may have some details wrong here, but
: >that is the general idea. :-)
 

: Not true. ...
 

: I read once (but cant find the reference now) that one thing that is
: different during a Hot Backup is that the entries written to the on line
: log files are larger than usual. Basically instead of writing block offset
: references of changed data V7 must write the entire changed block.

Lee is correct: there is no problem with redo logs being overwritten or archived if they contain 'active data' even when in hot backup. A simple test of this is to start two sessions (as sys or system), do an update in the first, switch the relevant tablespace to BEGIN BACKUP then 'alter system switch logfile;' N+1 times in the other (where N is the number of redo log groups) in the other. The system does not lock up. (remember to END BACKUP after the test).

This is the second time in a few weeks that this suggestion has come up: is it possible that it is a mis-interpration of what happens if you re-use redo logs so fast that a database checkpoint has not completed by the time you cycle back to the redo log that kicked it off ? In this case the database _does_ stop all update activity until the checkpoint is complete... This event is then recorded in the alert.log with text like: 'unable to advance to next log file. checkpoint not complete.'

In answer to Lee's question: the latest information I have on the use of redo logs during hot backup is that:

    when a block is changed, and the associated commit occurs which     would normally cause the redo to be written, the whole block is     written, but ONLY if this is the first time the block has been     changed (or rather its change has gone to the redo) since the block     was last loaded into the db_block_buffer. This is probably a lot more efficient than writing the whole block every time.

Personally, I prefer to do hot backups to disc through a Unix pipe and using compress on the fly. The speed of backup,hence total volume of archived redo, is largely dictated by the number of different devices I can send the output to: if I have N discs receiving compressed files, I am quite happy to put N tablespaces into backup mode simultaneously. When N <= 4 this does not seem to have too serious an affect on CPU or I/O

BTW: if you want to live dangerously, there is an undocumented init.ora parameter called '_log_blocks_during_backup', and I guess you could run the database with this set to FALSE. Personally I wouldn't try it on a live system, and I think you might need to do a checkpoint before each 'begin backup'.

-- 
Jonathan Lewis