SCN與資料庫恢復的關係
scn號與oracle資料庫恢復過程有著密切的關係，只有很好地理解了這層關係，才能深刻地理解恢復的原理，從而才能很好地解決這方面的問題。
一。SCN與CHECKPOINT
CKPT程式在checkpoint發生時，將當時的SCN號寫入資料檔案頭和控制檔案，同時通知DBWR程式將資料塊寫到資料檔案。
CKPT程式也會在控制檔案中記錄RBA(redo block address),以標誌Recovery需要從日誌中哪個地方開始。
與checkpoint相關的SCN號有四個，其中三個存在控制檔案中，一個存放在資料檔案頭中。
這四個分別是：
1.System Checkpoint SCN
當checkpoint完成後，ORACLE將System Checkpoint SCN號存放在控制檔案中。
我們可以透過下面SQL語句查詢：
select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN
當checkpoint完成後，ORACLE將Datafile Checkpoint SCN號存放在控制檔案中。
我們可以透過下面SQL語句查詢所有資料檔案的Datafile Checkpoinnt SCN號。
select name,checkpoint_change# from v$datafile;
3.Start SCN號
ORACLE將Start SCN號存放在資料檔案頭中。
這個SCN用於檢查資料庫啟動過程是否需要做media recovery.
我們可以透過以下SQL語句查詢：
select name,checkpoint_change# from v$datafile_header;
4.End SCN號
ORACLE將End SCN號存放在控制檔案中。
這個SCN號用於檢查資料庫啟動過程是否需要做instance recovery.
我們可以透過以下SQL語句查詢：
select name,last_change# from v$datafile;
在資料庫正常執行的情況下，對可讀寫的，online的資料檔案，該SCN號為NULL.
二。SCN號與資料庫啟動、關閉
在資料庫啟動過程中，當System Checkpoint SCN、Datafile Checkpoint SCN和
Start SCN號都相同時，資料庫可以正常啟動，不需要做media recovery.三者當中有
一個不同時，則需要做media recovery.
ORACLE在啟動過程中首先檢查是否需要media recovery，然後再檢查是否需要instance recovery.
如果資料庫的正常關閉的話，將會觸發一個checkpoint，同時將資料檔案的END SCN號設定為相應資料檔案的Start SCN號。當資料庫啟動時，發現它們是一致的，則不需要做instance recovery。在資料庫正常啟動後，ORACLE
會將END SCN號設定為NULL.
如果資料庫異常關閉的話，則END SCN號將為NULL.則需要做instance recovery.
四。為什麼需要System checkpoint SCN號與Datafile Checkpoint SCN號
為什麼ORACLE會在控制檔案中記錄System checkpoint SCN號的同時，還需要為每個資料檔案記錄
Datafile Checkpoint SCN號？
原因有二：
1.對只讀表空間，其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。
這三個SCN在表空間處於只讀期間都將被凍結。
2.如果控制檔案不是當前的控制檔案，則System checkpoint會小於Start SCN或END SCN號。
記錄這些SCN號，可以區分控制檔案是否是當前的控制檔案。
五。Recovery database using backup controlfile
當有一個Start SCN號超過了System Checkpoit SCN號時，則說明控制檔案不是當前的控制
檔案，因此在做recovery時需要採用using backup controlfile。這是為什麼需要記錄System
Checkpoint SCN的原因之一。
這裡需要一提的是，當重建控制檔案的時候，System Checkpoint SCN為0，Datafile Checkpoint SCN的資料來自於Start SCN。根據上述的描述，此時需要採用using backup controlfile做recovery.
六。示例
例子背景：
oracle 8i
windows
採用rman做熱備，在備份期間，做不少事務，同時做alter system checkpoint.
RMAN> run {
2> allocate channel c1 type disk;
3> backup database filesperset 3 format 'e:/full_%p_%t.bak';
4> }
(這裡需要一提的是，在這個備份角本里面我們加了filesperset 3。這樣將整個資料庫分成
兩個備份集。這樣還原出來的資料檔案其checkpoint_change#將不一樣。
否則由於資料庫資料檔案不多，都將包含在一個備份集中，這樣即使在備份中做insert操作和alter system
checkpoint也不會產生不同的checkpoint_change#。因為rman備份是將一個備份集中的檔案同時備份的。
而checkpoint_change#是存放在資料檔案頭部的，這樣備份這些資料檔案的頭部的時間將是很快的。)
然後
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> }
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2156662354
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 2156662355
2 2156662354
3 2156662322
4 2156662354
5 2156662354
6 2156662354
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ -------------
1 2156662355
2 2156662349
3 2156662322
4 2156662342
5 2156662349
6 2156662342
從這裡可以看出，顯然是需要做media recovery的。正常情況下，還需要做instance recovery.
當然由於沒有線上日誌，所以只能做resetlogs。
1.有歸檔日誌存
若有歸檔日誌在，則只需要做一個recover database until cancel;
然後即可alter database open resetlogs;
SQL> recover database until cancel (using backup controlfile);
ORA-00279: change 2156621770 generated at 10/07/2005 14:30:06 needed for thread 1
ORA-00289: suggestion : D:ORACLE8IRDBMSARC00738.001
ORA-00280: change 2156621770 for thread 1 is in sequence #738
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 2156621779 generated at 10/07/2005 14:30:51 needed for thread
1
ORA-00289: suggestion : D:ORACLE8IRDBMSARC00739.001
ORA-00280: change 2156621779 for thread 1 is in sequence #739
ORA-00278: log file 'D:ORACLE8IRDBMSARC00738.001' no longer needed for this recovery
ORA-00308: cannot open archived log 'D:ORACLE8IRDBMSARC00739.001'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系統找不到指定的檔案。
SQL> alter database open resetlogs;
Database altered.
2.無歸檔日誌
如果沒有歸檔日誌，由於restore出來是沒有線上日誌的。
如果v$datafile_header中checkpoint_change#是相同的，此時由於控制檔案中checkpoint_change#
比資料檔案頭中要高，所以資料庫還是需要做media recovery。
此時重建控制檔案還是一樣的，因為重建控制檔案後，在控制檔案中checkpoint_change#為0，
與檔案頭的checkpoint_change#還是不一樣，還需要media recovery.且由於控制檔案中checkpoint_change#
比檔案頭中要高，所以做recover時還需要加上using backup controlfile.
注意，這時由於沒有線上日誌，所以重建控制檔案需要將noresetlogs改成RESETLOGS才可以建立成功，
否則會報以下錯誤:
ORA-01565: error in identifying file 'D:ORACLE8IORADATAORA8IREDO01.LOG'
ORA-27041: unable to open file
如：
CREATE CONTROLFILE REUSE DATABASE "ORA8I" RESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'D:ORACLE8IORADATAORA8IREDO01.LOG' SIZE 1M,
GROUP 2 'D:ORACLE8IORADATAORA8IREDO02.LOG' SIZE 1M,
GROUP 3 'D:ORACLE8IORADATAORA8IREDO03.LOG' SIZE 1M
DATAFILE
'D:ORACLE8IORADATAORA8ISYSTEM01.DBF',
'D:ORACLE8IORADATAORA8IRBS01.DBF',
'D:ORACLE8IORADATAORA8IUSERS01.DBF',
'D:ORACLE8IORADATAORA8ITEMP01.DBF',
'D:ORACLE8IORADATAORA8ITOOLS01.DBF',
'D:ORACLE8IORADATAORA8IINDX01.DBF'
CHARACTER SET ZHS16GBK
;
此時scn號資訊如下:
SQL> select CHECKPOINT_CHANGE#,CONTROLFILE_CHANGE# from v$database;
CHECKPOINT_CHANGE# CONTROLFILE_CHANGE#
------------------ -------------------
0 0
此時由於沒有歸檔日誌和線上日誌，無法做recovery。
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 2156662342 generated at 10/07/2005 17:06:27 needed for thread 1
ORA-00289: suggestion : D:ORACLE8IRDBMSARC00749.001
ORA-00280: change 2156662342 for thread 1 is in sequence #749
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:ORACLE8IORADATAORA8ISYSTEM01.DBF'
ORA-01112: media recovery not started
所以也就無法做alter database open Resetlogs了。
此時可以加上_allow_resetlogs_corruption隱含引數，然後就可以alter database open resetlogs
將資料庫開啟了。
當然如果v$datafile_header中checkpoint_change#是不相同的，那麼此時就沒有什麼常歸有效的辦法能將
資料庫開啟了。
如果相差不多，加上隱含引數_allow_resetlogs_corruption，然後alter database open resetlogs
還是有可能可以開啟的。這個引數oracle是不建議加的，且加上這個引數也只是有可能可以開啟。
這個引數是以最oldest的scn將資料庫開啟，所以最好system資料檔案的scn號是最oldest的，否則容易產生
大量的600號錯誤。
一。SCN與CHECKPOINT
CKPT程式在checkpoint發生時，將當時的SCN號寫入資料檔案頭和控制檔案，同時通知DBWR程式將資料塊寫到資料檔案。
CKPT程式也會在控制檔案中記錄RBA(redo block address),以標誌Recovery需要從日誌中哪個地方開始。
與checkpoint相關的SCN號有四個，其中三個存在控制檔案中，一個存放在資料檔案頭中。
這四個分別是：
1.System Checkpoint SCN
當checkpoint完成後，ORACLE將System Checkpoint SCN號存放在控制檔案中。
我們可以透過下面SQL語句查詢：
select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN
當checkpoint完成後，ORACLE將Datafile Checkpoint SCN號存放在控制檔案中。
我們可以透過下面SQL語句查詢所有資料檔案的Datafile Checkpoinnt SCN號。
select name,checkpoint_change# from v$datafile;
3.Start SCN號
ORACLE將Start SCN號存放在資料檔案頭中。
這個SCN用於檢查資料庫啟動過程是否需要做media recovery.
我們可以透過以下SQL語句查詢：
select name,checkpoint_change# from v$datafile_header;
4.End SCN號
ORACLE將End SCN號存放在控制檔案中。
這個SCN號用於檢查資料庫啟動過程是否需要做instance recovery.
我們可以透過以下SQL語句查詢：
select name,last_change# from v$datafile;
在資料庫正常執行的情況下，對可讀寫的，online的資料檔案，該SCN號為NULL.
二。SCN號與資料庫啟動、關閉
在資料庫啟動過程中，當System Checkpoint SCN、Datafile Checkpoint SCN和
Start SCN號都相同時，資料庫可以正常啟動，不需要做media recovery.三者當中有
一個不同時，則需要做media recovery.
ORACLE在啟動過程中首先檢查是否需要media recovery，然後再檢查是否需要instance recovery.
如果資料庫的正常關閉的話，將會觸發一個checkpoint，同時將資料檔案的END SCN號設定為相應資料檔案的Start SCN號。當資料庫啟動時，發現它們是一致的，則不需要做instance recovery。在資料庫正常啟動後，ORACLE
會將END SCN號設定為NULL.
如果資料庫異常關閉的話，則END SCN號將為NULL.則需要做instance recovery.
四。為什麼需要System checkpoint SCN號與Datafile Checkpoint SCN號
為什麼ORACLE會在控制檔案中記錄System checkpoint SCN號的同時，還需要為每個資料檔案記錄
Datafile Checkpoint SCN號？
原因有二：
1.對只讀表空間，其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。
這三個SCN在表空間處於只讀期間都將被凍結。
2.如果控制檔案不是當前的控制檔案，則System checkpoint會小於Start SCN或END SCN號。
記錄這些SCN號，可以區分控制檔案是否是當前的控制檔案。
五。Recovery database using backup controlfile
當有一個Start SCN號超過了System Checkpoit SCN號時，則說明控制檔案不是當前的控制
檔案，因此在做recovery時需要採用using backup controlfile。這是為什麼需要記錄System
Checkpoint SCN的原因之一。
這裡需要一提的是，當重建控制檔案的時候，System Checkpoint SCN為0，Datafile Checkpoint SCN的資料來自於Start SCN。根據上述的描述，此時需要採用using backup controlfile做recovery.
六。示例
例子背景：
oracle 8i
windows
採用rman做熱備，在備份期間，做不少事務，同時做alter system checkpoint.
RMAN> run {
2> allocate channel c1 type disk;
3> backup database filesperset 3 format 'e:/full_%p_%t.bak';
4> }
(這裡需要一提的是，在這個備份角本里面我們加了filesperset 3。這樣將整個資料庫分成
兩個備份集。這樣還原出來的資料檔案其checkpoint_change#將不一樣。
否則由於資料庫資料檔案不多，都將包含在一個備份集中，這樣即使在備份中做insert操作和alter system
checkpoint也不會產生不同的checkpoint_change#。因為rman備份是將一個備份集中的檔案同時備份的。
而checkpoint_change#是存放在資料檔案頭部的，這樣備份這些資料檔案的頭部的時間將是很快的。)
然後
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> }
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2156662354
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 2156662355
2 2156662354
3 2156662322
4 2156662354
5 2156662354
6 2156662354
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ -------------
1 2156662355
2 2156662349
3 2156662322
4 2156662342
5 2156662349
6 2156662342
從這裡可以看出，顯然是需要做media recovery的。正常情況下，還需要做instance recovery.
當然由於沒有線上日誌，所以只能做resetlogs。
1.有歸檔日誌存
若有歸檔日誌在，則只需要做一個recover database until cancel;
然後即可alter database open resetlogs;
SQL> recover database until cancel (using backup controlfile);
ORA-00279: change 2156621770 generated at 10/07/2005 14:30:06 needed for thread 1
ORA-00289: suggestion : D:ORACLE8IRDBMSARC00738.001
ORA-00280: change 2156621770 for thread 1 is in sequence #738
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 2156621779 generated at 10/07/2005 14:30:51 needed for thread
1
ORA-00289: suggestion : D:ORACLE8IRDBMSARC00739.001
ORA-00280: change 2156621779 for thread 1 is in sequence #739
ORA-00278: log file 'D:ORACLE8IRDBMSARC00738.001' no longer needed for this recovery
ORA-00308: cannot open archived log 'D:ORACLE8IRDBMSARC00739.001'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系統找不到指定的檔案。
SQL> alter database open resetlogs;
Database altered.
2.無歸檔日誌
如果沒有歸檔日誌，由於restore出來是沒有線上日誌的。
如果v$datafile_header中checkpoint_change#是相同的，此時由於控制檔案中checkpoint_change#
比資料檔案頭中要高，所以資料庫還是需要做media recovery。
此時重建控制檔案還是一樣的，因為重建控制檔案後，在控制檔案中checkpoint_change#為0，
與檔案頭的checkpoint_change#還是不一樣，還需要media recovery.且由於控制檔案中checkpoint_change#
比檔案頭中要高，所以做recover時還需要加上using backup controlfile.
注意，這時由於沒有線上日誌，所以重建控制檔案需要將noresetlogs改成RESETLOGS才可以建立成功，
否則會報以下錯誤:
ORA-01565: error in identifying file 'D:ORACLE8IORADATAORA8IREDO01.LOG'
ORA-27041: unable to open file
如：
CREATE CONTROLFILE REUSE DATABASE "ORA8I" RESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'D:ORACLE8IORADATAORA8IREDO01.LOG' SIZE 1M,
GROUP 2 'D:ORACLE8IORADATAORA8IREDO02.LOG' SIZE 1M,
GROUP 3 'D:ORACLE8IORADATAORA8IREDO03.LOG' SIZE 1M
DATAFILE
'D:ORACLE8IORADATAORA8ISYSTEM01.DBF',
'D:ORACLE8IORADATAORA8IRBS01.DBF',
'D:ORACLE8IORADATAORA8IUSERS01.DBF',
'D:ORACLE8IORADATAORA8ITEMP01.DBF',
'D:ORACLE8IORADATAORA8ITOOLS01.DBF',
'D:ORACLE8IORADATAORA8IINDX01.DBF'
CHARACTER SET ZHS16GBK
;
此時scn號資訊如下:
SQL> select CHECKPOINT_CHANGE#,CONTROLFILE_CHANGE# from v$database;
CHECKPOINT_CHANGE# CONTROLFILE_CHANGE#
------------------ -------------------
0 0
此時由於沒有歸檔日誌和線上日誌，無法做recovery。
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 2156662342 generated at 10/07/2005 17:06:27 needed for thread 1
ORA-00289: suggestion : D:ORACLE8IRDBMSARC00749.001
ORA-00280: change 2156662342 for thread 1 is in sequence #749
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:ORACLE8IORADATAORA8ISYSTEM01.DBF'
ORA-01112: media recovery not started
所以也就無法做alter database open Resetlogs了。
此時可以加上_allow_resetlogs_corruption隱含引數，然後就可以alter database open resetlogs
將資料庫開啟了。
當然如果v$datafile_header中checkpoint_change#是不相同的，那麼此時就沒有什麼常歸有效的辦法能將
資料庫開啟了。
如果相差不多，加上隱含引數_allow_resetlogs_corruption，然後alter database open resetlogs
還是有可能可以開啟的。這個引數oracle是不建議加的，且加上這個引數也只是有可能可以開啟。
這個引數是以最oldest的scn將資料庫開啟，所以最好system資料檔案的scn號是最oldest的，否則容易產生
大量的600號錯誤。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/35489/viewspace-84799/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- SCN號與oracle資料庫恢復的關係Oracle資料庫
- (轉)SCN號與oracle資料庫恢復的關係Oracle資料庫
- SCN, Checkpoint 與 oracle資料庫恢復的關係(final)Oracle資料庫
- 【轉載】SCN 備份與恢復的關係
- SCN, checkpoint 及資料庫的恢復資料庫
- MSSQL-最佳實踐-資料庫恢復模式與備份的關係SQL資料庫模式
- 關閉資料庫的備份與恢復資料庫
- oracle 學習總結篇三:SCN號與資料庫關閉的關係Oracle資料庫
- 檢查點和oracle資料庫的恢復（一）SCNOracle資料庫
- Polardb資料庫掛庫後，如何恢復主備關係資料庫
- zt_Oracle資料恢復：資料檔案頭的SCN與時間校驗_file$_scnOracle資料恢復
- 恢復之資料庫關閉時的完全恢復資料庫
- oracle 學習總結篇三:SCN號與資料庫啟動的關係Oracle資料庫
- 【備份恢復】閃回資料庫（二） 基於 SCN 閃回資料庫資料庫
- 關係型資料庫與非關係型資料庫介紹！資料庫
- 資料庫的備份與恢復資料庫
- 架構與資料庫的關係架構資料庫
- 【資料庫資料恢復】SAP資料庫資料恢復案例資料庫資料恢復
- 資料庫 - 關係代數與關係運算資料庫
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 寶塔資料庫恢復 mysql資料庫丟失恢復 mysql資料庫刪除庫恢復 寶塔mysql資料庫恢復資料庫MySql
- 【資料庫資料恢復】如何恢復Oracle資料庫truncate表的資料資料庫資料恢復Oracle
- 【資料庫資料恢復】windows server下SqlServer資料庫的資料恢復資料庫資料恢復WindowsServerSQL
- oracle日誌挖機 找到scn號 進行資料庫恢復Oracle資料庫
- mysql的資料庫備份與恢復MySql資料庫
- oracle資料庫的備份與恢復Oracle資料庫
- 備份與恢復：polardb資料庫備份與恢復資料庫
- 【資料庫資料恢復】Sql Server資料庫資料恢復案例資料庫資料恢復SQLServer
- BBED 修改oracle 資料檔案的 SCN 號來做資料庫不完全恢復。Oracle資料庫
- 例項，資料庫，資料字典與資料庫建立的關係資料庫
- 【資料庫資料恢復】Oracle資料庫誤truncate table的資料恢復案例資料庫資料恢復Oracle
- 【資料庫資料恢復】誤truncate table的Oracle資料庫資料恢復方案資料庫資料恢復Oracle
- 恢復之非歸檔模式下資料庫非正常關閉的備份與恢復模式資料庫
- oracle redo record scn與transaction相關block scn關係小記Oracle RedoBloC
- RMAN 資料庫修復(restore)與資料庫恢復(recover)介紹資料庫REST
- SQL與NoSQL（關係型與非關係型）資料庫的區別SQL資料庫
- postgresql備份與恢復資料庫SQL資料庫
- mongo資料庫備份與恢復Go資料庫