我們在對數據庫進行熱備份的時候，需要將表空間置於脫機或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
