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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【體系結構】SCN與checkpoint（檢查點）
- 透過修改控制檔案scn推進資料庫scn資料庫
- PostgreSQL啟動恢復透過checkpoint open wal檔案SQL
- golang寫入檔案時，覆蓋前檔案（將前檔案清空）Golang
- 湃兔更新映象檔案的製作與燒寫
- 檔案的讀寫
- 【BBED】使用BBED修改資料檔案SCN，使該檔案從offline轉變為online
- 使用EasyX製作遊戲需要讀寫檔案時遇到編碼問題的解決方法遊戲
- Json檔案轉換為Excel檔案!涉及讀檔案,時間戳轉化,寫文件JSONExcel時間戳
- 普通檔案的讀寫
- 配置檔案的編寫
- 【kingsql分享】使用BBED修改Oracle資料檔案頭推進SCNSQLOracle
- 檔案排版（文字檔案讀寫）
- MySQL checkpoint執行時機MySql
- 基於Python的介面自動化-讀寫excel檔案PythonExcel
- Python中的檔案讀寫Python
- Linux作業系統定時備份檔案方法Linux作業系統
- oracle 控制檔案及引數檔案何時自動備份Oracle
- 資料庫課程作業筆記 - 編寫模型檔案資料庫筆記模型
- 製作ISO檔案 與 提取ISO檔案
- Django筆記二十之手動編寫migration檔案Django筆記
- 利用nodejs寫一個自動生成vue元件檔案的cliNodeJSVue元件
- 【淺出 PHP】PHP 檔案操作 寫檔案PHP
- VBA建立文字檔案、讀寫文字檔案
- Linux-檔案寫入和檔案同步Linux
- Golang 讀、寫檔案Golang
- Python 讀寫檔案Python
- PHP寫入檔案PHP
- Python——檔案讀寫Python
- keras讀寫檔案Keras
- 「Python」：檔案讀寫Python
- 【PG】PostgreSQL 預寫日誌(WAL)、checkpoint、LSNSQL
- android中MK檔案的寫法Android
- RPM 的 spec 檔案如何編寫
- 如何編寫 RPM 的 spec 檔案
- python config配置檔案的讀寫Python
- C++ hpp檔案的編寫C++
- ordebug 手動修改Oracle sga scnOracle
- Python中的檔案的讀寫操作Python