on 07-16-2011 9:04 AM
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.