對ORACLE SCN的理解

1、SCN數值實際來源於系統的timestamp，這個實際可以證明
select current_scn from v$database;
select timestamp_to_scn(sysdate) from dual;
這兩個數值是完全一樣的。
2、在資料庫關閉和啟動的過程中，在關閉的時候，用系統SCN同步了資料檔案頭SCN和控制檔案SCN，在啟動的過程中，資料庫檔案頭SCN和控制檔案SCN還有START SCN和STOP SCN，這些是用來控制資料庫是否在啟動的時候，需要繼續介質恢復，但是啟動完成之後，第一個系統SCN，我判斷應該是有TIMETASMP生成出來的，因為這第一個SCN，比啟動之後的資料檔案頭SCN多了很多，一個空閒資料庫在關閉15分鐘之後，啟動之後，第一個SCN和資料檔案頭SCN，數值相差500多，說明系統啟動之後，系統SCN是透過TIMESTAMP來的，而不是繼承上一次關閉的SCN。
3、經過實際檢測發現，用來修改checkpoint scn的CKPT程式，應該有3個觸發條件：1是手動，alter system checkpoint，2是由日誌切換觸發，手動或者自動切換重做日誌，均會觸發CKPT程式執行，3是資料庫乾淨重啟，將控制檔案、資料檔案頭、系統的checkpoint scn進行同步。
一個保持7*24小時長時間執行的資料庫，checkpoint scn的改變頻率，是和線上日誌大小及業務量有關的，改變頻率等於線上日誌的切換頻率，線上日誌小而且業務量大，那麼checkpoint的改變頻率就快。但是從整個資料庫4個SCN看起來，改變頻率最慢的還是checkpoint scn，其他的改變頻率都要比這個快。
在v$database中，有兩個相似的scn，分別是archive_change#和archivelog_change#，archivelog_change#是當前日誌的開始SCN，也是當前的checkpoint scn，而archive_change#，卻是上一個日誌的開始scn，這個看起來有點奇怪，仔細想想，用處還比較大，archive_change#，確實應該是之前的checkpoint scn，確切的描述應該是上上次的checkpoint scn，正確的描述應該是當前日誌的上一個日誌的開始SCN，所以可以說是上上次的checkpoint scn，那麼用途是什麼呢，用途應該是兩個，一個是這個scn之前的日誌要強制歸檔，也就是說，在3個日誌模式中，當前日誌的下一個日誌，比如當前日誌是redo02，那麼下一個日誌就是redo03，這個redo03，在未歸檔之前，其實就是archive_change#之前的日誌，這個說法就很明確了，也說明了為什麼資料庫必須確保3個日誌，2個日誌不行，因為當前日誌無法歸檔，上一個日誌可以延後歸檔，資料庫設定上上一個日誌要強制歸檔，那麼當前日誌、上一個日誌、上上個日誌，當然要全部存在，才好做了。這裡又引申出來，這樣archive_change#的第二個用途，從之前的描述可以看出，當前日誌肯定無法歸檔，同時上一個日誌也可以沒有被歸檔，這是為了減低磁碟IO壓力，做的非同步歸檔，上一個日誌是一個延後歸檔，那麼在當前日誌剛切換，上一個日誌還沒有歸檔的時候，資料庫出現問題，需要恢復，怎麼辦，archive_change#，就可以非常方便查出需要檢查是否恢復的大概範圍。這樣做，好像看起來有點多餘，但是這應該是資料安全的另外一層保障機制。oracle資料庫強調的就是資料安全。