热备份时 alter database/tablespace begin/end backup 的原因

Detection of Fractured Blocks During Open Backups
One danger in making online backups is the possibility of inconsistent data within a 
block. For example, assume that you are backing up block 100 in datafile users.dbf. 
Also, assume that the copy utility reads the entire block while DBWR is in the middle 
of updating the block. In this case, the copy utility may read the old data in the top 
half of the block and the new data in the bottom top half of the block. The result is 
called a fractured block, meaning that the data contained in this block is not 
consistent. at a given SCN.
When performing backups of an open tablespace without using RMAN, you must put 
tablespaces in backup mode to prevent the creation of fractured blocks in your 
backup. When not in backup mode, the database records only changed bytes in the 
redo stream. When a tablespace is in backup mode, each time a block is changed the 
datbase writes the before-image ofthe entire block to the redo stream before modifying 
the block. Then, the database also records the changes to the block in the redo log. 
During user-managed recovery using SQL*Plus, the database applies both the 
captured block images and the recorded block changes from the redo logs. Applying 
the block images repairs any possible fractured blocks in the backup being restored 
and recovered.
RMAN does not require that you put datafiles into backup mode. During an RMAN 
backup, a database server session reads each block of the datafile and checks whether 
each block is fractured by comparing the block header and footer. If a block is 
fractured, the session re-reads the block. If the same fracture is found, then the block is 
considered permanently corrupt. If MAXCORRUPT is exceeded, the backup stops.
----------------------------------------------------------------------------------From Rman Advanced user guaid.
http://hi.baidu.com/dba_james/blog/item/432e8f8e34c86ee8f11f36f1.html
试验

我的理解：
1 备份开始时，就是begin backup是的scn就是整个备份过程从开始scn。这个是锁定的
2 在这个scn后，数据文件发生了读写，那么这个数据文件和开始备份时肯定是不一致了的。
这个不一致的文件cp出来就是“错误的”，不一致的。
3 解决这个问题就是要把读写的操作记录到redolog中。
当恢复的时候，是对cp出来的不一致的数据文件做了恢复的（通过记录的redolog）。 也就是说在恢复的最最开始的是，很可能要做的是恢复cp出来的数据文件本身。
这个时候的redo是很重要，但是备份时候又没有备份online redo log，所以要
alter system switch logfile；触发日志归档，这个时候产生的archived_redo_log很有可能在恢复cp出来的数据块本身时有用到！

4 所以在做hotcp的时候最好是不要有大量的DML，否则redolog会比较大。
5 Anyway 最好有RMAN



正常情况下，dml发生的时候只写 数据变化 部分进redo

热备期间，在block第一次发生变化的时候写   数据变化部分 +   变化前的整个block进redo  

分离的数据块　就从日志中把完好的拷贝回来　再恢复啊　

归档日志不存在了就不能恢复，若是热备期间的归档日志不存在了　数据文件中数据根本就不一致，又怎么能启动数据库？

oracle打开数据库之前要干什么？要检查什么？热备的数据文件符合数据库打开的条件吗？
在数据库备份与恢复上有一段恢复原则:
   ORACLE要进行两次检查:
第一次是看数据文件头中的检查点计数器是否与控制文件中的检查点计数器是否一致,如果相等则进行第二次检查.若不相等则进行介质恢复.
第二次检查是对文件头中的开始SCN(检查点SCN)与对应控制文件中的结束SCN进行比较,若相等则不需恢复,若不相等进行故障恢复和事务回滚.
所以除了这些数据问家和控制文件一致外，还需要保证所有数据文件文件头的　检查点scn一致，并且　所有数据文件头的　stop   scn 一致且和检查点scn 一样大，才是没有问题　不用恢复可正常打开　

数据库正常运行的时候 stop   scn 是无穷大，正常关闭的时候跟检查点 scn一样大

异常关闭则依然是无穷大表示数据文件需要恢复



大家在做hotbackup的时候, 一般是
alter tablespace XXXX begin backup;
!cp ....
alter tablespace XXXX end backup;
我们都知道在hotbackup 的同时是允许对正在备份的文件写入的, 那么随着cp的进行, 复制下来的文件从时间的角度看是在不同的时间段有cp 读出来的, 里面的数据一定是不一致的. 那么hot backup如何保证恢复时的一致性呢? 这要从begin backup说起. 
begin backup 做了什么呢? 基本上, 当我们begin backup时, oracle 会把这个ts中的所有数据文件都标记为hot-backup-in-progress, 同时这个命令会checkpoint这个ts的所有文件. 也就是说, 所有的dirty block 都会被写回到所属的数据文件. 这时候, 文件头中的checkpoint scn 记录这时的scn. 尽管在整个backup 过程中, oracle 可能会发生多次checkpoint,  begin backup 的数据文件的checkpoint scn不会随之改变 , 而其它文件的scn会被更新,  也就是说, begin backup的文件的scn被锁定于开始备份的scn. 　虽然checkpoint 不会改变备份文件的头, checkpoint还是会把数据写入到这些文件中去, 也就是说, cp复制的文件无论如何都是不一致的. 那么怎样保证我们恢复的时候, 能够恢复到开始备份时的scn呢?  原来当备份中的文件中的某个块发生第一次修改的时候, oracle会把这个块(与开始备份时的数据一致)复制到redo log中. 当我们在恢复的时候, oracle 会把redolog 应用到这些数据文件, 相当于把这些修改过的块的数据再复制会数据文件. 从而, 把文件恢复到开始备份是的一致状态.   (类似恢复的过程？) 有个内部init parameter _LOG_BLOCKS_DURING_BACKUP控制是否将block写到redo log.这个参数默认是true. 
相关的几个视图
v$backup
v$datafile_header
v$log

来自：http://www.dev-club.com/club/bbs/essence,27479.htm

在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期间运行大量的批处理程序,日志信息会急剧增多 （使用RMAN可以减少redolog的产生）

还有就是为什么alter tablespace ... begin backup要冻结文件头的SCN?

这 个主要是以后数据文件做 恢复的起始SCN ,在BEGIN BACKUP下达后,系统要对表空间执行检查点,并将该检查点前的所有事务应用都固化到数据文件,然后冻结这个SCN,直到使用END BACKUP,使备份过程结束,再更新为新的SCN,冻结的原因是因为使用操作系统命令拷贝数据文件时,他不能保证第一个读取的块就是数据文件头,如果不 冻结,则可能从备份开始,已经多次更新了文件头,而此时文件头还没有被拷贝,这样等文件头被拷贝后,他的SCN已经远远大于了数据文件中其他数据块的 SCN,这样从文件头的SCN来定位恢复起点就不现实了

从上面可以看出,热备与RMAN的联机备份是存在本质区别的,RMAN是连接目标 数据库,产生Oracle用户进程,调用他自身的过程包,与dbwr进行交互,使用Oracle的SGA或PGA进行备份,这样他首先会保证每个块都是一 致的,不会出现热碑现象,这样就减少了REDO记录的产生,他也不需要冻结文件头SCN,因为RMAN总是能先读取数据文件头的块,做为DBA,RMAN 工具都不会使用的话是很可笑的!!!


讲解很详细的一篇文章

http://www.itpub.net/viewthread.php?tid=188490&extra=&page=1

链接：http://hi.baidu.com/dba_james/blog/item/1be8ac2ac515dafce7cd406e.html