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: Mon, 19 Jun 2000 12:31:46 -0700 (PDT)
Message-Id: <>


Your question is quite possibly the most classic hot backup question that is out there and it has a tendency to burn up people's mind, about the magic that occurs behind the scene. There is much more detail to this, than what I am writing and for the details, I will refer you to Rama Velpuri's Backup & Recovery Handbook. There is nothing written better than than for Oracle Backup and Recovery. I am just providing an outline to facilitate your understanding of the topic.

The outline:

  1. alter tablespace xxx begin backup;
  2. A tablespace-level checkpoint is generated, to bring any dirty blocks associated with the datafiles belonging to this tablespace from the database buffer cache to disk.
  3. All headers of the datafiles corresponding to xxx are frozen.
  4. Physical copying of datafiles occur;
  5. alter tablespace xxx end backup;
  6. All headers of the datafiles corresponding to xxx are un-frozen/thawed (;-)), as the case may be.
  7. Current sychronization information like log sequence#, checkpoint#, etc. is written to the headers.

Between #1 and #3, all I/O activity to the datafiles (both reads and writes) continue. The writes occur "in place" inside the datafiles, like regular writes to the database. You can verify this, by executing any shell command (while the backup is in progress), that sums/counts the number of bytes in a given datafile. Please note that the only thing that is frozen in the datafile(s) is the header. Everything else is available for reads and writes.

Further, during hot backup (between #1 and #3) for a given tablespace, any first-time data modifications to a block, generates "db_block_size" worth redo, as part of the before and after images, which are written to the redo log buffer. Any subsequent modifications to a block in memory, which has already generated the "db_block_size" worth redo, generates only the "regular" amount of redo. It is also known as a change-vector and you may read about it in Rama's book.

Point to clarify here is that, the additional block-sized redo that is generated during the hot backup, is only for future recovery sessions that may utilize the current backed up version of the datafiles. It is not used in any way, shape or form to "synchronize" the datafiles, when the "end backup" command is executed. As I mentioned before, the only synchronization that occurs in the files, when the "end backup" is executed, is in the recovery information in the header.

The "block-size" redo generated is to protect a future "recovery session" from the perils of the "fractured-block syndrome. This syndrome can occur, when the command that copies the datafiles to the backup destination, uses a different "blocking factor" than the size of the database block.

The rationale for freezing the header is to prevent the effect of "the syndrome" on the header block and also, prevent any writes to the header, while the copy is in progress. Having a recovery session on hand, with "fractured header blocks" of one or more datafile(s), is not a place I would ever want to be. I think I can count you in too for that....;-).

Hope that helps,


Gaja Krishna Vaidyanatha | Brio Technology | (972)-304-1170

"Opinions and views expressed are my own and not of Brio Technology"

Received on Mon Jun 19 2000 - 14:31:46 CDT

Original text of this message