Re: Bad pagenum

In <1j26giINNm4u@emory.mathcs.emory.edu> anasaz!qip.naomi@enuucp.eas.asu.edu (Naomi Walker) writes: >I have the following entry in the Informix error log, from an AST 486, >runing Interactive Unix 3.2-2, 4.1.UD2 Online, and 4.1.UD1 ESQL/C. >During some nightly file processing, we appeared to have tripped over >a page number that is invalid (page 75208 of 8628 pages). >My gut reaction is to run some tbcheck (maybe -cd or -cI), with Informix >in quiescent/fix-it mode. Since this is a production customer, and that >means downtime, i'm hesitating. Does this seem like the appropriate move >at this point? It is not reasonable to tbunload/tbload the database back, >as it is very large (unless it was an emergency, and we've have too many of >those already). > >Furthermore, does anyone have any idea what causes this? > You don't need to go Quiescent to check consistency with tbcheck, only to repair indexes. If you only have one bad pagenum do some investigation in Online mode first. You don't say whether you have already established: The app process which has encountered the problem? The database which contains the corruption? The table which contains the problem? Is the problem reproducable at will? If you only have one bad page then there can only be one table affected, so unloading/reloading a whole database would be overkill (unless the one bad page happens to be a critical system one). What you need to do is establish which page contains the bad page reference. The 232 bytes which were dumped to the message log contain (I believe) the offending entry from the tablespace table in shared memory. Unfortunately I don't know what offset to use to find the tablespace number. I would suggest setting the DUMPSHMEM environment variable (I believe this works with 4.10 even though it may not be documented) to get a dump of shared memory when the problem occurs. You can then use tbstat -tub shmem.<pid>.1 (where <pid> is the pid reported by the ptmap failure message) to identify the problem page. Having identified it, whether you can do anything about it will depend on what kind of page it is! As for ideas on causes, I'll reserve judgement until I know what kind of page we're talking about. -- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk