1) During hot backup db/tbsp is put into backup mode,
"alter database begin backup;" or "alter tablespace tbsp_name begin backup;"
2) Then we copy datafiles to disk or tape,
cp *.dbf /backup
3) Take db out of backup mode.
"alter database end backup;" or "alter tablespace tbsp_name end backup;"
4) Check the backup mode from V$BACKUP view.
"select status from v$backup;"
if status is active means there are some files still in backup mode
if status is not active means no files are in backup mode
we have a couple of questions here which we face in every interview????
Is the datafile available for dml during backup? If not, then where is the data going ?
The misconception start what is actually done during hot backup, is data file opens writeable during backup process? or
changes are stored somewhere in the SGA, the redologs, the rollback/undo segments or some combination thereof, and then written back into the datafile
when the tbsp/db is taken out of backup mode?
Well, around the writeable issue inside datafile there is other misconception like
“During hot backup process there is generated huge amount of redo data which in fact slows down the database dramatically if the database is in
archivelog mode.”
Now let’s know what actually happens during hot backup. The hot backup steps are,
1)The corresponding tablespace is checkpointed.
2)The checkpoint SCN marker in the datafile headers cease to increment with checkpoints.(means the scn is not incremented in datafile headers)
3)Full images of changed DB blocks are written to the redologs.
Whenever you issue,
ALTER TABLESPACE tbs_name BEGIN BACKUP;alter database begin backup;
command, at that point a checkpoint is performed against the target tablespace and the datafile header is frozen,
so no more updates are allowed on it (the datafile header), this is for the database to know which was the last time the tablespace had a consistent
image of the data.
But during backup process, the corresponding datafiles in the tablespace allow normal read/write operations, that is I/O activity is not frozen.
In case of redo log generation, each block will be recorded into the redo log files, the first time it the block is changed.
So if a row is modified for the first time inside date block since hot backup started the complete block image is recorded in the redo log files
but subsequent transactions on the block will only record the transaction just as normal.
Above three steps are required to guarantee consistency during the file is restored and recovery. By freezing the checkpoint SCN in the file headers,
any subsequent recovery on that backup copy of the file will know that it must commence at that SCN. Having an old SCN in the file header tells
recovery that the file is an old one, and that it should look for the redolog file containing that SCN, and apply recovery starting there.
Note that checkpoints to datafiles in hot backup mode are not suppressed during the backup, only the incrementing of the main checkpoint SCN flag.
A “hot backup checkpoint” SCN marker in the file header continues to increment as periodic or incremental checkpoints progress normally.
By initially checkpointing the datafiles that comprise the tablespace and logging full block images to redo, Oracle guarantees that any blocks
changed in the datafile while in hot backup mode will also be available in the redologs in case they are ever used for a recovery.
Now many claims that during hot backup process there is excessive redo log generation than in normal mode. It actually depends on the amount of
blocks changes during hot backup process. Because the first time a block is changed logging of full images of changed blocks in these tablespaces
are recorded to the redo logs. Normally, Oracle logs an entry in the redologs for every change in the database, but it does not log the whole image
of the database block. But during the hot backup process by logging full images of changed DB blocks to the redologs, Oracle eliminates the
possibility of the backup containing irresolvable split blocks. To understand this reasoning, you must first understand what a split block is.
Typically, Oracle database blocks are a multiple of O/S blocks. For instance, most windows filesystems have a default block size of 512 bytes and
unix filesystems have a default blocksize 2k, while Oracle’s default block size is 8k. This means that the filesystem stores data in 512 byte chunks,
while Oracle performs reads and writes in 2k chunks, or multiples thereof. While backing up a datafile, your backup script makes a copy of the datafile
from the filesystem, using O/S utilities such as copy, dd, cpio, or OCOPY. As it is making this copy, it is reading in O/S-block sized increments.
If the database writer happens to be writing a DB block into the datafile at the same time that your script is reading that block’s constituent
O/S blocks, your backup copy of the DB block could contain some O/S blocks from before the database performed the write, and some from after.
This would be a split block.
By logging the full block image of the changed block to the redologs, it guarantees that in the event of a recovery, any split blocks that might be
in the backup copy of the datafile will be resolved by overlaying them with the full legitimate image of the block from the redologs. Upon completion
of a recovery, any blocks that got copied in a split state into the backup will have been resolved through application of full block images from the
redologs.
Comments
Post a Comment