Assert Failed: Page Check Error on 7.24.UC5

Any body have experience with page check errors? I have had several page check errors in the past several weeks and would like some insight into what may be causing the problem. The page check errors do not occur on just one table, but seem to be random. I would like an explanation of what the check is comparing (memory and disk pages?) and why they may not be in sync. We are running IDS 7.24.UC5 on Solaris 2.6 with veritas 2.5 here is an example: 10:59:46 Checkpoint Completed: duration was 1 seconds. 11:00:29 Assert Failed: Page Check Error in phposition:isposition:bad page 11:00:29 Who: Session(75274, XXXXXXXX@MACHINE, 27306, 227242944) Thread(75400, sqlexec, d058ad8, 14) 11:00:29 Results: Possibleinconsistencies in 'ameritrade:"XXXXXXX".TABLE' 11:00:29 Action: Run 'oncheck -cDI ameritrade:"XXXXXX".TABLE' 11:00:29 See Also: /dump/af.26888d9c, shmem.26888d9c.0, /opt/informix/core 11:00:39 mt.c, line 10176, thread 125, proc id 24374, Unexpected virtual processor termination, pid = 24403, exit = 0xb . 11:00:39 Assert Failed: Unexpected virtual processor termination, pid = 24403, exit = 0xb 11:00:39 Who: Session(2, informix@, 0, 0) Thread(125, kaio, 0, 1) 11:00:39Results: Fatal Internal Error requires system shutdown 11:00:39 Action: Restart OnLine 11:00:39 See Also: /dump/af.7d8da6, shmem.7d8da6.0, /opt/informix/core 11:00:47 The Master Daemon Died 11:00:47 invoke_alarm(): /bin/sh -c '/opt/informix/etc/no_log.sh 5 6 "Internal Subsystem failure: ' MT'" "The Master Daemon Died" ' 11:00:47 invoke_alarm(): mt_exec failed, status -1, errno 0 11:00:47 PANIC: Attempting to bring system down top of af file: 11:00:29 bfcheck: bad page: pg_stamp cd6588eb != PG_STAMP2 d63289dbbuffer header 0b2e184c: 00000000 00000000 00000000 0b30dd48 ........ .....0.H 0b2e185c: 0b2afae0 0a00c694 0b34c9d0 00020000 .*...... .4...... 0b2e186c: 00400000 01b07435 0b866800 00000000 .@....t5 ..h..... 0b2e187c: 00000000 00010010 d633a36d ........ .3.m page 0b866800: 01b07435 cd6588eb 00012001 05630295 ..t5.e.. .. ..c.. 0b866810: 00000000 00000000 41435449 4f4e3a20 ........ ACTION: 0b866820: 20202020 20204649 4c4c2035 32363037 FI LL 52607 0b866830: 34313320 20202020 20202020 20202020 413 0b866840: 20202020 20202020 2020494e 53545255 INSTRU 0b866850: 4d454e54 3a202020 20202020 20202020 MENT: Thanks! Jim Neugebauer jneugebauer@ameritrade.com Informix/Oracle DBA Systems Engineering Group Ameritrade Holding Corp. 4211 South 102nd St. Omaha, NE 68127-1031 phone 402.597.5623 fax 402.5977799 -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

jneugeba@my-dejanews.com wrote: > > Any body have experience with page check errors? I have had several page > check errors in the past several weeks and would like some insight into what > may be causing the problem. The page check errors do not occur on just one > table, but seem to be random. I would like an explanation of what the check > is comparing (memory and disk pages?) and why they may not be in sync. We > are running IDS 7.24.UC5 on Solaris 2.6 with veritas 2.5 > > here is an example: 10:59:46 Checkpoint Completed: duration was 1 seconds. [SNIP] > 11:00:29 bfcheck: bad page: pg_stamp cd6588eb != PG_STAMP2 d63289db [SNIP]It means that the page has either become corrupted or was only partially written. The reported error is that the timestamp in the page header does not match that in the page trailer. Veritas you say? Are you using RAID 5? I suspect my favorite: partial media failure! Check your system logs for reports of failure to allocate sector remaping. It may be that one or more drives is becoming flaky and the SCSI controller has run out of the sectors it reserved to use for silently replacing bad sectors. The drive is returning garbage from those sectors and the RAID 5 parity block is now trash! If this is the case, don't say I did not warn you all, cause I did loudly for two years now. Art S. Kagel RAID10 RAID10 RAID10 RAID10 RAID10 RAID10 RAID10 RAID10 RAID10