Re: Bage Pagenum

In article <2mpp7s$cu7@emory.mathcs.emory.edu>, naomi@anasazi.com (Naomi Walker) says: > >I have never really nailed down how exactly to read this error report. >From other clues in our system, we have pretty much figured out who is >the offending table, and rebuilt it. It appears that the 030002cc is >the partnum(tablenum) of the bad table. I understand that somehow a >page number pointed at a page number that is out of range. > >Can anyone out there help me decode the rest of the message? What causes >this (or is it just an unfortunate lining up to the moon, sun, and stars)? > >(NOTE: We are using Online 4.10, and ESQL/C 4.10 on a Pyramid MIS-ES) > >04:13:23 Logical Log 873 Backed Up >04:14:26 Checkpoint Completed >04:15:30 Checkpoint Completed >04:16:19 ptmap: bad pagenum = 35154443 -- only 247500 pages >04:16:19 ptmap failure: userp = 11002474, pid = 22217 >04:16:19 113422d8: 00000000 00000000 0000012c 00000000 ........ ...,.... ..lots of hexa-gibberish deleted... >04:16:20 -- Fail Consistency Check -- ptmap error -- pid=22217 user=30005 us=11002474 Naomi, I've seen several of these. As you know, we're running on the same platform and Informix release level. The problem is a corrupted index entry, however, I can't find any indication of *WHICH* index is corrupted in the hexa-gibberish, and Informix tech support hasn't been able to give me any documentation of the output. The 247500 pages in your output is the last valid page in the currently allocated extents. The 35154443 is the page that an index entry points to. If you can find out via ISQL or other means (knet log) which index path is being used, you can rebuild that index. The underlying data pages are OK. We have seen this problem frequently (every two months), always (so far) after a hard crash of the Pyramid while significant updating activity was taking place. I *suspect* but have no proof, and have not been able to find a smoking gun that points to a problem in Fast Recovery related to indexes and B-trees. I spent two days once on this problem walking the index B-tree by hand using tbcheck -pP and found that a second-level B-tree index pointer was bad. An entry that should point to a leaf page actually had a ROWID in it. Anybody else seen anything similar? Jim Burks jburks@promus.com Database Administrator The Promus Companies Memphis, TN 38125-8883