|
|
Good question, bluekey。
ORACLE这么作一定有它的道理，它在作这个ONLINE HOT BACKUP时作了很多操作，实际
的情况比我们能想象到的要复杂得多，请参见以下关于HOT BACKUP的文章，特别要注意
“fractured block”、“before-image logging”。
大家都知道，在HOT BACKUP期间产生的REDO LOG要比正常情况下要多，但为什么多并不
是象有的朋友所说的“把变化的数据块都写入REDO LOG”。事实上不管在正常操作还
是HOT BACKUP期间，LGWR都要把数据块的变化写入REDO LOG，要不怎么恢复呢？以我目
前的理解，REDO LOG里多的这部分主要是由于“before-image logging”。
为什么要有这个“before-image logging”呢？由于备份出来的文件的每一BLOCK内部
都不能保证是一致的（在备前半块时，后半块可能已经被DBWR更新了），所以在
CHECKPOINT（由begin backup引起的）之后，任何一个BLOCK在被第一次修改之前，
ORACLE要把这个BLOCK的IMAGE写到REDO LOG里。将来在MEDIA RECOVER时，如果
在REDO LOG里发现有某DATA BLOCK的BEFORE-IMAGE，就先把这个BEFORE-IMAGE
写到数据文件里，覆盖掉由备份文件RESTORE进来的这个BLOCK的IMAGE（因为这块有
可能是“fractured block”），再在些基础上APPLY块的变化量。
OK，欢迎讨论。
TECH Internals of Recovery
4. Hot Backup
A hot backup is a copy of a datafile that is taken while the file is in
active use. Datafile writes (by DBWR) go on as usual during the
time the backup is being copied. Thus, the backup gets a "fuzzy"
copy of the datafile:
* Some blocks may be ahead in time versus other blocks of the copy.
* Some blocks of the copy may be ahead of the checkpoint SCN in the
file header of the copy.
* Some blocks may contain updates that constitute breakage of
the redo record atomicity guarantee with respect to other
blocks in this or other datafiles.
* Some block copies may be "fractured" (due to front and back
halves being copied at different times, with an intervening
update to the block on disk).
The "hotbackup-fuzzy" copy is unusable without "focusing" (via
the redo log) that occurs when the backup is restored and
undergoes media recovery. Media recovery applies redo (from all
threads) from the begin-backup checkpoint SCN (see Step 2. in
Section 4.1) through the end-point of the recovery operation (either
complete or incomplete). The result is a transaction-consistent
"focused" version of the datafile.
There are three steps to taking a hot backup:
* Execute the ALTER TABLESPACE ... BEGIN BACKUP command.
* Use an operating system copy utility to copy the constituent
datafiles of the tablespace(s).
* Execute the ALTER TABLESPACE ... END BACKUP command.
4.1 BEGIN BACKUP
The BEGIN BACKUP command takes the following actions (not
necessarily in the listed order) for each datafile of the tablespace:
1. It sets a flag in the datafile header - the hotbackup-fuzzy bit
- to indicate that the file is in hot backup. The header with
this flag set (copied by the copy utility) enables the copy to be
recognized as a hot backup. A further purpose of this flag in
the online file header is to cause the checkpoint in the file
header to be "frozen" at the begin-backup checkpoint value
that will be set in Step 4. This is the value that it must have in
the backup copy in order to ensure that, when the backup is
recovered, media recovery will start redo application at a suffi-
ciently early checkpoint SCN so as to cover all changes to the
file in all threads since the execution of BEGIN BACKUP (see
6.5). Since we cannot guarantee that the file header will be the
first block to be written out by the copy utility, it is important
that the file header checkpoint structure remain "frozen" until
END BACKUP time. This flag keeps the datafile checkpoint
structure "frozen" during hot backup, preventing it (and the
checkpoint SCN in the datafile's controlfile record) from being
updated during thread checkpoint events that advance the
database checkpoint. New in v7.2: While the file is in hot
backup, a new "backup" checkpoint structure in the datafile
header receives the updates that the "frozen" checkpoint
would have received.
2. It executes a datafile checkpoint, capturing the resultant
"begin-backup" checkpoint information, including the begin-
backup checkpoint SCN. When the file is checkpointed, all
instances are requested to write out all dirty buffers they have
for the file. If the need for instance recovery is detected at this
time, the file checkpoint operation waits until it is completed
before proceeding. Checkpointing the file at begin-backup
time ensures that only file blocks changed after begin-backup
time might have been written to disk during the course of the
file copy. This guarantee is crucial to enabling block before-
image logging to cope with the fractured block problem, as
described in Step 3.
3. [Platform-dependent option]: It starts block before-image log-
ging for the file. During block before-image logging, all
instances log a full block before-image to the redo log prior to
the first change to each block of the file (since the backup
started, or since the block was read anew into the buffer
cache). This is to forestall a recovery problem that would arise
if the backup were to contain a fractured block copy (mis-
matched halves). This could happen if (the database block size
is greater than the operating system block size, and) the front
and back halves of the block were copied to the backup at dif-
ferent times - with an intervening update to the block on
disk. In this eventuality, recovery can reconstruct the block
using the logged block before-image.
4. It sets the checkpoint in the file header equal to the begin-
backup checkpoint captured in Step 2. This file header check-
point will be "frozen" until END BACKUP is executed.
5. It clears the file's online-fuzzy bit. The online-fuzzy bit
remains clear during the course of the file copy operation, thus
ensuring a cleared online-fuzzy bit in the file copy. Note that
the online-fuzzy bit is set again by the execution of END
BACKUP.
4.2 File Copy
The file copy is done by utilities that are not part of Oracle. The
presumption is that the platform vendor will have backup facilities
that are superior to any portable facility that we could develop. It is
the responsibility of the administrator to ensure that copies are only
taken between the BEGIN BACKUP and END BACKUP
commands, or when the file is not in use.
4.3 END BACKUP
The END BACKUP command takes the following actions for each
datafile of the tablespace:
1. It restores (i.e. sets) the file's online-fuzzy bit.
2. It creates an end-backup redo record (end-backup "marker"
for the datafile. This record, interpreted only by media recov-
ery, contains the begin-backup checkpoint SCN (i.e. the SCN
matching that in the "frozen" checkpoint in the backup's
header). This record serves to mark the end of the redo gener-
ated during the backup. The end-backup "marker" is used by
media recovery to determine when all redo generated between
BEGIN BACKUP and END BACKUP has been applied to the
datafile. Upon encountering the end-backup "marker", media
recovery can (at the next media recovery checkpoint: see
6.7.1) clear the hotbackup-fuzzy bit. This is only important in
preventing an incomplete recovery that might erroneously
attempt to end before all redo generated between BEGIN
BACKUP and END BACKUP has been applied. Ending
incomplete recovery at such a point may result in an inconsis-
tent file, since the backup copy may already have contained
changes beyond this endpoint. As will be seen on 8.1, open
with resetlogs following incomplete media recovery will fail if
any online datafile has the hotbackup-fuzzy bit (or any other
fuzzy bit) set.
3. It clears the file's hotbackup-fuzzy bit.
4. It stops block before-image logging for the file.
5. It advances the file checkpoint to the current database check-
point. This compensates for any file header update(s) missed
during thread checkpoints that may have advanced the data-
base checkpoint while the file was in hot backup state, with its
checkpoint "frozen". |
|
楼主: 轩静天
IP卡
狗仔卡
发表于 2002-7-22 01:16
显身卡
发表于 2002-7-22 03:08
发表于 2002-7-22 10:25
