有关 alter tablespace begin backup

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