[20161019]資料檔案offline後恢復到那個scn
[20161019]資料檔案offline後恢復到那個scn號.txt
--前一天別人問的問題，如果資料檔案offline時，online要恢復，一般恢復到scn是多少，是offline時的scn嗎？
--總不見得如果長時間offline，要應用許多歸檔日誌吧，透過測試說明問題：
1.環境：
SYS@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
$ cat x1.sql
select dbms_flashback.get_system_change_number scn from dual;
alter database datafile 6 offline;
select dbms_flashback.get_system_change_number scn from dual;
2.測試：
SCOTT@book> @ x1
SCN
----------
1987849
Database altered.
SCN
----------
1987866
--我的機器沒有什麼事務，恢復的scn是1987849+1=1987850嗎？
BEGIN
DBMS_LOGMNR.START_LOGMNR
(
STARTSCN => 1987849
,ENDSCN => 1987866
,OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
+ DBMS_LOGMNR.CONTINUOUS_MINE
+ DBMS_LOGMNR.COMMITTED_DATA_ONLY
);
END;
/
SCOTT@book> create table xx as select * from V$LOGMNR_CONTENTS ;
Table created.
select * from xx where sql_redo like 'alter database datafile%';
Record View
As of: 2016/10/19 8:48:20
SCN: 1987853
START_SCN:
COMMIT_SCN:
TIMESTAMP: 2016/10/19 8:42:56
START_TIMESTAMP:
COMMIT_TIMESTAMP:
XIDUSN: 2
XIDSLT: 13
XIDSQN: 969
XID: 02000D00C9030000
PXIDUSN: 2
PXIDSLT: 13
PXIDSQN: 969
PXID: 02000D00C9030000
TX_NAME:
OPERATION: DDL
OPERATION_CODE: 5
ROLLBACK: 0
SEG_OWNER:
SEG_NAME:
TABLE_NAME:
SEG_TYPE: 64
SEG_TYPE_NAME:
TABLE_SPACE:
ROW_ID: AAAAAAAAAAAAAAAAAB
USERNAME: UNKNOWN
OS_USERNAME: UNKNOWN
MACHINE_NAME: UNKNOWN
AUDIT_SESSIONID: 0
SESSION#: 0
SERIAL#: 0
SESSION_INFO: UNKNOWN
THREAD#: 1
SEQUENCE#: 2
RBASQN: 53
RBABLK: 4258
RBABYTE: 416
UBAFIL: 3
UBABLK: 0
UBAREC: 0
UBASQN: 0
ABS_FILE#: 0
REL_FILE#: 0
DATA_BLK#: 0
DATA_OBJ#: 0
DATA_OBJV#: 0
DATA_OBJD#: 0
SQL_REDO: alter database datafile 6 offline;
SQL_UNDO:
RS_ID: 0x000035.000010a2.01a0
SSN: 0
CSF: 0
INFO: USER DDL (PlSql=0 RecDep=0)
STATUS: 0
REDO_VALUE: 2
UNDO_VALUE: 3
SAFE_RESUME_SCN:
CSCN:
OBJECT_ID:
EDITION_NAME:
CLIENT_ID:
--scn=1987853
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#,CHECKPOINT_TIME,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,LAST_CHANGE#,LAST_TIME, OFFLINE_CHANGE#, ONLINE_CHANGE#,status,name FROM v$datafile where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME LAST_CHANGE# LAST_TIME OFFLINE_CHANGE# ONLINE_CHANGE# STATUS NAME
----- ------------------ ------------------- --------------------- ------------------- ------------ ------------------- --------------- -------------- ------- --------------------------------------------------
6 1961394 2016-10-18 12:00:07 1731053 2016-10-12 08:59:30 1987850 2016-10-19 08:42:56 0 0 RECOVER /mnt/ramdisk/book/sugar01.dbf
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE# , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name FROM v$datafile_header where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME CREATION_CHANGE# RESETLOGS_CHANGE# STATUS CHECKPOINT_COUNT FUZ NAME TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------------------------- ------------------------------
6 1961394 2016-10-18 12:00:07 1730665 925702 OFFLINE 32 YES /mnt/ramdisk/book/sugar01.dbf SUGAR
--而控制檔案裡面記錄的LAST_CHANGE#=1987850.存在一點點差異，與前面的logminer記錄相差3.不知道為什麼?
RMAN> recover datafile 6 ;
Starting recover at 2016-10-19 08:54:57
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=80 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2016-10-19 08:54:57
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#,CHECKPOINT_TIME,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,LAST_CHANGE#,LAST_TIME, OFFLINE_CHANGE#, ONLINE_CHANGE#,status,name FROM v$datafile where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME LAST_CHANGE# LAST_TIME OFFLINE_CHANGE# ONLINE_CHANGE# STATUS NAME
----- ------------------ ------------------- --------------------- ------------------- ------------ ------------------- --------------- -------------- ------- --------------------------------------------------
6 1987850 2016-10-19 08:42:56 1731053 2016-10-12 08:59:30 1987850 2016-10-19 08:42:56 0 0 OFFLINE /mnt/ramdisk/book/sugar01.dbf
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE# , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name FROM v$datafile_header where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME CREATION_CHANGE# RESETLOGS_CHANGE# STATUS CHECKPOINT_COUNT FUZ NAME TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------------------------- ------------------------------
6 1987850 2016-10-19 08:42:56 1730665 925702 OFFLINE 33 NO /mnt/ramdisk/book/sugar01.dbf SUGAR
--recover後，CHECKPOINT_CHANGE#=1987850,也就是recover 僅僅需要恢復到LAST_CHANGE#=1987850.
SCOTT@book> alter database datafile 6 online ;
Database altered.
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#,CHECKPOINT_TIME,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,LAST_CHANGE#,LAST_TIME, OFFLINE_CHANGE#, ONLINE_CHANGE#,status,name FROM v$datafile where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME LAST_CHANGE# LAST_TIME OFFLINE_CHANGE# ONLINE_CHANGE# STATUS NAME
----- ------------------ ------------------- --------------------- ------------------- ------------ ------------------- --------------- -------------- ------- --------------------------------------------------
6 1988406 2016-10-19 08:58:46 1731053 2016-10-12 08:59:30 0 0 ONLINE /mnt/ramdisk/book/sugar01.dbf
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE# , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name FROM v$datafile_header where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME CREATION_CHANGE# RESETLOGS_CHANGE# STATUS CHECKPOINT_COUNT FUZ NAME TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------------------------- ------------------------------
6 1988406 2016-10-19 08:58:46 1730665 925702 ONLINE 34 YES /mnt/ramdisk/book/sugar01.dbf SUGAR
--online後，LAST_CHANGE#資訊清除。
3.做一個測試看看,這個也是別人問的問題，就是offline後，一些事務rollback會怎樣?
--session 1:
SCOTT@book(90,157)> create table DEMO (id number, name varchar2(20)) tablespace sugar;
Table created.
insert into DEMO values (1,'a');
insert into DEMO values (2,'b');
commit ;
SCOTT@book(90,157)> select rowid,demo.* from demo;
ROWID ID NAME
------------------ ------------ ----
AAAVqfAAGAAAACFAAA 1 a
AAAVqfAAGAAAACFAAB 2 b
SCOTT@book(90,157)> @ &r/rowid AAAVqfAAGAAAACFAAA
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
------------ ------------ ------------ ------------ -------------------- -------------------- ----------------------------------------
88735 6 133 0 0x1800085 6,133 alter system dump datafile 6 block 133 ;
SCOTT@book(90,157)> update demo set name='AAA' where id=1;
1 row updated.
--不提交，開啟另外的會話offline。session 2:
SCOTT@book(46,69)> @ x1
SCN
----------
1988698
Database altered.
SCN
----------
1988708
--session 1:
SCOTT@book(90,157)> rollback ;
rollback
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00376: file 6 cannot be read at this time
ORA-01110: data file 6: '/mnt/ramdisk/book/sugar01.dbf'
ORA-00376: file 6 cannot be read at this time
ORA-01110: data file 6: '/mnt/ramdisk/book/sugar01.dbf'
Process ID: 57177
Session ID: 90 Serial number: 157
--可以發現這個時候執行rollback，要訪問資料檔案，由於offline資料檔案，報錯，事務rollback失敗。也就是這個事務沒有成功。
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#,CHECKPOINT_TIME,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,LAST_CHANGE#,LAST_TIME, OFFLINE_CHANGE#, ONLINE_CHANGE#,status,name FROM v$datafile where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME LAST_CHANGE# LAST_TIME OFFLINE_CHANGE# ONLINE_CHANGE# STATUS NAME
----- ------------------ ------------------- --------------------- ------------------- ------------ ------------------- --------------- -------------- ------- --------------------------------------------------
6 1988406 2016-10-19 08:58:46 1731053 2016-10-12 08:59:30 1988699 2016-10-19 09:06:01 0 0 RECOVER /mnt/ramdisk/book/sugar01.dbf
--再次驗證看看是否recover到scn=LAST_CHANGE#=1988699.
RMAN> recover datafile 6 ;
Starting recover at 2016-10-19 09:09:55
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2016-10-19 09:09:55
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#,CHECKPOINT_TIME,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,LAST_CHANGE#,LAST_TIME, OFFLINE_CHANGE#, ONLINE_CHANGE#,status,name FROM v$datafile where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME LAST_CHANGE# LAST_TIME OFFLINE_CHANGE# ONLINE_CHANGE# STATUS NAME
----- ------------------ ------------------- --------------------- ------------------- ------------ ------------------- --------------- -------------- ------- --------------------------------------------------
6 1988699 2016-10-19 09:06:01 1731053 2016-10-12 08:59:30 1988699 2016-10-19 09:06:01 0 0 OFFLINE /mnt/ramdisk/book/sugar01.dbf
--確實recover僅僅恢復到LAST_CHANGE#。
SCOTT@book> alter database datafile 6 online ;
Database altered.
SCOTT@book> select rowid,demo.* from demo;
ROWID ID NAME
------------------ ---------- --------------------
AAAVqfAAGAAAACFAAA 1 a
AAAVqfAAGAAAACFAAB 2 b
總結：
1.資料檔案offline，最好隨手執行一次recover，或者之前就做一個檢查點。如果僅僅僅僅屬於一個表空間對應一個資料檔案，可以offline表空間，這樣不需要recover。
2.要online，僅僅恢復到控制檔案記錄的LAST_CHANGE#的scn值。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2126709/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Bak檔案恢復到資料庫資料庫
- 資料檔案offline後，再online時，提示需要介質恢復。
- [20161019]資料檔案offline與open resetlog
- zt_Oracle資料恢復：資料檔案頭的SCN與時間校驗_file$_scnOracle資料恢復
- 備份與恢復--重建控制檔案後資料檔案損壞的恢復
- BBED 修改oracle 資料檔案的 SCN 號來做資料庫不完全恢復。Oracle資料庫
- SCN, checkpoint 及資料庫的恢復資料庫
- 資料恢復-電腦管家檔案恢復工具資料恢復
- rman恢復資料檔案 恢復表空間
- 非歸檔模式下恢復利用offline drop命令誤刪除的資料檔案模式
- Oracle 之利用BBED修改資料塊SCN----沒有備份資料檔案的資料恢復Oracle資料恢復
- Oracle單個資料檔案損壞，在Rman命令裡設定表空間、資料檔案offline方式來恢復最方便Oracle
- 恢復之重建資料檔案
- 歸檔模式無備份丟失資料檔案後恢復模式
- 歸檔模式有備份丟失資料檔案後恢復模式
- 某個資料檔案損壞完全恢復（三）
- 一個錯誤的資料檔案的恢復
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- RMAN恢復案例:無恢復目錄，丟失全部資料檔案、控制檔案、日誌檔案恢復
- SCN與資料庫恢復的關係資料庫
- RMAN恢復案例:丟失全部資料檔案恢復
- 檔案替換後怎麼恢復，恢復被覆蓋的檔案
- 歸檔模式有備份丟失控制檔案和資料檔案後恢復模式
- 【伺服器資料恢復】Ext4檔案系統執行fsck後檔案掛載報錯的資料恢復伺服器資料恢復
- 資料檔案誤刪--但有資料檔案的copy恢復
- 如何恢復在全備後新增了資料檔案的資料庫資料庫
- 恢復之還原資料檔案
- 資料檔案丟失的恢復
- [ORACLE ASM] AMDU 恢復資料檔案OracleASM
- 新增資料檔案與恢復cf
- 資料檔案丟失如何恢復
- 丟失一個控制檔案並恢復資料庫資料庫
- Oracle 11g資料庫恢復：場景11：資料檔案損壞,不能恢復到原來的位置, 恢復到新的路徑Oracle資料庫
- 【BBED】使用BBED修改資料檔案SCN，使該檔案從offline轉變為online
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- rman備份恢復-rman恢復資料檔案測試
- rman恢復時跳過資料檔案，進行恢復
- oracle 資料檔案offlineOracle