alter tablespace begin backup时的逻辑

手动时备份，步骤一般是
1.alter tablespace tablespacexxx begin backup
2.!cp dbf文件
3.alter tablespace tablespacexxx end backup
4. alter system archive log current;

步骤是这样，这begin backup都干了啥

下了begin backup指示后，oracle会先触发一个checkpoint，将这个表空间的数据都写进去，然后锁定checkpong scn。以后发生的改变，仍然会写进datafile，但是文件头的scn却不变了。同时，在写datafile时，会将原来(下begin backup时)的数据，弄回进redo里。恢复的时候，再将redo的内容覆盖会datafile，这样来保证和scn的一致。

所以，begin backup后，redo会写得比平常多，可能延缓系统。

如果不下begin backup，恢复的时候可能会失败，因为os的block的写，比db的block的写是多个操作，完全有可能导致文件头的数据和文件内容不一致，以及同一个db block的数据里面的不同os block的数据不一致(cp出来的文件，同一个db block里的os block，一个是更新前一个更新后)。


姑且这么理解

这里有一个问题，那么恢复后的数据，到底是 alter tablespace tablespacexxx begin backup下指示时的，还是cp下指示时的？
其实，由于是archive模式，并且redo log没断的话，默认恢复后会到最后的scn，也就是所谓的【完全恢复】。