系統改變號和系統提交號

system commit number Vs system change number

system commit number
僅僅表示 提交時候產生的 SCN ,是 SCN 的一部分 ，不等於 SCN


system change number : 資料庫發生任何變化所產生的 SCN ,指所有的 SCN


產生 SCN 的原因很多！
DML/commit/rollback/job/資料庫遞迴呼叫/關閉開啟資料庫/日誌緩衝區若是並行分配…… 很多情況，任何資料庫的改變都會導致 SCN 的增加！

從這裡可以查：
SQL>select FIRST_CHANGE# from v$log;--日誌檔案同步號   
SQL>select file#,checkpoint_change# from v$datafile;--資料檔案同步號    ??
SQL>select checkpoint_change# from v$database;--控制檔案同步號  system change number


這是在ASKTOM.ORACLE.COM
說的很清楚的.
The SCN will -- but not the checkpoint_change#. Thats the last SCN
checkpointed:

system@ORACLE8I> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
725781

system@ORACLE8I> commit;

Commit complete.

system@ORACLE8I> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
725781

system@ORACLE8I> alter system checkpoint;

System altered.

system@ORACLE8I> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
725798

system@ORACLE8I> alter system checkpoint;

System altered.

system@ORACLE8I> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
725799

It'll change after a checkpoint.

就象我們打電話
scn 每個電話明細單號
檢查點 月底結帳

SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;

scn>=CHECKPOINT_CHANGE#
scn是一個一隻增的數字，有時候在control file, datafile 和redo log file的scn會不一致，經過一段時間後經過一次checkpoint，這幾個檔案得scn號就同步了，然後又開始不同步，又checkpoint，就這樣迴圈。形象一點就是scn始終要快checkpoint半拍，但同步那一刻是一樣的


System Change Number (SCN)
An SCN defines a committed version of the database. A query reports the contents of the database
as it looked at some specific SCN. An SCN is allocated and saved in the header of a redo record
that commits a transaction. An SCN may also be saved in a record when it is necessary to mark the
redo as being allocated after a specific SCN. SCN’s are also allocated and stored in other data
structures such as the controlfile or datafile headers. An SCN is at least 48 bits long. Thus they can
be allocated at a rate of 16,384 SCN’s per second for over 534 years without running out of them.
We will run out of SCN’s in June, 2522 AD (we use 31 day months for time stamps).

v$database中的checkpoint_change#是誰的SCN？
是在最後一次checkpoint時
幾個檔案都同步的scn

10 如何設定log_checkpoint_interval的值？
1）日誌轉換間的檢查點
如5M的重做日誌檔案與512位元組的OS塊，日誌間有四個檢查點。
LOG_CHECKPOINT_INTERVAL = 日誌大小/OS塊大小/檢查點出現次數
= 5242880 / 512 / 4 = 2560
2）僅僅在一個日誌轉換上的檢查點
LOG_CHECKPOINT_INTERVAL = CEIL（日誌大小/OS塊大小 + 1）
= CEIL（5242880 / 512 + 1）= 10241


那為什麼checkpoint太頻繁會導致not complete呢？

一個日誌檔案中可能發生n多次檢查點，
在日誌切換時，需要觸發一個檢查點，但
此時ckpt程式卻沒有到達檢查點產生的時機，所以
就會等待嘛，但如果LOG_CHECKPOINT_INTERVAL
設定得當，
剛好在日誌切換時產生CP，
那就是最好的，
不會產生cp not complete的問題

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24558279/viewspace-746153/，如需轉載，請註明出處，否則將追究法律責任。