[20161019]数据文件offline后恢复到那个scn

最新推荐文章于 2024-10-02 00:27:17 发布
最新推荐文章于 2024-10-02 00:27:17 发布
阅读量82 收藏
点赞数
文章标签： 数据库 操作系统
原文链接：https://yq.aliyun.com/articles/279644
版权

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

weixin_34049948
关注
Linux Host "Abort command issued"
Full Stack Engineer
09-15 5534
I still investigate this issue, and it now narrow down after we hard work. Thanks my team mate. Something we alred
Oracle数据文件scn不一致,控制文件与数据文件头SCN不一致导致数据库无法启动故障处理...
weixin_42460407的博客
04-06 1697
环境说明OS操作系统：WINDOWS 2012 64位数据库版 本：ORACLE 11.2.0.1故障问题描述客户反映数据库无法启动，报ORA-01589：要打开数据库必须使用RESETLOGS或NORESETLOGS选项。使用alter database openresetlogs启动数据库报ORA-01194：文件1需要更多恢复来保持一致性，ORA-01110：数据文件1：‘E:\APP\YI...
V$LOGMNR_CONTENTS各字段的意思
m0_37797416的博客
03-11 968
V$LOGMNR_CONTENTS视图包含日志历史记录信息。 查询此视图的用户，必须有select any transaction权限。查询此视图将按顺序读取归档的redo log文件。 列 数据类型 描述 SCN NUMBER System change number，oracle为了避免操作系统时间不同步等问题自己定义的在某个时间点定义数据库已提交版本的...
oracle数据库offline,oracle的offline scn/online scn
weixin_42501130的博客
04-02 99
当表空间或数据文件被offline时，其对应的数据文件的scn会写入一个值,被称为offline scn. 不过有一些值得注意的地方，我这里用实验来进行剖析，让大家更容易理解：查看当前的4号表空间的scnSYS@hyyk> select file#,checkpoint_change# from v$datafile where ts#=4;FILE# CHECKPOINT_CHANGE#-...
SNS交换机（OEM博科FC交换机）的端口状态及排查流程说明
Pipcie的博客
07-21 2079
问题描述 交换机的端口状态可以通过switchshow命令和portshow命令查看,端口物理上主要有哪几种状态，分别的含义及定位方法是？ 解决方案 端口物理上主要有几种状态，分别的含义及异常定位方法如下： No_Card No interface card present.No_Module No module (GBIC or other) present.端口没有插入光模块No_Light Module is not receiving light (8 Gbps-capable ports
Oracle数据文件scn不一致,数据文件SCN的一致性问题
weixin_35951275的博客
04-06 826
1、数据库正常运行中，所有数据文件的SCN都是一致的吗？2、将一数据文件offline后，再将其online时，这个数据文件的SCN会前提吗？假如是，前提到的SCN是怎么确定的？1.数据库正常运行时，所有数据文件的SCN不一定一致。问题在这个所有上，比如Offline表空间，数据文件的SCN会被冻结，而且表空间的数据文件offline/online时又会发生文件检查点，使单个数据文件SCN和数据库...
oracle数据库offline,案例:Oracle数据库启动报错ORA-01190 数据文件offline无法online
weixin_32096149的博客
04-02 889
天萃荷净Oracle数据库无法启动 文件无法online 通过Oracle bbed工具解决ORA-01190当我们使用resetlogs方式打开数据库后，发现有数据文件处于offline状态，这个时候很可能就是悲剧降临的时候，很有可能这个文件文件在resetlogs之前就处于offline状态，然后你resetlogs之后，这个文件使用常规方法很难再online，会出现ORA-01190或者OR...
无备份情况下，将数据文件从offline到online
S1156578253的博客
07-22 1295
模拟在没有案发的说法别模拟在
Oracle RMAN恢复带有OFFLINE数据文件的数据库
lk的窝
09-18 2344
1、创建测试表空间及测试数据文件 SQL> create tablespace test datafile '/u01/app/oracle/oradata/qlotcdb/test.dbf' size 1M; SQL> create user test identified by test default tablespace test; User created. SQL> alt
关于表空间及数据文件的offline与online
u014057054的专栏
04-24 2644
一、数据文件 在对单个数据文件做offline时,是立即offline,此时不会针对数据文件生成检查点,所以数据文件的终止SCN为无穷大,处于不一致状态,数据文件也需要recover,在v$recover_file视图也可以看到这个文件的信息,要想将数据文件online,必须先对文件执行recover操作,必,所以建议offline数据文件后应该立刻执行recover操作,使他处于一致状态,
关于PLSQL中的一些问题总结：在PLSQL中书写DDL等
五彩世界的博客
05-21 2519
关于问题前导，使用的数据表中涉及到的字段和类型：在PLSQL中create、drop、truncate等DDL是没有办法直接执行的。必须要使用：Execute immediate ‘DDL语句’但是我发现这样并不能执行！后面查阅发现，oracle中执行DDL语句需要使用变量的形式：即 所谓的动态SQL语句首先在declare中声明变量(  例如：sql varchar2(200):= ‘creat...
集群各节点显示的状态均为OFFLINE
weixin_42459738的博客
07-28 981
现象描述 在集群的任意一个节点上执行gcadmin，显示的节点状态均为OFFLINE，如下图所示： 原因分析 出现该问题的原因是由于gcware内探测节点状态所使用的ssh端口与系统的ssh端口不匹配导致的，检查ssh端口是否一致的方法为： 首先执行cat /etc/corosync/corosync.conf命令查看corosync配置文件中的node_ssh_port端口，如下图所示，如果配置文件中没有node_ssh_port端口，表示程序默认使用22端口： 然后执行cat /etc/ssh/ss
通过logminer分析truncate与delete删除数据的效率问题
DolphinHat的专栏
10-22 1793
首先打开数据库的最小日志附加模式: alter database add supplemental log data; 准备两张数据表: create table t03 as select * from dba_objects; create table t04 as select * from dba_objects; 下面我们通过logminer来分析truncate与
MySQL之复合查询与内外连接
zdlynj的博客
09-30 1202
前面我们讲解的mysql表的查询都是对一张表进行查询，即数据的查询都是在某一时刻对一个表进行操作的。而在实际开发中，我们往往还需要对多个表同时进行查询。我们这里使用的测试表，为雇员信息表(来自Oracle 9i的经典测试表)：EMP员工表，DEPT部门表，SALGRADE工资等级表。
点评项目-2-完善注册登录业务
m0_75138009的博客
09-29 560
需要处理的业务：在网页发送 /user/code 路径下的 post 请求后，我们需要检验手机号后，向合法的手机号发送一个随机生成的电话号。
Spring的热部署工具和数据库密码加盐操作
2301_77053417的博客
09-28 766
加密过程：用户输入的密码+盐值 --> 字符串1，然后使用md5对字符串1加密得到字符串2，然后字符串2+盐值 --> 字符串3，这个字符串3就是存储在数据库中的密文。背景：如果我们的密码明文存储在数据库中，要是被窃取了是非常的危险的，所以我们在数据库中存储的密码不能是明文的，需要进行加密后存储，也就是数据库中存储的是密文。解密过程：取出数据库中的盐值和用户输入的密码得到字符串1，使用md5对字符串1加密得到字符串2，然后验证字符串2和数据库中的密文即可。做好以上的步骤，你项目中的热部署就已经做好了。
World of Warcraft [CLASSIC][80][Grandel] Call to Arms: Victory in Wintergrasp
最新发布
qq 117791303
10-02 274
Wintergrasp 冬拥湖 120 VS 120
Oracle数据库：正确删除与恢复表空间数据文件指南
5. **数据恢复**：在操作系统级别误删数据文件后，可能需要通过备份和恢复操作来恢复数据文件，或者利用RMAN等工具进行还原。 6. **安全操作**：在执行删除操作前，确保有完整的数据库备份，并了解删除操作的潜在...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值