在Oracle备份中,我们可以使用alter tablespace ... begin backup将表空间置于联机备份模式,然后用操作系统命令进行数据文件的物理拷贝,达到备份的目的,这个过程中数据文件还是照样联机,并进行正常的数据插入,但会导致比平常更多的REDO记录的产生
产生较多的REDO记录是由热备引起的,因为在热备过程中,我们采用copy/ocopy 命令,这个是属于操作系统的命令,他和Oracle是不相关的,不能和Oracle的内部进程如dbwr进行交互,这样就可能导致热碑块的出现,因为操作系统读取数据文件时,他的IO尺寸并不是block size的大小,一般会更小,这样会导致一个数据块被读取多次,而每次获取的部分都不一致(数据不断更新),为了恢复这种断裂的热碑块,Oracle进行了数据块前映象这个操作,对于backup模式的数据文件块,在第一次受到DML影响时,先将数据块整个COPY到REDO中,后续的DML在进行 UNDO,正常REDO信息的记录,当恢复数据文件时,会先应用最先的数据块前映像,然后才是后续的REDO记录信息,更多的日志记录就是这个前映像产生的,这个不能和UNDO弄混淆,他是整个数据块,而不是简单的行记录,由于Oracle本身不知道在拷贝时那些块可能出现热碑,所以只要是BACKUP期间有DML的块,就按照上面的情况处理,所以如果在backup期间运行大量的批处理程序,日志信息会集聚增多
还有就是为什么alter tablespace ... begin backup要冻结文件头的SCN?
这个主要是以后数据文件做恢复的起始SCN,在BEGIN BACKUP下达后,系统要对表空间执行检查点,并将该检查点前的所有事务应用都固化到数据文件,然后冻结这个SCN,直到使用END BACKUP,使备份过程结束,再更新为新的SCN,冻结的原因是因为使用操作系统命令拷贝数据文件时,他不能保证第一个读取的块就是数据文件头,如果不冻结,则可能从备份开始,已经多次更新了文件头,而此时文件头还没有被拷贝,这样等文件头被拷贝后,他的SCN已经远远大于了数据文件中其他数据块的 SCN,这样从文件头的SCN来定位恢
Subject: What Happens During a Hot Backup
The BEGIN BACKUP command checkpoints the datafiles and advances the datafile
header checkpoints to the begin backup checkpoint SCN. Until the END BACKUP
command is executed, checkpoints will cease to update the datafile headers.
It starts the logging of block images.
Each time the block is read into cache an image of the whole block before the
first change is logged.
The END BACKUP command creates a redo record containing the begin backup
checkpoint SCN. It stops the logging of block images and causes the datafile
checkpoints to be advanced to the database checkpoint.
Datafile updates by DBWR go on as usual during the time the backup is being
copied so the backup gets a "fuzzy" copy of the datafile: some blocks may be
ahead in time versus other blocks and some may contain updates by transactions
that are later rolled back. The "fuzzy" backup copy is unusable without the
"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 checkpoint SCN that was captured at BEGIN BACKUP time through the
end-point of the recovery operation.
Once redo application is finished, uncommited transactions are rolled back to
leave a transaction-consistent "focussed" version of the datafile.
--------------------------------------------------------------------------------
Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.
Oracle Server Enterprise Edition Technical Forum
Thread Status: Closed
From: Casey Bowden 13-Aug-01 23:01
Subject: Hot Backup Order
RDBMS Version: 8.1.5
Operating System and Version: Win NT 4. SP5
Error Number (if applicable):
Product (i.e. SQL*Loader, Import, etc.):
Product Version:
Hot Backup Order
Which is better, to put a tablespace in backup mode and copy off all datafiles then end backup on said tablespace. OR Put the tablespace in backup mode, copy off one datafile, end backup on said tablesapce and repeat for all datafiles? Please explain how the System Change Numbers are used in the header of the datafile and what is the Oracle recommendendation. And how each situation uses them differntely.
Thanks
Casey
--------------------------------------------------------------------------------
From: Vinod Menon 14-Aug-01 15:40
Subject: Re : Hot Backup Order
Basically this depends on situations. Say you have large # of datafiles under a single tablespace. In that case it is better to copy some of the datafiles, then switch modes and continue.
The reason is on taking a tablespace in backup mode the headers r updated immediately through forced check points - which gurantees that the datafiles are latest. On crash you might need lesser recovery time this case.
--------------------------------------------------------------------------------
From: Oracle, Helen Schoone 16-Aug-01 20:46
Subject: Re : Hot Backup Order
Hi. I see no reason to alter a tablespace into and out of hot backup mode for each datafile of the tablespace. Sounds like more of a possibility for errors. Also, each time you alter a tablespace into hot backup mode, a checkpoint will occur causing any modified blocks for all the files of that tablespace to be flushed to disk.
Each datafile header contains checkpoint information. The checkpoint SCN guarantees that all data associated with a change prior to that SCN have been flushed to disk. When you alter a tablespace into hot backup mode, Oracle checkpoints, then stops checkpointing the file header of all datafiles in the tablespace while it is in hot backup mode, although DBWR continues to write changed blocks to the files, as applicable. If the file later needs to be restored and recovered, Oracle knows that recovery of that file needs to begin at the checkpoint SCN recorded in the file header when the tablespace was altered into backup mode. During the time the tablespace is in hot backup mode, extra information is written to redo for all changes made to the datafiles of the tablespace which facilitates recovery of the files since they can be copied while they are being written to.
Once you alter a tablespace out of hot backup mode, Oracle records the information in the redo, updates the checkpoint information in the file headers and normal processing resumes.
I hope this helps.
Regards,
Helen
Oracle Support Services