DBVerify? I think not.

Waaay back when I was younger and worked in Oracle Support we were competing fiercely (and with any weapon) against Informix, Ingres and Sybase.

Especially Sybase was the great enemy, and we used to laugh a lot about their DBVerify facility, which their Support organisation required their users to run before they called Sybase Support.

Since running DBVerify could take more than 24 hours if the Sybase database was sufficiently large, it was obvious to any idiot that it didn't make sense. And why did they need such a facility? Didn't they have faith in the DBMS' ability to keep blocks out of corruption charges?

DBVerify was mentioned in Oracle competitive marketing materials as one good argument for not choosing Sybase.

Then Oracle copied it, including its name. Incredible. And to this date it is - if possible - even more useless than its Sybase forefather.

Yesterday I had a conference call with a large customer who had been down with their CRM system because DBVerify told them they had numerous corrupted blocks in their database after a restore and some reorg stuff.

I simply told them to ignore this bug in dbv (newed blocks are flagged as corrupted) and only think in terms of corrupted blocks if they ever see an ORA-1578 in their alert log.

They didn't quite believe me (it's an official Oracle utility, after all, this dbv nonsense), so I had to explain all sorts of stuff about block internals, checksums, hard and soft corruptions, and what have you.

In the end I promised them that I'd give them all the consulting help they'd need to fix corrupted blocks if they had any - and to just put the system back in production.

But imagine: A large company, down for five days because of the age-old bug/issue with dbverify calling blocks corrupted when they're not - and Oracle Support (and other involved parties) not knowing that it's just nonsense because they might not be aware of its history.

Spread the word: Stop using the useless piece of c... known as dbverify :-))).