Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Help with corrupt block

Re: Help with corrupt block

From: Richard Foote <richard.foote_at_bigpond.com>
Date: Wed, 20 Nov 2002 22:34:20 +1000
Message-ID: <8dKC9.80496$g9.226680@newsfeeds.bigpond.com>


"Alistair Thomson" <thomson_alistair_at_no.spam.yahoo.co.uk> wrote in message news:arfoc4$hc3$1$8302bc10_at_news.demon.co.uk...
> Hi
>
> Oracle 8.1.7.0.0 EE
> NT 4 service pack 6e
>
> I have some very large partitioned tables. When trying to delete some
> records I was getting the following trace files and on two occassions the
> server crashed! Nothing was showing in the alert log.
>
> I've searched through metalink but can't find anything of much use!
>
> The trace file contains information as shown below:
>
> *** SESSION ID:(14.37185) 2002-10-16 06:00:34.078
> ***
> Corrupt block relative dba: 0x114042e3 (file 69, block 17123)
> Bad header found during buffer read
> Data in bad block -
> type: 6 format: 2 rdba: 0x114042db
> last change scn: 0x0000.54f4cd23 seq: 0x1 flg: 0x02
> consistency value in tail: 0xcd230601
> check value in block header: 0x0, block checksum disabled
> spare1: 0x0, spare2: 0x0, spare3: 0x0
> ***
> Reread of rdba: 0x114042e3 (file 69, block 17123) found valid data
> ***
> Corrupt block relative dba: 0x114101fa (file 69, block 66042)
> Bad header found during buffer read
> Data in bad block -
> type: 6 format: 2 rdba: 0x114101f2
> last change scn: 0x0000.557786e1 seq: 0x1 flg: 0x02
> consistency value in tail: 0x86e10601
> check value in block header: 0x0, block checksum disabled
> spare1: 0x0, spare2: 0x0, spare3: 0x0
> ***
> Reread of rdba: 0x114101fa (file 69, block 66042) found valid data
>
>
> Any advice about what's going wrong here or how to fix it would be
> appreciated.

Hi Alistair

Oracle doesn't like a couple of blocks in file 69 (which coincidently, just happens to be one of my favourite numbers ;)

My recommendation would be to restore the latest backup of file 69 and recover the database (assuming you're running your database in archivelog mode). Then check to see if everything is now hunky dory (via dbf).

If not and if prior backups are of no use either in that your backups also contain the corruption then ring back and we'll try plan B.

Cheers

Richard

>
> Thanks
>
> Alistair
>
>
Received on Wed Nov 20 2002 - 06:34:20 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US