只有datafile的备份+controlfile备份，进行异机数据库恢复实例过程分享

oracle实战分享 2021-10-19

547

一、背景

业务系统所在服务器数据盘出现故障，在做备份时，只做了异地数据库全备，归档未备份到异地，导致在open resetlogs打开报错。

通过现象可以看到，这是oracle比较经典的一个错误，先来了解下这个故障的描述：

ORA-600[2663] [a] [b] [c] [d] []
ARGUMENTS:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE

TheORA-600 [2663] occurs when an SCN is compared to the dependent SCN stored in aUGA variable.If the SCN is less than the dependent SCN then we signal theORA-600 [2663] internal error.

ORA-600 [2663] 发生在 SCN 与存储在 UGA 变量中的从属 SCN 进行比较时。如果 SCN 小于从属 SCN，那么我们会发出 ORA-600 [2663] 内部错误信号。

ORA-600 [2662] [a] [b] [c] [d] [e]具体值来确认。

ARGUMENTS:

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCN WRAP

Arg [d] dependent SCN BASE

Arg [e] Where present this is the DBA wherethe dependent SCN came from.

这两类错误ora-600 2662 2663简单理解就是数据文件里面的某些块所记录的scn要大于数据文件头和控制文件的scn，oracle就认为数据文件头需要介质恢复，而介质恢复本质就是文件头里面的检查点信息、判断介质恢复的信息。搞清楚思路后就开始着手恢复。

再来分析目前备份情况：只有RMAN数据文件全备+控制文件备份，没有任何有效归档可用。

二、恢复记录

2.1 rman恢复记录

A) 写pfile

vi$ORACLE_HOME/dbs/initorcl.ora

*.db_name='ORCL'

*.control_files='/home/oracle/app/oradata/control01.ctl’

B) 然后起库到nomount

Startup nomount;

C) 进入rman恢复控制文件

Rman target

restore database;

D) 恢复过程中可以另开窗口通过下面语句关注大概恢复需要多久时间

selectsid,

serial#,

context,

sofar,

totalwork,

round (time_remaining/60) minutes,

round (sofar totalwork * 100, 2)"%_complete"

fromv$session_longops

where opname like 'RMAN%'

and totalwork != 0

and opname not like '%aggregate%'

and sofar <> totalwork;

2.2 恢复完成后，查看v$datafile 和 v$datafile_header观察checkpoint_change#

SQL>select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

------------------

7333426190

CHECKPOINT_CHANGE#

------------------

7333426190

CHECKPOINT_CHANGE#

------------------

7333426190

28rows selected.

SQL>select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

------------------

7333439098

CHECKPOINT_CHANGE#

------------------

7333439098

CHECKPOINT_CHANGE#

------------------

7333439098

28rows selected.

V$datafile来自于控制文件的数据文件检查点，v$datafile_header来自于数据文件头block 1的检查点信息。7333426190 《 7333439098，说明控制文件的最后一次增量检查点是触发了的，并且更新到了控制文件，但是lgwr写的redo buffer或者 arc0 写的归档还没及时触发dwr,导致脏块未完全刷新到磁盘中，未触发完全检查点ckpt.进行到这一步就需要考虑重建控制文件，让控制文件的信息重新从数据文件头读取，这样两个检查点就一致了。

2.3 重建控制文件

A) 先定位找出重建控制文件的脚本，然后拷贝出来修改。

Alter database backup controlfile to trace as‘/tmp/ctl.txt’;

B) 修改为如下，然后startupnomount下执行

STARTUP NOMOUNT

CREATECONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG

MAXLOGFILES16

MAXLOGMEMBERS2

MAXDATAFILES38

MAXINSTANCES4

MAXLOGHISTORY18688

LOGFILE

GROUP1 '/home/oracle/app/oradata/redo01.log' SIZE 200M BLOCKSIZE 512,

GROUP2 '/home/oracle/app/oradata/redo02.log' SIZE 200M BLOCKSIZE 512,

GROUP3 '/home/oracle/app/oradata/redo03.log' SIZE 200M BLOCKSIZE 512

--STANDBY LOGFILE

DATAFILE

'/home/oracle/app/oradata/system.dbf',

'/home/oracle/app/oradata/sysaux.dbf',

'/home/oracle/app/oradata/undotbs1.dbf',

'/home/oracle/app/oradata/MDC_DATA_INDEX.dbf',

'/home/oracle/app/oradata/QYMP_CALLDATA.dbf',

'/home/oracle/app/oradata/QYMP_LS_SMS_IDX.dbf',

'/home/oracle/app/oradata/MDC_CALLDATA.dbf',

'/home/oracle/app/oradata/MDC_DATA.dbf',

'/home/oracle/app/oradata/MDC_SMS.dbf',

'/home/oracle/app/oradata/USERS01.dbf',

'/home/oracle/app/oradata/QYMP_DATA_INDEX.dbf',

'/home/oracle/app/oradata/LOVE_SPACE_SMS.dbf',

'/home/oracle/app/oradata/LOVE_SPACE_TTS.dbf',

'/home/oracle/app/oradata/EC_SH_INDEX.dbf',

'/home/oracle/app/oradata/MDC_SMS_INDEX.dbf',

'/home/oracle/app/oradata/QYMP_SMS.dbf',

'/home/oracle/app/oradata/EC_SH.dbf',

'/home/oracle/app/oradata/LOVE_SPACE_USERINFO.dbf',

'/home/oracle/app/oradata/MDC_CALLDATA_INDEX.dbf',

'/home/oracle/app/oradata/QYMP_CALLDATA_INDEX.dbf',

'/home/oracle/app/oradata/QYMP_SMS_INDEX.dbf',

'/home/oracle/app/oradata/LOVE_SPACE_CALLDATA.dbf',

'/home/oracle/app/oradata/QYMP_DATA.dbf',

'/home/oracle/app/oradata/undotbs2.dbf',

'/home/oracle/app/oradata/systemnew.dbf',

'/home/oracle/app/oradata/system02.dbf',

'/home/oracle/app/oradata/counp_data01.dbf',

'/home/oracle/app/oradata/qymp_data02.dbf'

CHARACTERSET ZHS16GBK

;

2.4 重建控制文件后继续恢复

A)重建完成后再次查看scn

两边scn已经一致了，变为 7333426190

B)然后尝试openresetlogs打开

在打开过程中提示需要介质恢复,显然还是有问题的。然后想到数据文件头的控制位置，然后使用命令查看哪些文件需要介质恢复，针对性的去进行处理。

selectfile#,name,recover,fuzzy,status from v$datafile_header;

SQL>/

FILE# NAME REC FUZ STATUS

---------------------------------------------------------------------- --- --- -------

1/home/oracle/app/oradata/system.dbf NO ONLINE

2/home/oracle/app/oradata/sysaux.dbf YES ONLINE

3 home/oracle/app/oradata/undotbs1.dbf NO ONLINE

4/home/oracle/app/oradata/MDC_DATA_INDEX.dbf NO ONLINE

5/home/oracle/app/oradata/QYMP_CALLDATA.dbf YES ONLINE

6 home/oracle/app/oradata/QYMP_LS_SMS_IDX.dbf NO ONLINE

7/home/oracle/app/oradata/MDC_CALLDATA.dbf YES ONLINE

8/home/oracle/app/oradata/MDC_DATA.dbf YES ONLINE

9 /home/oracle/app/oradata/MDC_SMS.dbf YES ONLINE

10/home/oracle/app/oradata/USERS01.dbf NO ONLINE

11/home/oracle/app/oradata/QYMP_DATA_INDEX.dbf NO ONLINE

FILE# NAME REC FUZ STATUS

---------------------------------------------------------------------- --- --- -------

12/home/oracle/app/oradata/LOVE_SPACE_SMS.dbf NO ONLINE

13/home/oracle/app/oradata/LOVE_SPACE_TTS.dbf NO ONLINE

14/home/oracle/app/oradata/EC_SH_INDEX.dbf NO ONLINE

15/home/oracle/app/oradata/MDC_SMS_INDEX.dbf NO ONLINE

16/home/oracle/app/oradata/QYMP_SMS.dbf YES ONLINE

17/home/oracle/app/oradata/EC_SH.dbf NO ONLINE

18/home/oracle/app/oradata/LOVE_SPACE_USERINFO.dbf NO ONLINE

19/home/oracle/app/oradata/MDC_CALLDATA_INDEX.dbf NO ONLINE

20/home/oracle/app/oradata/QYMP_CALLDATA_INDEX.dbf NO ONLINE

21/home/oracle/app/oradata/QYMP_SMS_INDEX.dbf NO ONLINE

22/home/oracle/app/oradata/LOVE_SPACE_CALLDATA.dbf NO ONLINE

FILE# NAME REC FUZ STATUS

---------------------------------------------------------------------- --- --- -------

23/home/oracle/app/oradata/QYMP_DATA.dbf YES ONLINE

24/home/oracle/app/oradata/undotbs2.dbf NO ONLINE

25/home/oracle/app/oradata/systemnew.dbf YES ONLINE

26/home/oracle/app/oradata/system02.dbf NO ONLINE

27/home/oracle/app/oradata/counp_data01.dbf NO ONLINE

28/home/oracle/app/oradata/qymp_data02.dbf YES ONLINE

C) 标底色的就是需要处理的文件头，处理文件头就需要使用oracle 内部工具BBED，考虑到远程操作不方便，这里就使用操作系统的dd命令进行导出导入文件头数据了。

2.5 操作系统导出好的和坏的文件头

A)先dd出有问题的文件头

--dderr

ddif=/home/oracle/app/oradata/sysaux.dbf of=/home/oracle/app/headerbak/sysaux bs=8192 count=32

ddif=/home/oracle/app/oradata/QYMP_CALLDATA.dbfof=/home/oracle/app/headerbak/QYMP_CALLDATA bs=8192 count=32

ddif=/home/oracle/app/oradata/MDC_CALLDATA.dbfof=/home/oracle/app/headerbak/MDC_CALLDATA bs=8192 count=32

ddif=/home/oracle/app/oradata/MDC_DATA.dbf of=/home/oracle/app/headerbak/MDC_DATAbs=8192 count=32

ddif=/home/oracle/app/oradata/MDC_SMS.dbf of=/home/oracle/app/headerbak/MDC_SMS bs=8192 count=32

ddif=/home/oracle/app/oradata/QYMP_SMS.dbf of=/home/oracle/app/headerbak/QYMP_SMS bs=8192 count=32

ddif=/home/oracle/app/oradata/QYMP_DATA.dbfof=/home/oracle/app/headerbak/QYMP_DATA bs=8192 count=32

ddif=/home/oracle/app/oradata/systemnew.dbfof=/home/oracle/app/headerbak/systemnew bs=8192 count=32

ddif=/home/oracle/app/oradata/qymp_data02.dbfof=/home/oracle/app/headerbak/qymp_data02 bs=8192 count=32

B) 再dd出好的文件头去对比

--ddok

ddif=/home/oracle/app/oradata/system.dbf of=/home/oracle/app/headerbak/systemokbs=8192 count=32

ddif=/home/oracle/app/oradata/EC_SH.dbf of=/home/oracle/app/headerbak/ok2.dbfbs=8192 count=32

2.6 拷贝走备份的数据到异机修复文件头

A)BBED 操作：

配置bbed，这个就跳过了，网上很多资料

B)进入bbed，然后查看文件头情况

[ora11g@ol7 ~]$ bbed parfile=bbed.par

BBED: Release 2.0.0.0.0 - LimitedProduction on Thu Oct 14 10:46:38 2021

************* !!! For Oracle Internal Useonly !!! ***************

BBED> info --查看写入需要修改的文件信息

File# Name Size(blks)

----- ---- ----------

1 /restore/systemok 0

2 /restore/ok2.dbf 0

3 /restore/MDC_CALLDATA 0

4 /restore/MDC_DATA 0

5 /restore/MDC_SMS 0

6 /restore/QYMP_CALLDATA 0

7 /restore/QYMP_DATA 0

8 /restore/qymp_data02 0

9 /restore/QYMP_SMS 0

10 /restore/sysaux 0

11 /restore/systemnew 0

12 /u02/app/oracle/oradata/zlhis/users01.dbf 0

13 /u02/app/oracle/oradata/zlhis/system01.dbf 0

BBED> set dba 1,1 --设置要操作的文件号块号

DBA 0x00400001(4194305 1,1)

BBED> map /v --看块的信息汇总,我要修改的位置主要是kcvfh结构里面

File: /restore/systemok (1)

Block: 1 Dba:0x00400001

------------------------------------------------------------

DataFile Header

struct kcvfh, 860 bytes @0

struct kcvfhbfh, 20 bytes @0

struct kcvfhhdr, 76 bytes @20

ub4 kcvfhrdb @96

struct kcvfhcrs, 8 bytes @100

ub4 kcvfhcrt @108

ub4 kcvfhrlc @112

struct kcvfhrls, 8 bytes @116

ub4 kcvfhbti @124

struct kcvfhbsc, 8 bytes @128

ub2 kcvfhbth @136

ub2 kcvfhsta @138

struct kcvfhckp, 36 bytes @484

ub4 kcvfhcpc @140

ub4 kcvfhrts @144

ub4 kcvfhccc @148

struct kcvfhbcp, 36 bytes @152

ub4 kcvfhbhz @312

struct kcvfhxcd, 16 bytes @316

sword kcvfhtsn @332

ub2 kcvfhtln @336

text kcvfhtnm[30] @338

ub4 kcvfhrfn @368

struct kcvfhrfs, 8 bytes @372

ub4 kcvfhrft @380

struct kcvfhafs, 8 bytes @384

ub4 kcvfhbbc @392

ub4 kcvfhncb @396

ub4 kcvfhmcb @400

ub4 kcvfhlcb @404

ub4 kcvfhbcs @408

ub2 kcvfhofb @412

ub2 kcvfhnfb @414

ub4 kcvfhprc @416

struct kcvfhprs, 8 bytes @420

struct kcvfhprfs, 8 bytes @428

ub4 kcvfhtrt @444

ub4tailchk @8188

BBED> p kcvfh --查看文件头信息

struct kcvfh, 860 bytes @0

struct kcvfhbfh,20 bytes @0

ub1 type_kcbh @0 0x0b

ub1 frmt_kcbh @1 0xa2

ub1 spare1_kcbh @2 0x00

ub1 spare2_kcbh @3 0x00

ub4 rdba_kcbh @4 0x00400001

ub4 bas_kcbh @8 0x00000000

ub2 wrp_kcbh @12 0x0000

ub1 seq_kcbh @14 0x01

ub1 flg_kcbh @15 0x04 (KCBHFCKV)

ub2 chkval_kcbh @16 0xb64b

ub2 spare3_kcbh @18 0x0000

struct kcvfhhdr, 76 bytes @20

ub4 kccfhswv @20 0x00000000

ub4 kccfhcvn @24 0x0b200000

ub4 kccfhdbi @28 0x557fcf87

text kccfhdbn[0] @32 O

text kccfhdbn[1] @33 R

text kccfhdbn[2] @34 C

text kccfhdbn[3] @35 L

text kccfhdbn[4] @36

text kccfhdbn[5] @37

text kccfhdbn[6] @38

text kccfhdbn[7] @39

ub4 kccfhcsq @40 0x00000001

ub4 kccfhfsz @44 0x003ff680

s_blkz kccfhbsz @48 0x00

ub2 kccfhfno @52 0x0001

ub2 kccfhtyp @54 0x0003

ub4 kccfhacid @56 0x00000000

ub4 kccfhcks @60 0x00000000

text kccfhtag[0] @64

text kccfhtag[1] @65

text kccfhtag[2] @66

text kccfhtag[3] @67

text kccfhtag[4] @68

text kccfhtag[5] @69

text kccfhtag[6] @70

text kccfhtag[7] @71

text kccfhtag[8] @72

text kccfhtag[9] @73

text kccfhtag[10] @74

text kccfhtag[11] @75

text kccfhtag[12] @76

text kccfhtag[13] @77

text kccfhtag[14] @78

text kccfhtag[15] @79

text kccfhtag[16] @80

text kccfhtag[17] @81

text kccfhtag[18] @82

text kccfhtag[19] @83

text kccfhtag[20] @84

text kccfhtag[21] @85

text kccfhtag[22] @86

text kccfhtag[23] @87

text kccfhtag[24] @88

text kccfhtag[25] @89

text kccfhtag[26] @90

text kccfhtag[27] @91

text kccfhtag[28] @92

text kccfhtag[29] @93

text kccfhtag[30] @94

text kccfhtag[31] @95

ub4 kcvfhrdb @96 0x00400091

struct kcvfhcrs, 8 bytes @100

ub4 kscnbas @100 0x00000007

ub2 kscnwrp @104 0x0000

ub4 kcvfhcrt @108 0x360a8408

ub4 kcvfhrlc @112 0x378577aa

struct kcvfhrls, 8 bytes @116

ub4 kscnbas @116 0x05e0ea1a

ub2 kscnwrp @120 0x0000

ub4 kcvfhbti @124 0x00000000

struct kcvfhbsc, 8 bytes @128

ub4 kscnbas @128 0x00000000

ub2 kscnwrp @132 0x0000

ub2 kcvfhbth @136 0x0000

ub2 kcvfhsta @138 0x2000 (NONE) system正常的是这个0x2000，异常关闭为0x20004

struct kcvfhckp, 36 bytes @484

struct kcvcpscn, 8 bytes @484

ub4 kscnbas @484 0xb51b340e

ub2 kscnwrp @488 0x0001

ub4 kcvcptim @492 0x409d6d8e

ub2 kcvcpthr @496 0x0001

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

ub4 kcrbaseq @500 0x0002f420

ub4 kcrbabno @504 0x00009350

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

ub4 kcvfhcpc @140 0x0003ebfd

ub4 kcvfhrts @144 0x40b93bad

ub4 kcvfhccc @148 0x0003ebfc

struct kcvfhbcp, 36 bytes @152

struct kcvcpscn, 8 bytes @152

ub4 kscnbas @152 0x00000000

ub2 kscnwrp @156 0x0000

ub4 kcvcptim @160 0x00000000

ub2 kcvcpthr @164 0x0000

union u, 12 bytes @168

struct kcvcprba, 12 bytes @168

ub4 kcrbaseq @168 0x00000000

ub4 kcrbabno @172 0x00000000

ub2 kcrbabof @176 0x0000

ub1 kcvcpetb[0] @180 0x00

ub1 kcvcpetb[1] @181 0x00

ub1 kcvcpetb[2] @182 0x00

ub1 kcvcpetb[3] @183 0x00

ub1 kcvcpetb[4] @184 0x00

ub1 kcvcpetb[5] @185 0x00

ub1 kcvcpetb[6] @186 0x00

ub1 kcvcpetb[7] @187 0x00

ub4 kcvfhbhz @312 0x00000000

struct kcvfhxcd, 16 bytes @316

ub4 space_kcvmxcd[0] @316 0x00000000

ub4 space_kcvmxcd[1] @320 0x00000000

ub4 space_kcvmxcd[2] @324 0x00000000

ub4 space_kcvmxcd[3] @328 0x00000000

sword kcvfhtsn @332 0

ub2 kcvfhtln @336 0x0006

text kcvfhtnm[0] @338 S

text kcvfhtnm[1] @339 Y

text kcvfhtnm[2] @340 S

text kcvfhtnm[3] @341 T

text kcvfhtnm[4] @342 E

text kcvfhtnm[5] @343 M

text kcvfhtnm[6] @344

text kcvfhtnm[7] @345

text kcvfhtnm[8] @346

text kcvfhtnm[9] @347

text kcvfhtnm[10] @348

text kcvfhtnm[11] @349

text kcvfhtnm[12] @350

text kcvfhtnm[13] @351

text kcvfhtnm[14] @352

text kcvfhtnm[15] @353

text kcvfhtnm[16] @354

text kcvfhtnm[17] @355

text kcvfhtnm[18] @356

text kcvfhtnm[19] @357

text kcvfhtnm[20] @358

text kcvfhtnm[21] @359

text kcvfhtnm[22] @360

text kcvfhtnm[23] @361

text kcvfhtnm[24] @362

text kcvfhtnm[25] @363

text kcvfhtnm[26] @364

text kcvfhtnm[27] @365

text kcvfhtnm[28] @366

text kcvfhtnm[29] @367

ub4 kcvfhrfn @368 0x00000001

struct kcvfhrfs, 8 bytes @372

ub4 kscnbas @372 0x00000000

ub2 kscnwrp @376 0x0000

ub4 kcvfhrft @380 0x00000000

struct kcvfhafs, 8 bytes @384

ub4 kscnbas @384 0x00000000

ub2 kscnwrp @388 0x0000

ub4 kcvfhbbc @392 0x00000000

ub4 kcvfhncb @396 0x00000000

ub4 kcvfhmcb @400 0x00000000

ub4 kcvfhlcb @404 0x00000000

ub4 kcvfhbcs @408 0x00000000

ub2 kcvfhofb @412 0x000a

ub2 kcvfhnfb @414 0x000a

ub4 kcvfhprc @416 0x375a65b2

struct kcvfhprs, 8 bytes @420

ub4 kscnbas @420 0x02964ab1

ub2 kscnwrp @424 0x0000

struct kcvfhprfs, 8 bytes @428

ub4 kscnbas @428 0x00000000

ub2 kscnwrp @432 0x0000

ub4 kcvfhtrt @444 0x00000000

正常文件头，除system外应该为0x0000，但是有问题的是为0x0004，这就是介质恢复的标志。

知道了这个就可以逐步修改文件头了，使用下面图片的语句，将12，1的这个值赋予给2，1 依次类推，恢复完成9个文件。

修复完成后拷贝到生成库headerbaknew

2.7 操作系统导入修改的文件头去覆盖旧的文件头

--imoport

ddof=/home/oracle/app/oradata/sysaux.dbf if=/home/oracle/app/headernew/sysaux bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/QYMP_CALLDATA.dbfif=/home/oracle/app/headernew/QYMP_CALLDATA bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/MDC_CALLDATA.dbfif=/home/oracle/app/headernew/MDC_CALLDATA bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/MDC_DATA.dbf if=/home/oracle/app/headernew/MDC_DATAbs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/MDC_SMS.dbf if=/home/oracle/app/headernew/MDC_SMS bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/QYMP_SMS.dbf if=/home/oracle/app/headernew/QYMP_SMS bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/QYMP_DATA.dbfif=/home/oracle/app/headernew/QYMP_DATA bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/systemnew.dbfif=/home/oracle/app/headernew/systemnew bs=8192 count=32 conv=notrunc

ddof=/home/oracle/app/oradata/qymp_data02.dbfif=/home/oracle/app/headernew/qymp_data02 bs=8192 count=32 conv=notrunc

修复完成后校验恢复情况：

可以看到fuz全部变为了NO

2.7 尝试使用alter databaseopen resetlogs打开数据库

开库完成后数据库被意外crash，报错ora-600 2662 2663,接着进行恢复。

Recover database;

Recover database until cancel;

Recover database using backup controlfile;

...

经过测试均报错，出现current日志损坏情况，最后在执行recover database until scn任然无法解决。最后没有办法，在pfile加入不得不使用的两个参数来欺骗oracle一致性，然后再使用scn推进的方式跳过一致性检查。

*._allow_resetlogs_corruption=TRUE

*._allow_error_simulation=TRUE

2.8 第二次使用alter database open resetlogs打开

开库完成后数据库被意外crash，报错ora-600 2662 2663,接着进行恢复。

推进scn号进行处理。

2^32 = 4294967296 ，我们直接把 wrap更新为 10（hex A），base为0，这时候，我们预计开库后的SCN应该是 42949672960 大一点。

a) 查看当前的scn

SQL> selectcheckpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

330003350

b) 查看scn在当前内存的地址

SQL> oradebugsetmypid

Statement processed.

SQL> oradebugDUMPvar SGA kcsgscn

kcslf kcsgscn_ [060012658, 060012688) = 0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000000000000 60012338 00000000

修改scnwrap为A，因为我们是小端，所以wrap为后四位，从地址位060012654+4 开始修改，后推4位：

其中 060012658= 060012654+ 4

c) 确认修改的scn并修改

--修改的是反的。01代表高位，10代表低位

SQL> oradebug poke0x060012658 8 0x0000000100000010

BEFORE: [060012658, 060012660)= 00000001 00000000

AFTER: [060012658, 060012660) = 00000010 00000001

SQL> oradebug DUMPvar SGAkcsgscn

kcslf kcsgscn_ [060012658,060012688) = 00000010 0000000100000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000060012338 00000000

SQL> alter database open;

SQL> selectcheckpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

4294967313

2.8 重建temp

create temporary tablespace TEMP3 tempfile '/home/oracle/app/oradata/TEMP3.DBF' size 100m reuse autoextend on next 1M;

alter database default temporary tablespaceTEMP3;

drop tablespace TEMP including contents anddatafiles;

create temporary tablespace TEMP tempfile'/home/oracle/app/oradata/temp01.dbf' size 100m reuse autoextend on next 1M;

alter database default temporary tablespaceTEMP;

drop tablespace TEMP3 including contentsand datafiles;

数据库

文章转载自oracle实战分享，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

只有datafile的备份+controlfile备份，进行异机数据库恢复实例过程分享

一、背景

二、恢复记录

2.1 rman恢复记录

2.2 恢复完成后，查看v$datafile 和 v$datafile_header观察checkpoint_change#

2.3 重建控制文件

2.4 重建控制文件后继续恢复

2.5 操作系统导出好的和坏的文件头

2.6 拷贝走备份的数据到异机修复文件头

2.7 尝试使用alter databaseopen resetlogs打开数据库

评论