Re: large database maintenance

In article <CGprHr.M4p_at_freenet.carleton.ca>, ah513_at_Freenet.carleton.ca (Doug Harris) writes:

|>In a previous article, petter_at_fdmetd.uucp (Petter Henrik Hansen) asks:
|>>
|>> 2. After "end backup" for a tablespace, the data in the redo log
|>> are applied to the tablespace. Will this cost me much CPU?
|>
|>The data in the redo log are only applied to the tablespace during crash
|>recovery. What happens during a backup is that extra timestamps are written
|>to the redo-log in order to delimit the so called "fuzzy" redo entries
|>which were written during the backup. In addition, there is an init.ora
|>parameter "LOG_BLOCKS_DURING_BACKUP". During normal operation, when a
|>change is made to a database block, only information on the changed bytes
|>is written to the log. During a backup, when
|>LOG_BLOCKS_DURING_BACKUP = TRUE (the default) the entire block is
|>written to the log. This is to protect against a situation when Oracle
|>is writting changes to a database block at the same time that block is
|>being backed up. If you can guarantee the atomicity of a database block
|>read, then you can set LOG_BLOCKS_DURING_BACKUP=FALSE, and save this
|>extra work. However, my experience is that if you run the backup during
|>a period of low activity (which I realize not everyone has),
|>the extra redo activity is not a problem.
|>

The purpose of Oracle writing entire Oracle blocks to the redo log during backup is to guarantee that those logs can be used for recovery. During an OS backup, some redolog entries will occur prior to the OS backup of the corresponding block in the database file, some will occur after. If the entire block is not written to the redo log, those prior changes will be lost.

My understanding is that the only situation in which you should consider setting LOG_BLOCKS_DURING_BACKUP=FALSE is if your Oracle blocksize is the same as your OS's disk block size. In most cases, this is not true, so changing LOG_BLOCKS_DURING_BACKUP=FALSE would result in backups that are not consistent, and not useable for recovery.