When is corruption not really corruption ?

When is corruption not really corruption ?

Post by Alan Moor » Thu, 13 Jun 2002 20:12:52

Dear All,

If anyone else has encountered this odd behaviour with dbverify - I'd love
to hear from you!

We have a 7.3.4 database running on Solaris. Recently, we ran dbverify
against all the files - and got the rather worrying news that some blocks
were corrupt in system01.dbf. However, interrogation of these blocks reveals
that they are in fact the old Oracle v6 CACHE blocks (the CACHE blocks in
your system tablespace are simply a bootstrap marker telling Oracle where to
stop reading the first system file on startup).

The cache can be idenitified by running this SQL (the segment name will
simply be it's starting block address):
select segment_name from dba_segments where segment_type = 'CACHE' and owner
= 'SYS'

It seems that when you upgrade a database using an Oracle migration tool,
this little marker is copied in the system tablespace to a higher address
(seems reasonable - more startup info needing read in higher Oracle
releases). However we're suspicious that it's just the V7.3.4 dbverify
utility can't handle the old V6 cache blocks properly and therefore the
'corruption' message is bogus.  Oracle Worlwide support are telling us to
export/import (very inconvenient and the database is working fine) and that
noone else seems to have reported this (although that doesn't mean it isn't
a bug!).

Does anyone out there have a 7.3.4 database on Solaris which has been
upgraded from v6 using a migrate tool - and can therefore spend a couple of
minutes trying this?

Thanks to anyone out there who can spare the time!

Alan Moore
Oracle DBA
Information & Communication Technology
Glasgow City Council


1. Now I'm really tired of Database corruption

I have used JET 3.51 very successfully - in stand-alone systems. But when it
comes to systems used vigourously over a network (POS being and example,
where you have over 5+ PCs updating stock systems etc on a File Server), I
have found ACcess Databses a very poor solution, and do not wish to move to
SQL Server. We were using Clipper Dbs previously on a DOS-based system, and
things were pretty stable. I wonder why MS does not solve this problem


(I have applied all the fixes recommended by MS on the NT server, my Cables
are good, my HUbs are of good quality, NICs are 3COM 10/100, my Dbs and
Recordset are closed properly and set to nothing etc etc...God knows what
I've not done...I serioudly need a GOOD alternative.)

2. Informix 4GL Position, Newport Beach, CA

3. where EXISTS / NOT EXISTS do not work (I am really pannic)

4. PDXWIN4.5 -> DDE -> ??WORD6.0

5. Help!!!! .val file corruption or not found

6. Incremental Search (as in VB Help)

7. Undetected corruption?

8. ado command output to ado stream


10. index corruption

11. SQL 6.5SP5a Memo Field Corruption

12. IDENTITY: Possible cause of corruption?

13. Table Corruption