[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#=1731053.

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值。

时间: 2024-10-22 14:47:12

[20161019]数据文件offline后恢复到那个scn的相关文章

[20161019]数据文件offline与open resetlog

[20161019]数据文件offline与open resetlog.txt --上午做了数据文件offline后恢复到那个scn号,恢复到该数据文件的LAST_CHANGE#的scn值. --如果数据文件做了offline,在以后数据库做了open resetlog后,如何online呢?如果归档存在没有问题, --但是10g开始支持跨resetlog的恢复.自己以前也做了类似的测试. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING            

数据文件offline后unusable索引造成的问题

最近在做一个oracle入库速度测试时,想到将最近一个小时的索引放到内存中(表是按小时分区)是不是会提升入库的速度,索引的维护对io是一个不小的开销: 不过这个方案如果要使用的话数据库必须是 oracle 12c,因为在当前小时结束后,需要将相关索引移出内存,让下一个小时的索引留在内存,这样内存的使用情况基本是一个定量: 而在移动的过程中不能对业务有影响,这样需要用到12c的新功能,在线移动数据文件. 测试的结果是入库速度有很明显的提升,入库速度是之前的几倍,但这个不是本文的重点:本文的重点是在

20160331数据文件offline与open resetlogs2

[20160331]数据文件offline与open resetlogs3.txt --接上面的测试.链接: --关机做一个冷备份,便于重复测试.取出冷备份,重复测试: --做一些必要的清理清除归档. 1.环境: SYS@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ----------------------

[20161012]数据文件offline马上执行recover

[20161012]数据文件offline马上执行recover.txt --前几天看的1篇文章,提到数据文件offline,应该养成随手执行recover习惯.保证下一次online时,不需要恢复. --如果offline很久,忘记online了,而归档日志已经不存在,该如何跳过应用日志,online数据文件呢? --以前也做过一些测试,再重复测试看看.(注意:这样恢复存在数据丢失的风险) 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING           

[20151028]理解数据文件offline+drop.txt

[20151028]理解数据文件offline+drop.txt --前几天做删除数据文件的恢复测试,自己在理解offline drop的方式存在错误,做一个记录: The ALTER DATABASE DATAFILE <datafile name> OFFLINE DROP command, is not meant to allow you to remove a datafile. What the command really means is that you are offlin

数据文件丢失如何恢复

摘要: 数据文件丢失如何恢复,内容来自以下讨论: http://www.itpub.net/348275.html 数据库归档模式,新建表空间testtbs, 数据文件testtbs.dbf关闭数据库删除数据文件testtbs.dbf启动数据库 提示:ORA-01157: 无法标识/锁定数据文件 2 - 请参阅 DBWR 跟踪文件ORA-01110: 数据文件 2: 'D:ORACLEORADATAHAHATESTTBS.DBF' 此数据文件没有做任何备份, 请问这种情况怎么恢复 操作如下: S

临时数据文件 offline 对于导入导出的影响

临时数据文件 offline 对于导入导出的影响 sys@ORACL> alter database tempfile 'd:\oracle\oradata\oracl\temp01.dbf' offline; 数据库已更改. sys@ORACL> ================================================tempfile offline的情况. 1 导出少量数据时,没有报错,当导出大量数据时,会报EXP-00068: 表空间 TEMP 脱机 C:\Use

c++-C++调用CURL下载文件暂停后恢复下载失败。错误码CURLE_PARTIAL_FILE。

问题描述 C++调用CURL下载文件暂停后恢复下载失败.错误码CURLE_PARTIAL_FILE. C++调用CURL下载文件暂停后恢复下载失败.错误码CURLE_PARTIAL_FILE. 暂停一分钟内恢复下载没有问题,但是在暂停超过两分钟恢复下载的时候就会出现CURLE_PARTIAL_FILE. 开始以为是DNS在内存中保存超时了,结果调用了CURLOPT_DNS_CACHE_TIMEOUT还是不行. GOOGLE了一把,有人遇到这个问题,但是没有看到具体的解决方案. curl_easy

solaris ufs文件系统故障后恢复如何oracle数据库

[数据恢复故障描述] 1台sun sparc solaris系统,安装有oracle数据库,未知原因(有人为操作可能,但限于多方原因,无法得知),装载数据库的文件系统无法挂载,需要恢复oracle数据库. [数据恢复过程] 首先对故障硬盘进行全面的完整备份,使用dd命令备份成nfs上的一个镜像文件. 对镜像文件进行完整分析,发现超级块存在故障. 抛开超级块,进行文件系统分析: 1.查找及分析根目录记录,找到. 2.根据根目录查找第一个节点区,找到,并以此分析块大小. 3.根据根据节点区特点,确定