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
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
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!
Information & Communication Technology
Glasgow City Council