cancel
Showing results for 
Search instead for 
Did you mean: 

Full offline + redologBackup error through DB13 with BRBACKUP VERIFY OPTION

Former Member
0 Kudos

Dear All,

I'm facing problem in backup, log is as under

BR0278W Command output of '/oracle/PRD/102_64/bin/dbv file=/oracle/PRD/sapbackup/begicwjp/sr3.data12 blocksize=8192':

DBVERIFY: Release 10.2.0.4.0 - Production on Thu Jul 14 21:06:43 2011

Copyright (c) 1982, 2007, Oracle. All rights reserved.

DBVERIFY - Verification starting : FILE = /oracle/PRD/sapbackup/begicwjp/sr3.data12

Block Checking: DBA = 63054525, Block Type = KTB-managed data block

data header at 0x58ec64

kdbchk: the amount of space used is not equal to block size

used=253 fsc=227 avsp=7606 dtl=8088

Page 139965 failed with check code 6110

DBVERIFY - Verification complete

Total Pages Examined : 256000

Total Pages Processed (Data) : 62468

Total Pages Failing (Data) : 1

Total Pages Processed (Index): 37748

Total Pages Failing (Index): 0

Total Pages Processed (Other): 37858

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 117926

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 57538115 (0.57538115)

BR0398E DBVERIFY detected corrupted blocks in /oracle/PRD/sapdata3/sr3_12/sr3.data12

Please help me how to resolve this issue

Regards,

Arshad.

Accepted Solutions (0)

Answers (1)

Answers (1)

volker_borowski2
Active Contributor
0 Kudos

Not good!

Sapnet search with: "kdbchk: the amount of space used is not equal to block size"

Delivers only two hits.

Check Note 1368640, and apply the fix.

This should prevent further damage.

There are mentioned various checks, to narrow down the real problem.

Unfortunately, due to this bug, the corruption seems also to be in the redologs, so a media recovery without loss of work will not help you, so I'd try to track down the affected object first. Follow note 365481 to find the related object, may be you are lucky, that it can be repaired or rebuilt.

Could not do damage to log a call for that, in case development has special tools to fix this.

Volker

Former Member
0 Kudos

Dear Volker,

Thanks for your response, I didn't find patch 7662491 which is mentioned in note 1368640 this to fix issue, however i have applied latest patch released for oracle (SAP_102048_201107_SOLX8664), the problem is still there, i have also taken export and there is no error in export.

Regards,

Arshad.

volker_borowski2
Active Contributor
0 Kudos

Check Note 1368640, and apply the fix.

This should prevent further damage.

As said,

this will not fix your problem, it will avoid additional problems to arise.

If you can do an export of the table this is at least promising.

Try to import the table to a sandbox system, may be utilizing a manual

import with a change of the schema owner so that you do not destroy your sandbox.

steps required:

create new tablespace PSAPDUMMY on sandbox

create new DB user IMPCHECK on sandbox

create the table in the new tablespace for schema IMPCHECK exactly as it exists in prod.

use native "imp" with FROMUSER= TOUSER=IMPCHECK to import the table to the sandbox.

Run dbv on the PSAPDUMMY

If you get no corruption, you might get lucky with an export/import approach for production.

For prod I'd process like:

- stop sap

- export table

- rename table and indexes to dummy names

- import the table

- recheck dbv

- start sap

- check application

- if everything is fine (and only then), drop the renamed table

Volker