目的:使用bbed将已经offline掉的datafile 5 的scn信息改为与其他datafile一致。

本位参考自:http://www.xifenfei.com/1527.html

目的:将已经offline掉的datafile 5 的scn信息改为与其他datafile一致。

db版本为11.2.0.4

背景知识:

1、datafile 的file header 存储在第一个block里

2、Oracle considers four attributes of this data structure when determining if a datafile is sync with the other data files of the database:(不同oracle版本offset可能不同)

(1)kscnbas (at offset 140) – SCN of last change to the datafile.

(2)kcvcptim (at offset 148) -Time of the last change to the datafile.

(3)kcvfhcpc (at offset 176) – Checkpoint count.

(4)kcvfhccc (at offset 184) – Unknown, but is always 1 less than thecheckpoint point count.

Oracle有4个属性来判断datafile 是否和其他的datafile 一致,如果都一致,可以正常操作,如果不一致,那么会报ORA-01113错误

bbed password=blockedit blocksize=8192  listfile=/home/oracle/bbed.file mode=edit

/home/oracle/bbed.file的内容如下:
1 /u01/app/oracle/oradata/test/system01.dbf 849346560
2 /u01/app/oracle/oradata/test/sysaux01.dbf 3470786560
3 /u01/app/oracle/oradata/test/undotbs01.dbf 251658240
4 /u01/app/oracle/oradata/test/users01.dbf 382730240
5 /u01/app/oracle/oradata/test/ten01.dbf 52428800
6 /u01/app/oracle/oradata/test/tb_test_01.dbf 5242880
7 /u01/app/oracle/oradata/test/ts1.dbf 524288000
8 /u01/app/oracle/oradata/test/ts2.dbf 524288000
9 /u01/app/oracle/oradata/test/test01.dbf 52428800
10 /u01/app/oracle/oradata/test/test_uni_sz_2m_01.dbf 52428800
11 /u01/app/oracle/oradata/test/test_uni_sz_1m_01.dbf 209715200
12 /u01/app/oracle/oradata/test/test.dbf 10485760

如上内容,可以用如下语句来生成:

select file#||' '||name||' '||bytes from v$datafile;
BBED> set dba 1,1
        DBA             0x00400001 (4194305 1,1)

BBED>  p kcvfhckp
struct kcvfhckp, 36 bytes                   @484
   struct kcvcpscn, 8 bytes                 @484
      ub4 kscnbas                           @484      0x0036b5c8--->
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x344bc95d--->
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500
      struct kcvcprba, 12 bytes             @500
         ub4 kcrbaseq                       @500      0x00000001
         ub4 kcrbabno                       @504      0x000021e7
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00

BBED>  p kcvfhcpc
ub4 kcvfhcpc                                @140      0x00000168--->

BBED> p kcvfhccc
ub4 kcvfhccc                                @148      0x00000167--->
BBED> set dba 5,1
        DBA             0x01400001 (20971521 5,1)

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484
   struct kcvcpscn, 8 bytes                 @484
      ub4 kscnbas                           @484      0x00369818--->
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x344b98b3--->
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500
      struct kcvcprba, 12 bytes             @500
         ub4 kcrbaseq                       @500      0x00000098
         ub4 kcrbabno                       @504      0x0000b62c
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00

BBED> p kcvfhcpc
ub4 kcvfhcpc                                @140      0x00000104--->

BBED> p kcvfhccc
ub4 kcvfhccc                                @148      0x00000103--->

======================================================================================

下面开始修改:
BBED> set dba 5,1
        DBA             0x01400001 (20971521 5,1)

BBED> m /x c8b53600 offset 484
BBED-00209: invalid number (c8b53600)

BBED> m /x c8b5
 File: /u01/app/oracle/oradata/test/ten01.dbf (5)
 Block: 1                Offsets:  484 to  487           Dba:0x01400001
------------------------------------------------------------------------
 c8b53600 

 <32 bytes per line>

BBED> set offset +2
        OFFSET          486

BBED> m /x 3600
 File: /u01/app/oracle/oradata/test/ten01.dbf (5)
 Block: 1                Offsets:  486 to  489           Dba:0x01400001
------------------------------------------------------------------------
 36000000 

 <32 bytes per line>

BBED> m /x 5dc94b34 offset 492
 File: /u01/app/oracle/oradata/test/ten01.dbf (5)
 Block: 1                Offsets:  492 to  495           Dba:0x01400001
------------------------------------------------------------------------
 5dc94b34 

 <32 bytes per line>

BBED> m /x 68010000 offset 140
 File: /u01/app/oracle/oradata/test/ten01.dbf (5)
 Block: 1                Offsets:  140 to  143           Dba:0x01400001
------------------------------------------------------------------------
 68010000 

 <32 bytes per line>

BBED> m /x 67010000 offset 148
 File: /u01/app/oracle/oradata/test/ten01.dbf (5)
 Block: 1                Offsets:  148 to  151           Dba:0x01400001
------------------------------------------------------------------------
 67010000 

 <32 bytes per line>

BBED>  p kcvfhckp
struct kcvfhckp, 36 bytes                   @484
   struct kcvcpscn, 8 bytes                 @484
      ub4 kscnbas                           @484      0x0036b5c8
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x344bc95d
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500
      struct kcvcprba, 12 bytes             @500
         ub4 kcrbaseq                       @500      0x00000098
         ub4 kcrbabno                       @504      0x0000b62c
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00

BBED> p kcvfhcpc
ub4 kcvfhcpc                                @140      0x00000168

BBED> p kcvfhccc
ub4 kcvfhccc                                @148      0x00000167

BBED> sum
Check value for File 5, Block 1:
current = 0xc16c, required = 0xbd5a

BBED> sum apply
Check value for File 5, Block 1:
current = 0xbd5a, required = 0xbd5a

BBED>
SQL> select file#,to_char(checkpoint_change#,'999999999999'),to_char(RESETLOGS_CHANGE#,'999999999999')
from v$datafile_header;  2  

FILE# TO_CHAR(CHECK TO_CHAR(RESET
----- ------------- -------------
    1       3585483       3580553
    2       3585483       3580553
    3       3585483       3580553
    4       3585483       3580553
    5       3585480        995548       --->3585480跟3585483还是不一样。
    6       3585483       3580553
    7       3585483       3580553
    8       3585483       3580553
    9       3585483       3580553
   10       3585483       3580553
   11       3585483       3580553
   12       3395372        995548

12 rows selected.

SQL> recover datafile 5;--->recover是不行滴,原因是该datafile是属于在 resetlog之前就已经offline的数据文件
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 5 belongs to an orphan incarnation
ORA-01110: data file 5: '/u01/app/oracle/oradata/test/ten01.dbf'
时间: 2024-10-11 16:41:58

目的:使用bbed将已经offline掉的datafile 5 的scn信息改为与其他datafile一致。的相关文章

一次导致数据丢失的小变更

前言 不知不觉,技术人生系列·我和数据中心的故事来到了第十期,小y又和大家见面了! 前期我们分享了不少Oracle数据库故障和优化的实战案例,有朋友问,小y是否可以分享一些无备份时数据恢复方面的实战案例呢? 答案自然是--当然可以了.小y从来就不是一个藏着掖着的人嘛 ^_^ 这些年,小y所在的Oracle服务团队,该遇到的和不该遇到的问题,基本都碰到了. 所以在无备份的数据恢复这方面做的案例还是很多的,有时一周甚至要做三四个这样的CASE,问题类型不尽相同,例如: >> 某电信运营商文件系统满

利用 BBED 恢复非归档模式下 OFFLINE 数据文件

今天来模拟一个非归档模式下恢复OFFLINE数据文件的场景,主要有2种情况: 一种是在线日志没有被覆盖,另一种是在线日志被覆盖. 第一种情况比较简单,数据库自身就能处理,而第二种情况稍显复杂,但也并不难,下面开始整个实验过程: 一.在线日志没有被覆盖的场景 --切换数据库到非归档模式 SQL> archive log list Database log mode       Archive Mode Automatic archival       Enabled Archive destina

【BBED】bbed常用命令

[BBED]bbed常用命令         一.1  相关知识点扫盲 BBED(Oracle Block Browerand EDitor Tool),用来直接查看和修改数据文件数据的一个工具,是Oracle一款内部工具,可以直接修改Oracle数据文件块的内容,在一些极端恢复场景下比较有用.该工具不受Oracle支持,所以默认是没有生成可执行文件的,在使用前需要重新连接.   一.1.1  我的编译代码 ls -l  $ORACLE_HOME/rdbms/lib/*sbbd* ls -l 

oracle特殊恢复-bbed修改某个数据文件头

数据文件头中的scn要与控制文件中的scn一致,数据库才可以open,在open过程中我们可以通过bbed来修改某个数据文件头的scn,来欺骗oracle,来open库. 1.环境如下 使用Oracle 11gR2进行测试,具体版本为11.2.0.4 [email protected] SQL>select file#,name,checkpoint_change#,checkpoint_time from v$datafile;      FILE# NAME                 

在归档模式下,恢复一个被offline drop的datafile的方法

参考自: HOW TO RECOVER OFFLINE DROPPED DATAFILE IN ARCHIVELOG MODE (文档 ID 286355.1) 如下的实验基于oracle 11.2.0.4 linux x86-64bit完成 [[email protected] u02]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Sun Feb 15 20:33:17 2015 Copyright (c) 1

无归档情况下使用BBED处理ORA-01113错误

在丢失归档情况下,恢复时常会遇到ora-01113错误,以下实验模拟表空间offline,然后在丢失归档文件的情况下使用BBED修改文件头信息,最后恢复数据文件: 数据库版本: SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Rele

数据文件offline 时oracle 干了那些事?

SQL> oradebug setmypid Statement processed. SQL> oradebug unlimit Statement processed. SQL>  oradebug event 10046 trace name context forever ,level 12; Statement processed. SQL> alter database datafile '/oracle/oradata/lixora/LIXORA/datafile/o

一次归档日志被删除导致offline的datafile 无法访问的问题

版本:10.2.0.5, asm 方式的2个节点rac,rhel5.5 其实该问题的解决思路,应该说是抢救数据出来. 该datafile是索引表空间的非第一个数据文件.app的开发工程师说该表空间内只有index,没有table 使用如下语句查询出该datafile内含有的object: select distinct owner, segment_name, segment_type, partition_name from dba_extents where relative_fno IN

修Bug(中途掉坑里,差点失控,后期完美补刀)

刚接手的项目留下一些bug,是一个word文档,一个一个慢慢解决吧: 先从简单的入手吧,找找感觉: bug:导出的word文档有乱码(<=b>.<=:p>): 生成word文档的方式是有3个模板文件,生成的时候动态替换标题和内容等: 3个文件放在类路径的某个目录下: 没有做缓存,每次都实时IO读取文件,这里可以优化: 问题可能是3个文件的编码,手动改下试试: 改成代码里边写的GBK: 重试,没效果: 修改文件,真的是多了字符,好多低级错误: ok,解决了,这个bug花了40分钟: