When is corruption not really corruption ?

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
alan.moore_at_it.glasgow.gov.uk Received on Wed Jun 12 2002 - 06:12:52 CDT