checkpoint時的SCN寫檔案動作
參考自：http://blog.csdn.net/tianlesoftware/article/details/5251916
當發生checkpoint時，會把SCN寫到四個地方去：三個地方於control file內，一個在datafile header。
一、實驗，如下：
--Control fil e三個地方為：
1.1 System checkpoint SCN ===========> (SYSTEM CHECKPOINT SCN in control file)
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3779864
1.2 Datafile checkpoint SCN ===============> (DATAFILE CHECKPOINT SCN in control file)
SQL> set lines 200
SQL> col name for a60
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3779864
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3779864
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3779864
/u01/app/oracle/oradata/DBdb/users01.dbf 3779864
/u01/app/oracle/oradata/DBdb/example01.dbf 3779864
1.3 Stop SCN ======================> (STOP SCN in control file)
SQL> select name,last_change# from v$datafile;
NAME LAST_CHANGE#
------------------------------------------------------------ ------------
/u01/app/oracle/oradata/DBdb/system01.dbf
/u01/app/oracle/oradata/DBdb/sysaux01.dbf
/u01/app/oracle/oradata/DBdb/undotbs01.dbf
/u01/app/oracle/oradata/DBdb/users01.dbf
/u01/app/oracle/oradata/DBdb/example01.dbf
正常datafile在read-write mode下 last_change#一定是NULL
--另外一個地方在datafile header內
1.4 Start SCN ================================> (DATAFILE HEADER)
SQL> select name, checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3779864
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3779864
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3779864
/u01/app/oracle/oradata/DBdb/users01.dbf 3779864
/u01/app/oracle/oradata/DBdb/example01.dbf 3779864
SQL>
二、相關問題
2.1 為什麼儲存在CONTROL FILE中要分為兩個地方(SYSTEM CHECKPOINT SCN,DATAFILE CHECKPOINT SCN) ?
當你把一個tbs設為read-only時，他的SCN會凍結停止，此時DATAFILE CHECKPOINT SCN是不會再遞增改變的， 但是整體的SYSTEM CHECKPOINT SCN卻仍然會不斷遞增前進。
所以，這就是為什麼需要分別在兩個地方儲存SCN
2.2 正常shutdown database後，SCN會發生什麼變化？我們可以把資料庫開在mount mode，如下：
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup mount;
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2257840 bytes
Variable Size 549456976 bytes
Database Buffers 281018368 bytes
Redo Buffers 2371584 bytes
Database mounted.
SQL>
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3782319
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782319
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782319
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782319
/u01/app/oracle/oradata/DBdb/users01.dbf 3782319
/u01/app/oracle/oradata/DBdb/example01.dbf 3782319
SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
------------------------------------------------------------ ------------------ ------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/users01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/example01.dbf 3782319 3782319
可以看到儲存在control file中的三個SCN位置都是相同，注意此時的stop scn不會是NULL，而是等於start scn
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782319
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782319
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782319
/u01/app/oracle/oradata/DBdb/users01.dbf 3782319
/u01/app/oracle/oradata/DBdb/example01.dbf 3782319
當clean shutdown 時，checkpoint會進行，並且此時datafile的stop scn和start scn會相同。 等到我門開啟資料庫時，Oracle檢查datafile header中的start scn和存於control file中的datafile的scn是否相同， 如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，資料庫就會正常開啟，否則就需要recovery... 等到資料庫開啟後，儲存在control file中的stop scn就會恢復為NULL值，此時表示datafile是open在正常模式下了。
如果不正常SHUTDOWN (shutdown abort)，則mount資料庫後，你會發現stop scn並不是等於其它位置的scn， 而是等於NULL，這表示Oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery。
crash recovery：
必須先進行roll forward(從redo log file中從目前的start SCN開始，重做後面的已提交之交易)。再從roll back segment 做rollback未完成(dead transaction)交易。檢驗controlfile中的SCN會等於datafile header的SCN
2.3 先進行備份：（資料庫處於mount狀態，冷備）；
RMAN> backup database tag='full database';
Starting backup at 28-NOV-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00004 name=/u01/app/oracle/oradata/DBdb/users01.dbf
input datafile file number=00001 name=/u01/app/oracle/oradata/DBdb/system01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/DBdb/undotbs01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/DBdb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/DBdb/example01.dbf
channel ORA_DISK_1: starting piece 1 at 28-NOV-17
channel ORA_DISK_1: finished piece 1 at 28-NOV-17
piece handle=/u01/app/oracle/fast_recovery_area/DBDB/backupset/2017_11_28/o1_mf_nnndf_FULL_DATABASE_f1t8rv9q_.bkp tag=FULL DATABASE comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:15
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 28-NOV-17
channel ORA_DISK_1: finished piece 1 at 28-NOV-17
piece handle=/u01/app/oracle/fast_recovery_area/DBDB/backupset/2017_11_28/o1_mf_ncsnf_FULL_DATABASE_f1t8z23m_.bkp tag=FULL DATABASE comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 28-NOV-17
RMAN>
--shutdown abort資料庫：
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
Database altered.
SQL> shutdown abort;
ORACLE instance shut down.
SQL>
--啟庫：
SQL> conn / as sysdba
Connected to an idle instance.
SQL>
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2257840 bytes
Variable Size 549456976 bytes
Database Buffers 281018368 bytes
Redo Buffers 2371584 bytes
SQL>
SQL> alter database mount;
Database altered.
--查詢scn狀態：
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3782322
SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
------------------------------------------------------------ ------------------ ------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782322
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782322
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782322
/u01/app/oracle/oradata/DBdb/users01.dbf 3782322
/u01/app/oracle/oradata/DBdb/example01.dbf 3782322
stop scn並不是等於其它位置的scn， 而是等於NULL，表示需要進行crash recovery
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782322
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782322
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782322
/u01/app/oracle/oradata/DBdb/users01.dbf 3782322
/u01/app/oracle/oradata/DBdb/example01.dbf 3782322
2.4 crash recovery 和media recovery 的比較
啟動資料庫時，如果發現STOP SCN = NULL，表示需要進行crash recovery；啟動資料庫時，如果發現有datafile header的START SCN 不等於儲存於CONTROLFILE的DATAFILE SCN，表示需要進行Media recovery
STOP SCN equal NULL ==> NEED CRASH RECOVERY
DATAFILE HEADER START SCN not equal CONTROLFILE SCN ==> NEED MEDIA RECOVERY
三、RECOVERY DATABASE 兩種常見問題
3.1 RECOVER DATABASE UNTIL CANCEL ==> OPEN DATABASE RESETLOG
==> DATAFILE HEADER SCN一定會小於CONTROLFILE的DATAFILE SCN
如果你有進行RESTORE DATAFILE，則該RESTORE的DATAFILE HEADER SCN一定會小於目前CONTROLFILE的DATAFILE SCN，此時會無法開啟資料庫，必須進行media recovery。 重做archive log直到該datafile header的SCN=current scn
restore datafile後，可以mount database然後去檢查controlfile and datafile header的SCN
select 'controlfile' "SCN location",name,checkpoint_change#
from v$datafile where name like '%users01%'
union
select 'file header',name,checkpoint_change#
from v$datafile_header where name like '%users01%';
3.2 RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; ===> OPEN DATABASE RESETLOG
==> DATAFILE HEADER SCN一定會大於CONTROLFILE的DATAFILE SCN
如果只是某TABLE被DROP掉，沒有破壞資料庫整體資料結構，還可以用NCOMPLETE RECOVERY解決 如果是某個TABLESPACE OR DATAFILE被DROP掉，因為檔案結構已經破壞，目前的CONTROL FILE內已經沒有 該DATAFILE的資訊，就算你只RESTORE DATAFILE然後進行INCOMPLETE RECOVERY也無法救回被DROP的DATA FILE。
只好RESOTRE 之前備份的CONTROL FILE(裡頭被DROP DATAFILE Metadata此時還存在)，不過RESTOREC CONTROL FILE後 此時Oracle會發現CONTROL FILE內的SYSTEM SCN會小於目前的DATAFILE HEADER SCN，也不等於目前儲存於LOG FILE內的SCN， 此時就必須使用RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE到DROP DATAFILE OR DROP TABLESPACE之前的SCN。
另一種特殊狀況就是，萬一不幸地所有CONTROL FILE都遺失了，也必須用這種方式救回，所以請做MULTIPLEXING。
當發生checkpoint時，會把SCN寫到四個地方去：三個地方於control file內，一個在datafile header。
一、實驗，如下：
--Control fil e三個地方為：
1.1 System checkpoint SCN ===========> (SYSTEM CHECKPOINT SCN in control file)
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3779864
1.2 Datafile checkpoint SCN ===============> (DATAFILE CHECKPOINT SCN in control file)
SQL> set lines 200
SQL> col name for a60
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3779864
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3779864
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3779864
/u01/app/oracle/oradata/DBdb/users01.dbf 3779864
/u01/app/oracle/oradata/DBdb/example01.dbf 3779864
1.3 Stop SCN ======================> (STOP SCN in control file)
SQL> select name,last_change# from v$datafile;
NAME LAST_CHANGE#
------------------------------------------------------------ ------------
/u01/app/oracle/oradata/DBdb/system01.dbf
/u01/app/oracle/oradata/DBdb/sysaux01.dbf
/u01/app/oracle/oradata/DBdb/undotbs01.dbf
/u01/app/oracle/oradata/DBdb/users01.dbf
/u01/app/oracle/oradata/DBdb/example01.dbf
正常datafile在read-write mode下 last_change#一定是NULL
--另外一個地方在datafile header內
1.4 Start SCN ================================> (DATAFILE HEADER)
SQL> select name, checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3779864
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3779864
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3779864
/u01/app/oracle/oradata/DBdb/users01.dbf 3779864
/u01/app/oracle/oradata/DBdb/example01.dbf 3779864
SQL>
二、相關問題
2.1 為什麼儲存在CONTROL FILE中要分為兩個地方(SYSTEM CHECKPOINT SCN,DATAFILE CHECKPOINT SCN) ?
當你把一個tbs設為read-only時，他的SCN會凍結停止，此時DATAFILE CHECKPOINT SCN是不會再遞增改變的， 但是整體的SYSTEM CHECKPOINT SCN卻仍然會不斷遞增前進。
所以，這就是為什麼需要分別在兩個地方儲存SCN
2.2 正常shutdown database後，SCN會發生什麼變化？我們可以把資料庫開在mount mode，如下：
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup mount;
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2257840 bytes
Variable Size 549456976 bytes
Database Buffers 281018368 bytes
Redo Buffers 2371584 bytes
Database mounted.
SQL>
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3782319
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782319
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782319
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782319
/u01/app/oracle/oradata/DBdb/users01.dbf 3782319
/u01/app/oracle/oradata/DBdb/example01.dbf 3782319
SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
------------------------------------------------------------ ------------------ ------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/users01.dbf 3782319 3782319
/u01/app/oracle/oradata/DBdb/example01.dbf 3782319 3782319
可以看到儲存在control file中的三個SCN位置都是相同，注意此時的stop scn不會是NULL，而是等於start scn
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782319
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782319
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782319
/u01/app/oracle/oradata/DBdb/users01.dbf 3782319
/u01/app/oracle/oradata/DBdb/example01.dbf 3782319
當clean shutdown 時，checkpoint會進行，並且此時datafile的stop scn和start scn會相同。 等到我門開啟資料庫時，Oracle檢查datafile header中的start scn和存於control file中的datafile的scn是否相同， 如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，資料庫就會正常開啟，否則就需要recovery... 等到資料庫開啟後，儲存在control file中的stop scn就會恢復為NULL值，此時表示datafile是open在正常模式下了。
如果不正常SHUTDOWN (shutdown abort)，則mount資料庫後，你會發現stop scn並不是等於其它位置的scn， 而是等於NULL，這表示Oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery。
crash recovery：
必須先進行roll forward(從redo log file中從目前的start SCN開始，重做後面的已提交之交易)。再從roll back segment 做rollback未完成(dead transaction)交易。檢驗controlfile中的SCN會等於datafile header的SCN
2.3 先進行備份：（資料庫處於mount狀態，冷備）；
RMAN> backup database tag='full database';
Starting backup at 28-NOV-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00004 name=/u01/app/oracle/oradata/DBdb/users01.dbf
input datafile file number=00001 name=/u01/app/oracle/oradata/DBdb/system01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/DBdb/undotbs01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/DBdb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/DBdb/example01.dbf
channel ORA_DISK_1: starting piece 1 at 28-NOV-17
channel ORA_DISK_1: finished piece 1 at 28-NOV-17
piece handle=/u01/app/oracle/fast_recovery_area/DBDB/backupset/2017_11_28/o1_mf_nnndf_FULL_DATABASE_f1t8rv9q_.bkp tag=FULL DATABASE comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:15
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 28-NOV-17
channel ORA_DISK_1: finished piece 1 at 28-NOV-17
piece handle=/u01/app/oracle/fast_recovery_area/DBDB/backupset/2017_11_28/o1_mf_ncsnf_FULL_DATABASE_f1t8z23m_.bkp tag=FULL DATABASE comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 28-NOV-17
RMAN>
--shutdown abort資料庫：
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
Database altered.
SQL> shutdown abort;
ORACLE instance shut down.
SQL>
--啟庫：
SQL> conn / as sysdba
Connected to an idle instance.
SQL>
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2257840 bytes
Variable Size 549456976 bytes
Database Buffers 281018368 bytes
Redo Buffers 2371584 bytes
SQL>
SQL> alter database mount;
Database altered.
--查詢scn狀態：
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3782322
SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
------------------------------------------------------------ ------------------ ------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782322
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782322
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782322
/u01/app/oracle/oradata/DBdb/users01.dbf 3782322
/u01/app/oracle/oradata/DBdb/example01.dbf 3782322
stop scn並不是等於其它位置的scn， 而是等於NULL，表示需要進行crash recovery
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
/u01/app/oracle/oradata/DBdb/system01.dbf 3782322
/u01/app/oracle/oradata/DBdb/sysaux01.dbf 3782322
/u01/app/oracle/oradata/DBdb/undotbs01.dbf 3782322
/u01/app/oracle/oradata/DBdb/users01.dbf 3782322
/u01/app/oracle/oradata/DBdb/example01.dbf 3782322
2.4 crash recovery 和media recovery 的比較
啟動資料庫時，如果發現STOP SCN = NULL，表示需要進行crash recovery；啟動資料庫時，如果發現有datafile header的START SCN 不等於儲存於CONTROLFILE的DATAFILE SCN，表示需要進行Media recovery
STOP SCN equal NULL ==> NEED CRASH RECOVERY
DATAFILE HEADER START SCN not equal CONTROLFILE SCN ==> NEED MEDIA RECOVERY
三、RECOVERY DATABASE 兩種常見問題
3.1 RECOVER DATABASE UNTIL CANCEL ==> OPEN DATABASE RESETLOG
==> DATAFILE HEADER SCN一定會小於CONTROLFILE的DATAFILE SCN
如果你有進行RESTORE DATAFILE，則該RESTORE的DATAFILE HEADER SCN一定會小於目前CONTROLFILE的DATAFILE SCN，此時會無法開啟資料庫，必須進行media recovery。 重做archive log直到該datafile header的SCN=current scn
restore datafile後，可以mount database然後去檢查controlfile and datafile header的SCN
select 'controlfile' "SCN location",name,checkpoint_change#
from v$datafile where name like '%users01%'
union
select 'file header',name,checkpoint_change#
from v$datafile_header where name like '%users01%';
3.2 RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; ===> OPEN DATABASE RESETLOG
==> DATAFILE HEADER SCN一定會大於CONTROLFILE的DATAFILE SCN
如果只是某TABLE被DROP掉，沒有破壞資料庫整體資料結構，還可以用NCOMPLETE RECOVERY解決 如果是某個TABLESPACE OR DATAFILE被DROP掉，因為檔案結構已經破壞，目前的CONTROL FILE內已經沒有 該DATAFILE的資訊，就算你只RESTORE DATAFILE然後進行INCOMPLETE RECOVERY也無法救回被DROP的DATA FILE。
只好RESOTRE 之前備份的CONTROL FILE(裡頭被DROP DATAFILE Metadata此時還存在)，不過RESTOREC CONTROL FILE後 此時Oracle會發現CONTROL FILE內的SYSTEM SCN會小於目前的DATAFILE HEADER SCN，也不等於目前儲存於LOG FILE內的SCN， 此時就必須使用RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE到DROP DATAFILE OR DROP TABLESPACE之前的SCN。
另一種特殊狀況就是，萬一不幸地所有CONTROL FILE都遺失了，也必須用這種方式救回，所以請做MULTIPLEXING。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31397003/viewspace-2147892/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Checkpoint和SCN的解析
- 初學checkpoint and scn
- How to get SCN ,TIMESTAMP ,CHECKPOINT
- RedoLog Checkpoint 和 SCN關係
- SCN, checkpoint 及資料庫的恢復資料庫
- oracle mount_open_checkpoint(scn)啟動驗證測試Oracle
- Oracle SCN機制解析 (SCN, checkpoint檢查點) - finalOracle
- 重建控制檔案時，與資料檔案相關的Checkpoint資訊來自何處
- 重做日誌檔案中的SCN
- PostgreSQL啟動恢復透過checkpoint open wal檔案SQL
- zt_Oracle資料恢復：資料檔案頭的SCN與時間校驗_file$_scnOracle資料恢復
- 【體系結構】SCN與checkpoint（檢查點）
- 資料檔案的SCN和資料塊的SCN有何區別
- 透過修改控制檔案scn推進資料庫scn資料庫
- SCN、Checkpoint、例項恢復介質恢復理解
- Checkpoint not complete 日誌檔案問題
- 湃兔更新映象檔案的製作與燒寫
- golang寫入檔案時，覆蓋前檔案（將前檔案清空）Golang
- SCN, Checkpoint 與 oracle資料庫恢復的關係(final)Oracle資料庫
- 資料庫控制檔案中的SCN詳解資料庫
- 關於資料檔案頭的檢查點SCN
- 檢視錶空間及資料檔案的checkpoint資訊
- 檔案的讀寫
- 資料檔案SCN的一致性問題
- Mybatis配置檔案resultMap對映啥時候可寫可不寫？MyBatis
- Linux 核心驅動中對檔案的讀寫Linux
- 重建控制檔案, 資料檔案檢查點SCN到底來自哪裡？
- Json檔案轉換為Excel檔案!涉及讀檔案,時間戳轉化,寫文件JSONExcel時間戳
- 普通檔案的讀寫
- Oracle資料庫的SCN轉換成時間和時間轉換成SCNOracle資料庫
- 小記基於控制檔案的scn不完全恢復
- 關於資料檔案頭的檢查點SCN知識
- 檔案-臨時檔案
- MySQL checkpoint執行時機MySql
- 製作URL檔案的方法
- 檔案排版（文字檔案讀寫）
- SCN 時間戳的相互轉換時間戳
- 檔案讀寫