Re: Error in Online log: bfcheck

In article <GIiY5BAcYjYyEwBU@misslink.demon.co.uk>, Simon Ellison-Bunce <simonb@misslink.demon.co.uk> writes >In article <z6z8QEA39tVyEwsT@smooth1.demon.co.uk>, David Williams ><djw@smooth1.demon.co.uk> writes >>In article <FzUO7BAtD6UyEwTf@misslink.demon.co.uk>, Simon Ellison-Bunce >><simonb@misslink.demon.co.uk> writes >>>A few days ago we started getting some error messages in our Online log >>>file that we've not seen before. They don't look good, but everything is >>>still running (so far!). Can anyone shed light on what this means? >>> >>>bfcheck: bad page: pg_flags 0 != type 2, userp = 8040210c, pid = 9192, >>>uid = 357 >>><Then some dump data> >>>-- WARNING: Fail Consistency Check -- pthdrpage:ptalloc:bad partn page - >>>- pid = 9192 user=357 us=8040210c >>> >>>This is Online v5 on SCO 3.2v4.2. >>> >>>We have reloaded the database after reinitialising the disk, but the >>>errors are still occuring. >>> >> >> You have a corrupt database. It sounds like something is overlapping >>the database E.g. a filesystem overlapping the same area of disk that >>Online is using. >> >> Run the following command to check you database is now OK:- >> >> tbcheck -cr >> tbcheck -ce >> tbcheck -cc <database name> >> tbcheck -cID <database name> > >I'm virtually certain we don't have a problem with disk allocation. > >tbcheck -cr, tbcheck -ce and tbcheck -cc don't give any sign of anything >wrong. > >If I run tbcheck -cID <dbname> then tbcheck dies before completing with >an OS Memory fault error, and a Process Terminated Abnormally message is >written to the Online log. > >However, if I run tbcheck against each table in the database >individually, then it runs happily and no problems are reported. > >Any more ideas? Sounds like the basic disk structure in online are ok (reserved pages, extent allocation info, system catalogs). However the oncheck -cID on the whole database indicates a corruption at the overall database level. The fact that individual tables tbcheck Ok indicates that they are OK. Again leading to the conclusion that corruption is at the database level rather than the table level. Informix would PROBABLY (I'm not them so I won't speak for them but something similar to this happen to me recently and this is the advice I would give) tell you to either a) Dbexport the database, check that produces no errors then drop the database and reimport it or b) Restore from a known good level-0 archive and start applying logical logs to restore your database. Personally I'd try a) and if it all goes OK I would re run on the tbcheck's. PS Do a full machine backup + level 0 archive before hand...I did warn you!!! :-> -- David Williams