[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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【BBED】使用BBED修改資料檔案SCN，使該檔案從offline轉變為online
- BBED 修改oracle 資料檔案的 SCN 號來做資料庫不完全恢復。Oracle資料庫
- Oracle單個資料檔案損壞，在Rman命令裡設定表空間、資料檔案offline方式來恢復最方便Oracle
- Oracle 之利用BBED修改資料塊SCN----沒有備份資料檔案的資料恢復Oracle資料恢復
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 檔案替換後怎麼恢復，恢復被覆蓋的檔案
- 【伺服器資料恢復】Ext4檔案系統執行fsck後檔案掛載報錯的資料恢復伺服器資料恢復
- 資料恢復新姿勢——通過ibd和frm檔案恢復資料資料恢復
- 【伺服器資料恢復】StorNext檔案系統資料恢復案例伺服器資料恢復
- 如何恢復在全備後新增了資料檔案的資料庫資料庫
- 剪下後的檔案可以恢復嗎？恢復剪下檔案怎麼辦？
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- 透過修改控制檔案scn推進資料庫scn資料庫
- uninstall 後的檔案如何恢復
- 【儲存資料恢復】WAFL檔案系統下raid資料恢復案例資料恢復AI
- 膝上型電腦資料恢復之誤格式化後檔案怎麼恢復？資料恢復
- 虛擬機器vmdk檔案刪除後如何恢復資料虛擬機
- 電腦檔案丟失資料恢復資料恢復
- 【資料庫資料恢復】Sql Server資料庫檔案丟失的資料恢復過程資料庫資料恢復SQLServer
- 【RMAN】如果控制檔案損壞那麼如何恢復？恢復控制檔案的方式有哪幾種？
- 【伺服器資料恢復】FSCK後ext3檔案系統無法掛載的資料恢復案例伺服器資料恢復
- 利用offline datafile檔案方式遷移資料
- MSSQL資料庫資料恢復案例:ndf檔案大小變為0KB恢復資料SQL資料庫資料恢復
- 【北亞資料恢復】MongoDB資料遷移檔案丟失的MongoDB資料恢復案例資料恢復MongoDB
- 【資料庫資料恢復】mdb_catalog.wt檔案丟失的MongoDB資料恢復案例資料庫資料恢復MongoDB
- 【資料庫資料恢復】EXT3檔案系統下MYSQL資料庫恢復案例資料庫資料恢復MySql
- 【伺服器資料恢復】xfs檔案系統資料丟失的資料恢復案例伺服器資料恢復
- 從備份片中恢復某個指定得歸檔或者資料檔案
- 資料庫資料恢復-SQL SERVER資料庫檔案大小變為“0”的資料恢復方案資料庫資料恢復SQLServer
- Linux伺服器資料恢復案例；ocfs2檔案系統資料恢復Linux伺服器資料恢復
- oracle基於SCN增量恢復Oracle
- mysql通過frm、idb檔案恢復資料MySql
- SQL SEVER 缺少LOG檔案資料庫恢復SQL資料庫
- 怎樣恢復Mac檔案及資料夾資料？BackupLoupe for mac(資料恢復備份助手)3.5.4Mac資料恢復
- 資料庫資料恢復—MongoDB資料庫檔案丟失，啟動報錯的資料恢復案例資料庫資料恢復MongoDB
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 【伺服器資料恢復】reiserfs檔案系統下RAID5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】ZFS檔案系統下伺服器資料恢復案例伺服器資料恢復
- 伺服器資料恢復-ext3檔案系統下oracle資料庫資料恢復案例伺服器資料恢復Oracle資料庫