alter tablespace tablespacename begin backup

我们在对数据库进行热备份的时候，需要将表空间置于脱机或backup命令后，对其数据文件进行拷贝。但是为什么需要在热备份之前需要alter tablespace … begin backup呢？这里牵扯到一个SCN的概念。

首先我们强制进行检查点进程

SQL> alter system checkpoint;
System altered

在这里先明确一个概念

v$database → checkpoint_change# ,表示系统检查点SCN，存放在控制文件里

v$datafile →checkpoint_change#，表示数据文件检查点SCN，存放在控制文件里

→last_change#，终止SCN，存放在控制文件里

v$datafile_header → checkpoint_change#，启动SCN，start SCN，存放在数据文件头里

当检查点SCN，datafile SCN和start SCN都一致时，数据库不需要进行介质恢复。至于终止SCN，数据库在打开的状况下值为NULL，当我们正常关闭数据库时才会有数值。如果数据库是abort关闭的，那么此时终止SCN为空，于是数据库重新开启会根据这个终止SCN为空而判断出需要进行介质恢复。

此时，我们通过SQL语句select b.NAME,a.checkpoint_change# database_scn,b.checkpoint_change# datafile_scn,c.CHECKPOINT_CHANGE# start_scn,b.last_change# shut_scn from v$database a, v$datafile b, v$datafile_header c where b.FILE# = c.FILE#;查看当前的4类SCN

可以看到当前系统SCN为830445

现在我们将要备份的其中一个表空间置于begin backup模式：

SQL> alter tablespace test begin backup;

Tablespace altered

再查看下SCN：

此时test表空间下的test1和test2数据文件的datafile SCN和start SCN变成了830645

我们再做一次checkpoint （alter system checkpoint）

这时候我们发现begin backup的tablespace下的数据文件SCN并没有变化
这样带来的好处是，我们拷贝数据文件是个漫长的过程，我们不能保证数据文件头一定是首先被拷贝到备份里去的。在这过程中，数据库有可能会发生变化，假如已经产生变化的数据块之前已经被拷贝到备份里了，而没有置于begin backup的话其数据文件头里的SCN也将会产生变化，之后，数据文件头被拷贝到备份。如果之后的某个时间数据库需要进行恢复，将备份拷贝过来，从数据文件头的SCN开始进行介质恢复，那么从前面热备份操作时开始拷贝到文件产生变化的这段时间内的数据不在备份里，而介质恢复也不会去重做它，就将导致数据丢失。

换回来讲，如果在热备份时数据文件头的SCN被冻结了，可以保证在进行介质恢复时从830645开始进行恢复，而热备需要大量的日志空间，我们可以猜想从begin backup到end backup这短时间，数据库将相应的变化信息并不是和平时一样简简单单的记录在日志文件中，或许这种状态是将变化的数据块的镜像完全拷贝到日志文件中，在进行介质恢复时，这段时间的信息或许是将变化的数据块（SCN大于datafile SCN）重新覆盖而不是简简单单的redo。

alter tablespace test end backup

链接：http://blog.mchz.com.cn/?p=2763