Oracle can be placed in the first file number, [Case] Oracle error ORA-01210 Repair method for corruption of datafile header block...

Tiancuihejing

OracleResearch Center Case Analysis: Operation and Maintenance DBA reported that the Oracle database encountered an error ORA-01210 analysis reason was caused by the data file header block, and the damaged file was repaired using BBED.

Except for reprinting on this website, all articles on this website are original by this website: Reprinted from love wife & love life —Roger's Oracle Technology Blog

Link address of this article: Datafile in Archivelog modeheaderHow to recover if damaged?

The client database has a failure, and the file header of the two datafiles is completely damaged, which may behardwareThe problem caused.

At that time, it waswindowsThe environment, through remote desktop operation, is too stuck, and someone has already gone through a series of operations before taking over, which makes recovery relatively troublesome. The way I took is to use their previous create datafile, use bbed to modify the ckpt information, and then open the library first. Finally, use data extractionsoftwareExtract the backed up corrupt datafile data and load it directly into the database.

Here I will use vm to simulate how to manually restore if the datafile header block is just damaged? Of course, if there is

If other blocks are damaged, such as the bitmap block in front of the datafile header, then recovery is quite complicated.

—Simulate the file header corruption first

BBED> info

File# Name Size(blks)

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

1 /home/ora10g/oradata/roger/ 0

2 /home/ora10g/oradata/roger/ 0

3 /home/ora10g/oradata/roger/ 0

4 /home/ora10g/oradata/roger/ 0

6 /home/ora10g/oradata/roger/undotbs2_01.dbf 0

8 /home/ora10g/oradata/roger/sqlt_01.dbf 0

BBED> copy file 4 block 5 to file 2 block 1

Warning: contents of previous BIFILE will be lost. Proceed (Y/N) y

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 0 to 511 Dba:0x00800001

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

1ea20000 05000001 b7220000 00000104 19c10000 04000000 09800f00 00000000

00000000 00f80000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> sum apply

Check value for File 2, Block 1:

current = 0xc119, required = 0xc119

BBED> set file 2 block 1

FILE# 2

BLOCK# 1

BBED> verify

DBVERIFY - Verification starting

FILE = /home/ora10g/oradata/roger/

BLOCK = 1

Block 1 is corrupt

Corrupt block relative dba: 0x01000001 (file 0, block 1)

Bad header found during verification

Data in bad block:

type: 30 format: 2 rdba: 0x01000005

last change scn: 0x0000.000022b7 seq: 0x1 flg: 0x04

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0x22b71e01

check value in block header: 0xc119

computed block checksum: 0x0

DBVERIFY - Verification complete

Total Blocks Examined : 1

Total Blocks Processed (Data) : 0

Total Blocks Failing (Data) : 0

Total Blocks Processed (Index): 0

Total Blocks Failing (Index): 0

Total Blocks Empty : 0

Total Blocks Marked Corrupt : 1

Total Blocks Influx : 0

At this time, you will encounter an error like the following:

SQL> startup

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed SIZE 1272600 bytes

Variable SIZE 146801896 bytes

DATABASE Buffers 16777216 bytes

Redo Buffers 2920448 bytes

DATABASE mounted.

ORA-01122: DATABASE file 2 failed verification CHECK

ORA-01110: DATA file 2: '/home/ora10g/oradata/roger/'

ORA-01210: DATA file header IS media corrupt

SQL> recover datafile 2;

ORA-00283: recovery SESSION canceled due TO errors

ORA-01110: DATA file 2: '/home/ora10g/oradata/roger/'

ORA-01122: DATABASE file 2 failed verification CHECK

ORA-01110: DATA file 2: '/home/ora10g/oradata/roger/'

ORA-01210: DATA file header IS media corrupt

Of course, my simulation here is a bit absolute. In some cases, it can be recovered in this case. If the file header block is completely damaged. It cannot be repaired directly. If you have a backup, you can release the datafile restore from the backup and then recover, so that's it.

In the last case, before I took over, someone had rebuilt the datafile and rebuilt the controlfile (the original file was not backed up).

Similar operations: alter database create datafile ‘/home/ora10g/oradata/roger/’. Of course, this step also requires you to rebuild the controlfile first or use an older controlfile to replace the current controlfile, otherwise you will encounter such an error:

SQL> alter database create datafile 2 as '/home/ora10g/oradata/roger/';

alter database create datafile 2 as '/home/ora10g/oradata/roger/'

ERROR at line 1:

ORA-01178: file 2 created before last CREATE CONTROLFILE, cannot recreate

ORA-01110: data file 2: '/home/ora10g/oradata/roger/'

SQL> !oerr ora 1178

01178, 00000, "file %s created before last CREATE CONTROLFILE, cannot recreate"

// *Cause: Attempted to use ALTER DATABASE CREATE DATAFILE to recreate a

// datafile that existed at the last CREATE CONTROLFILE command.

// The information needed to recreate the file was lost with the

// control file that existed when the file was added to the database.

// *Action: Find a backup of the file, and recover it. Do incomplete recovery

// to time before file was originally created.

In this case, after creating the datafile, its scn is very old. If you need to recover, then you need all archivelogs from the scn to the present.

In this case, you can manually repair the data file header. If the damage is serious, then you can be lazy, copy other datfiles and then modify them.

++++++++++ The following is the entire repair process. I will briefly demonstrate it here.

BBED>copy file 4 block 1 to file 2 block 1

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 0 to 511 Dba:0x00800001

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

0ba20000 01000001 00000000 00000104 b2590000 00000000 0005200a 294d0a93

524f4745 52000000 db210000 60950000 00200000 04000300 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 b0220000 00000000 cb3eb32a 8ebafc2f d4a75c00 00000000 00000000

00000000 00000000 00000000 8b040000 d7b8fc2f 8a040000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 04000000 05005553 45525300 00000000 00000000

00000000 00000000 00000000 00000000 04000000 00000000 00000000 1d41672f

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

e8b8fc2f f1a65c00 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 c6bc5d00 00000000 24aa0830 01000000 03000000 29610000 10000000

<32 bytes per line>

BBED> set file 2 block 1

FILE# 2

BLOCK# 1

BBED> map /v

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Dba:0x00800001

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

Data File Header

struct kcvfh, 676 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

word 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

ub4 tailchk @8188

A key question here is, what areas do we need to modify? This requires you to be relatively familiar with the structure of the datafile header. dbsanke wrote an article a long time ago, you can refer to it.

++++++ The first place to modify: rdba_kcbh

BBED> p kcvfhbfh

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 0x01000001

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 0x59b2

ub2 spare3_kcbh @18 0x0000

Here is 0×0100001, which means file 4 block 1, and we want to change it to the correct value: file 2 block 1. The block number afterward remains unchanged, that is, it should be 0×00800001

BBED> modify /x 01008000 offset 4

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 4 to 515 Dba:0x00800001

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

01008000 00000000 00000104 b2590000 00000000 0005200a 294d0a93 524f4745

52000000 db210000 60950000 00200000 04000300 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

b0220000 00000000 cb3eb32a 8ebafc2f d4a75c00 00000000 00000000 00000000

00000000 00000000 8b040000 d7b8fc2f 8a040000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 04000000 05005553 45525300 00000000 00000000 00000000

00000000 00000000 00000000 04000000 00000000 00000000 1d41672f 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 e8b8fc2f

f1a65c00 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

c6bc5d00 00000000 24aa0830 01000000 03000000 29610000 10000000 02000000

<32 bytes per line>

++++++ The second modification place: kccfhfsz is the file size

BBED> p kcvfhhdr

struct kcvfhhdr, 76 bytes @20

ub4 kccfhswv @20 0x00000000

ub4 kccfhcvn @24 0x0a200500

ub4 kccfhdbi @28 0x930a4d29

text kccfhdbn[0] @32 R

text kccfhdbn[1] @33 O

text kccfhdbn[2] @34 G

text kccfhdbn[3] @35 E

text kccfhdbn[4] @36 R

text kccfhdbn[5] @37

text kccfhdbn[6] @38

text kccfhdbn[7] @39

ub4 kccfhcsq @40 0x000021db

ub4 kccfhfsz @44 0x00009560

s_blkz kccfhbsz @48 0x00

ub2 kccfhfno @52 0x0004

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

.......

First, you can view the actual size of the data file from os, as follows:

[ora10g@killdb roger]$ ls -ltr

-rw-r—– 1 ora10g oinstall 10493952 Jan 28 06:31

However, one thing to note is that the size of the dbfile should be minus the actual size you see on the operating system, because there is also an os block header.

BBED> modify /x 00050000 offset 44

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 44 to 555 Dba:0x00800001

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

00050000 00200000 04000300 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 b0220000 00000000

cb3eb32a 8ebafc2f d4a75c00 00000000 00000000 00000000 00000000 00000000

8b040000 d7b8fc2f 8a040000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

04000000 05005553 45525300 00000000 00000000 00000000 00000000 00000000

00000000 04000000 00000000 00000000 1d41672f 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 e8b8fc2f f1a65c00 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 c6bc5d00 00000000

24aa0830 01000000 03000000 29610000 10000000 02000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

++++++ The third place to modify: kccfhfno datafile file number

BBED> modify /x 02 offset 52

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 52 to 563 Dba:0x00800001

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

02000300 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 b0220000 00000000 cb3eb32a 8ebafc2f

d4a75c00 00000000 00000000 00000000 00000000 00000000 8b040000 d7b8fc2f

8a040000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 04000000 05005553

45525300 00000000 00000000 00000000 00000000 00000000 00000000 04000000

00000000 00000000 1d41672f 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 e8b8fc2f f1a65c00 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 c6bc5d00 00000000 24aa0830 01000000

03000000 29610000 10000000 02000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

++++++ The 4th modification place: kscnbas v$datafile.create_change#

BBED> p kcvfhcrs

struct kcvfhcrs, 8 bytes @100

ub4 kscnbas @100 0x000022b0

ub2 kscnwrp @104 0x0000

BBED> modify /x 0def59 offset 100

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 100 to 109 Dba:0x00800001

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

0def5900 00000000 cb3e

<32 bytes per line>

++++++++ The fifth modification: kcvfhcrt means v$datafile.create_time

BBED> p kcvfhcrt

ub4 kcvfhcrt @108 0x2ab33ecb

At this time, you can directly query the database through v$datafile, as follows:

SQL> set lines 120

SQL> col creation_time_file for 999999999999999

SQL> col creation_name_scn for 999999999999999

SQL> select file#,to_char(creation_time,'yyyy-mm-dd hh24:mi:ss') creation_time_file,

2 (to_char(creation_time,'yyyy')-1988)*12*31*24*3600+

3 (to_char(creation_time,'mm')-1)*31*24*3600

4 +(to_char(creation_time,'dd')-1)*24*3600

5 +to_char(creation_time,'hh24')*3600

6 +to_char(creation_time,'mi')*60

7 +to_char(creation_time,'ss') creation_name_scn

8 from v$datafile order by 1;

FILE# CREATION_TIME_FILE CREATION_NAME_SCN

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

1 2010-04-15 13:14:44 716390084

2 2012-12-21 05:28:14 802589294

3 2010-04-15 13:14:49 716390089

4 2010-04-15 13:14:51 716390091

6 2012-11-20 08:32:57 799835577

8 2012-02-13 06:11:26 775116686

6 rows selected.

Or you can dump the controlfile directly and get that information from the trace.

Modified to the following:

BBED> modify /x 6e8ad62f offset 108

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 108 to 127 Dba:0x00800001

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

6e8ad62f 8ebafc2f d4a75c00 00000000 l n..Fox/Mandarin\.....

00000000 l ....

<16 bytes per line>

++++++++ The 6th modification: kcvfhtsn represents tablespace number v$#

BBED> p kcvfhtsn

word kcvfhtsn @332 4

Query the result through v$datafile:

SQL> select file#,ts# from v$datafile order by 1;

FILE# TS#

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

1 0

2 6

3 2

4 4

6 5

8 9

6 rows selected.

SQL>

Modified to:

BBED> modify /x 06 offset 332

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 332 to 341 Dba:0x00800001

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

06000000 05005553 4552

<32 bytes per line>

++++++++ The 7th modification place: kcvfhrfn v$# is the relative file number

BBED> p kcvfhrfn

ub4 kcvfhrfn @368 0x00000004

BBED> modify /x 02 offset 368

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 368 to 377 Dba:0x00800001

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

02000000 00000000 0000

<32 bytes per line>

++++++++++ The 8th place to modify: kcvfhtnm tablespace name, namely v$

BBED> p kcvfhtnm

text kcvfhtnm[0] @338 U

text kcvfhtnm[1] @339 S

text kcvfhtnm[2] @340 E

text kcvfhtnm[3] @341 R

text kcvfhtnm[4] @342 S

text kcvfhtnm[5] @343

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

BBED> d /v offset 338

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 338 to 347 Dba:0x00800001

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

55534552 53000000 0000 l USERS.....

<16 bytes per line>

BBED>

We only need to know the tablespace name and convert it:

SQL> select name from v$tablespace where ts#=6;

NAME

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

ROGER

SQL> select dump('ROGER',16) from dual;

DUMP('ROGER',16)

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

Typ=96 Len=5: 52,4f,47,45,52

SQL> select dump('USERS',16) from dual;

DUMP('USERS',16)

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

Typ=96 Len=5: 55,53,45,52,53

Modified to:

BBED> modify /x 524f4745

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 338 to 347 Dba:0x00800001

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

524f4745 53000000 0000

<32 bytes per line>

BBED> modify /x 52 342

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 342 to 351 Dba:0x00800001

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

52000000 00000000 0000

<32 bytes per line>

BBED>

BBED> sum apply

Check value for File 2, Block 1:

current = 0x15bb, required = 0x15bb

Here we add that if your tablespace name does not match the actual situation, you may also need to modify kcvfhtln to represent the length. I am ROGER here, which is 5.

Finally, let's try:

SQL> startup mount

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed SIZE 1272600 bytes

Variable SIZE 146801896 bytes

DATABASE Buffers 16777216 bytes

Redo Buffers 2920448 bytes

DATABASE mounted.

SQL> ALTER DATABASE OPEN;

ALTER DATABASE OPEN

ERROR at line 1:

ORA-01122: DATABASE file 2 failed verification CHECK

ORA-01110: DATA file 2: '/home/ora10g/oradata/roger/'

ORA-01210: DATA file header IS media corrupt

It seems that there is something wrong, let's query the v$datafile to see the information:

SQL> SELECT file#,rfile#,CREATION_CHANGE#,CHECKPOINT_CHANGE# ,UNRECOVERABLE_CHANGE#,LAST_CHANGE#,OFFLINE_CHANGE#

2 FROM v$datafile ORDER BY 1;

FILE# RFILE# CREATION_CHANGE# CHECKPOINT_CHANGE# UNRECOVERABLE_CHANGE# LAST_CHANGE# OFFLINE_CHANGE#

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

1 1 8 6143174 0 6143174 6072275

2 2 5893901 6142083 0 6142083 6072275

3 3 5796 6143174 0 6143174 6072275

4 4 8880 6143174 0 6143174 6072275

6 6 5608840 6143174 0 6143174 6072275

8 8 2387501 6143174 0 6143174 6072275

6 ROWS selected.

You can see that the checkpoint information is inconsistent, because I opened it once in the beginning to demonstrate the simulation.

The actual scn of datafile 2 currently does not match the actual:

BBED> set file 2 block 1

FILE# 2

BLOCK# 1

BBED> p kcvfhckp

struct kcvfhckp, 36 bytes @484

struct kcvcpscn, 8 bytes @484

ub4 kscnbas

ub2 kscnwrp @488 0x0000

ub4 kcvcptim

ub2 kcvcpthr @496 0x0001

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

ub4 kcrbaseq @500 0x00000003

ub4 kcrbabno @504 0x00006129

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

However, what is the actual situation of our datafile 2? Let's check v$datafile to confirm:

SQL> select file#,to_char(CHECKPOINT_TIME,'yyyy-mm-dd hh24:mi:ss') CHECKPOINT_TIME_file,

2 (to_char(CHECKPOINT_TIME,'yyyy')-1988)*12*31*24*3600+

3 (to_char(CHECKPOINT_TIME,'mm')-1)*31*24*3600

4 +(to_char(CHECKPOINT_TIME,'dd')-1)*24*3600

5 +to_char(CHECKPOINT_TIME,'hh24')*3600

6 +to_char(CHECKPOINT_TIME,'mi')*60

7 +to_char(CHECKPOINT_TIME,'ss') CHECKPOINT_TIME_scn

8 from v$datafile order by 1;

FILE# CHECKPOINT_TIME_FIL CHECKPOINT_TIME_SCN

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

1 2013-01-28 05:56:52 805874212

2 2013-01-28 05:22:07 805872127

3 2013-01-28 05:56:52 805874212

4 2013-01-28 05:56:52 805874212

6 2013-01-28 05:56:52 805874212

8 2013-01-28 05:56:52 805874212

6 rows selected.

We can see that checkpoint scn and time are not correct, so we need to modify it:

BBED> modify /x 83b85d offset 484

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 484 to 493 Dba:0x00800001

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

83b85d00 00000000 24aa

<32 bytes per line>

BED> d /v offset 492

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 492 to 501 Dba:0x00800001

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

24aa0830 01000000 0300 l $0......

<16 bytes per line>

BBED> set file 2 block 1 offset 492

FILE# 2

BLOCK# 1

OFFSET 492

BBED> modify /x ffa1

File: /home/ora10g/oradata/roger/ (2)

Block: 1 Offsets: 492 to 501 Dba:0x00800001

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

ffa10830 01000000 0300

<32 bytes per line>

BBED> sum apply

Check value for File 2, Block 1:

current = 0xb0ee, required = 0xb0ee

After the modification is completed, we can check through dbv to see if the file header modification is correct, as follows:

[ora10g@killdb roger]$ dbv file=/home/ora10g/oradata/roger/ start=1 end=2

DBVERIFY: Release 10.2.0.5.0 - Production on Mon Jan 28 08:45:51 2013

DBVERIFY - Verification starting : FILE = /home/ora10g/oradata/roger/

DBVERIFY - Verification complete

Total Pages Examined : 2

Total Pages Processed (Data) : 0

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing (Index): 0

Total Pages Processed (Other): 2

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 0

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 6051499 (0.6051499)

Finally, let’s open the database again, as follows:

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01122: database file 2 failed verification check

ORA-01110: data file 2: '/home/ora10g/oradata/roger/'

ORA-01207: file is more recent than control file - old control file

SQL> recover datafile 2;

ORA-00283: recovery session canceled due to errors

ORA-01122: database file 2 failed verification check

ORA-01110: data file 2: '/home/ora10g/oradata/roger/'

ORA-01207: file is more recent than control file - old control file

When you encounter the process, don’t worry. Let’s take a look at what this error means? From a literal meaning, it means that the information of changing the datafile may be newer than some information in the control file. This is possible, because I first opened the file after I offline it, and then modified the file header information, and then referred to other datafile header blocks, so the information of file 2 may be newer than the previous information.

Since that's the case, let's rebuild the controlhttp://, and note that you should use the norestlogs method to create:

SQL> ALTER DATABASE backup controlfile TO trace;

DATABASE altered.

SQL> shutdown immediate

ORA-01109: DATABASE NOT OPEN

DATABASE dismounted.

ORACLE instance shut down.

SQL> STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "ROGER" NORESETLOGS ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 2 '/home/ora10g/oradata/roger/' SIZE 50M,

GROUP 3 '/home/ora10g/oradata/roger/' SIZE 50M

-- STANDBY LOGFILE

DATAFILE

'/home/ora10g/oradata/roger/',

'/home/ora10g/oradata/roger/undotbs2_01.dbf',

'/home/ora10g/oradata/roger/sqlt_01.dbf'

CHARACTER SET ZHS16GBK

;ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed SIZE 1272600 bytes

Variable SIZE 146801896 bytes

DATABASE Buffers 16777216 bytes

Redo Buffers 2920448 bytes

SQL> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Control file created.

SQL> ALTER DATABASE OPEN;

ALTER DATABASE OPEN

ERROR at line 1:

ORA-01113: file 2 needs media recovery IF it was restored FROM backup, OR END BACKUP IF it was NOT

ORA-01110: DATA file 2: '/home/ora10g/oradata/roger/'

Judging from the above prompts, it is normal. At least datafile 2 can be recognized normally, and media recovery is required.

SQL> recover datafile 2;

Media recovery complete.

SQL> SELECT MAX(checkpoint_change#) FROM v$datafile;

MAX(CHECKPOINT_CHANGE#)

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

6143174

SQL> SELECT MAX(checkpoint_change#) FROM v$datafile_header;

MAX(CHECKPOINT_CHANGE#)

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

6143174

SQL> ALTER DATABASE OPEN;

DATABASE altered.

SQL> ----- Finally, the database was successfully opened.

It's over here. I don't think this is difficult. It may be just to understand the structure of the file header and understand the meaning of relevant information. Finally, let's give a simple summary. In case of file header corruption, the following content may be needed in the recovery situation:

1. rdba_kcbh (offset 4) Even if the rdba address of the file header block

2. kccfhfsz (offset 44) is the file size

3. kccfhfno (offset 52) that is the datafile file number

4. kscnbas (offset 100) i.e. v$datafile.create_change#

5. kcvfhcrt (offset 108) that is v$datafile.create_time

6. kcvfhtsn (offset 332) means v$#, indicating the tablespace number

7. kcvfhrfn (offset 368) means v$#, which represents the relative file number

8. kcvfhtnm (offset 338) that is, v$, representing the tablespace name (depending on the actual situation, it may also be necessary to modify kcvfhtln, representing the tablespace name character length)

9. kscnbas (offset 484) i.e. checkpoint scn

(offset 492) that is last checkpoint time.

Of course, this summary is not comprehensive. There may be some other things that need to be modified in many cases. In addition, if it is a system datafile, it will also be different. For example, the bootstrap$ object in the oracle database is stored in file 1 block 337. In the first datafile header in the system table space, there will be a root rdba address that points to the bootstrap address. In the 11gR2 version, the address becomes file 1 block 521 (different versions may vary).

--------------------------------------ORACLE-DBA----------------------------------------

The most authoritative and professional Oracle case resources summary [Case] Oracle error ORA-01210 Repair method for datafile header block damage

Oracle can be placed in the first file number, [Case] ​​Oracle error ORA-01210 Repair method for corruption of datafile header block...

Oracle can be placed in the first file number, [Case] Oracle error ORA-01210 Repair method for corruption of datafile header block...