Informix goes down after select

Hi all, if i do a simple select on a table in my database the whole Informix-Server(IDS 7.30 on SCO Open Server 3.5.2) is going down. the error message is : 17:33:51 Assert Failed: No Exception Handler 17:33:51 Informix Dynamic Server Version 7.30.UC2 17:33:51 Who: Session(16, informix@fj1, 1461, 0) Thread(41, sqlexec, 0, 1) File: mtex.c Line: 314 17:33:51 Results: Exception Caught. Type: MT_EX_OS, Context: fpe 17:33:51 Action: Please notify Informix Technical Support. 17:33:54 See Also: /tmp/af.29966e, shmem.29966e.0 17:34:09 mtex.c, line 314, thread 41, proc id 1446, No Exception Handler. 17:34:09 PANIC: Attempting to bring system down 17:35:08 Requested shared memory segment size rounded from 8000KB to 8192KB it's only on the one table, wich can not be dropped, renamed or altered, because the server goes down. Additionally i can't drop or create any index on my table. The only thing, i can do is : - unload the other tables - drop the whole database - recreate the database and tables and load them into , but it's the 3th time, that it occurs (on the same table, wich is not used to often). ---------------------------------------------------------------------------- --------------------------------------------- Is there anybody, who has a solution (or any idea) for my problem ????????????? ---------------------------------------------------------------------------- --------------------------------------------- Sven P.S: I've already called my technical support, but they don't have any solution.

What happens when you run oncheck -pt dbname:tabname?? John Carlson Informix DBA WHSmith USA S. Radtke wrote: > > Hi all, > > if i do a simple select on a table in my database the whole > Informix-Server(IDS 7.30 on SCO Open Server 3.5.2) is going down. > > the error message is : > > 17:33:51 Assert Failed: No Exception Handler > 17:33:51 Informix Dynamic Server Version 7.30.UC2 > 17:33:51 Who: Session(16, informix@fj1, 1461, 0) > Thread(41, sqlexec, 0, 1) > File: mtex.c Line: 314 > 17:33:51 Results: Exception Caught. Type: MT_EX_OS, Context: fpe > 17:33:51 Action: Please notify Informix Technical Support. > 17:33:54 See Also: /tmp/af.29966e, shmem.29966e.0 > 17:34:09 mtex.c, line 314, thread 41, proc id 1446, No Exception Handler. > 17:34:09 PANIC: Attempting to bring system down > 17:35:08 Requested shared memory segment size rounded from 8000KB to 8192KB> > it's only on the one table, wich can not be dropped, renamed or altered, > because the server goes down. > Additionally i can't drop or create any index on my table. > > The only thing, i can do is : > - unload the other tables > - drop the whole database > - recreate the database and tables and load them into > > , but it's the 3th time, that it occurs (on the same table, wich is not used > to often). > > ---------------------------------------------------------------------------- > --------------------------------------------- > Is there anybody, who has a solution (or any idea) for my problem > ????????????? > ---------------------------------------------------------------------------- > --------------------------------------------- > > Sven > > P.S: I've already called my technical support, but they don't have any > solution.

Hi John, here is the oncheck -pT, but this is for the table after rebuild. When i do an oncheck -cd and -ci on the table before recreated, the server goes down. At the next time the phenomenon will occurs, i'll try to get oncheck -pT ..., but i know, what will happens.. ;-) TBLspace Report for fj010k:pfrs.fi_fremd Physical Address 4035a4 Creation date 05/26/99 11:39:51 TBLspace Flags 802 Row Locking TBLspace use 4 bit bit-maps Maximum row size 376 Number of special columns 0 Number of keys 4 Number of extents 2 Current serial value 1 First extent size 8 Next extent size 8 Number of pages allocated 64 Number of pages used 58 Number of data pages 0 Number of rows 0 Partition partnum 4194880 Partition lockid 4194880 Extents Logical Page Physical Page Size 0 4036cc 8 8 4073d5 56 TBLspace Usage Report for fj010k:pfrs.fi_fremd Type Pages Empty Semi-Full Full Very-Full ---------------- ---------- ---------- ---------- ---------- ---------- Free 59 Bit-Map 1 Index 4 Data (Home) 0 ---------- Total Pages 64 Unused Space Summary Unused data slots 0 Unused bytes per data page 120 Total unused bytes in data pages 0 Home Data Page Version Summary Version Count 0 (current) 0 Index Usage Report for index fi_fremd1 on fj010k:pfrs.fi_fremd Average Average Level Total No. Keys Free Bytes ----- -------- -------- ---------- 1 1 0 2020 ----- -------- -------- ---------- Total 1 0 2020 Index Usage Report for index fre_sort on fj010k:pfrs.fi_fremd Average Average Level Total No. Keys Free Bytes ----- -------- -------- ---------- 1 1 0 2020 ----- -------- -------- ---------- Total 1 0 2020 Index Usage Report for index fremd_sort on fj010k:pfrs.fi_fremd Average Average Level Total No. Keys Free Bytes ----- -------- -------- ---------- 1 1 0 2020 ----- -------- -------- ---------- Total 1 0 2020 Index Usage Report for index fi_fremd_ind_4 on fj010k:pfrs.fi_fremd Average Average Level Total No. Keys Free Bytes ----- -------- -------- ---------- 1 1 0 2020 ----- -------- -------- ---------- Total 1 0 2020 Thank you for your reply Sven

S. Radtke wrote: > > Hi all, > > if i do a simple select on a table in my database the whole > Informix-Server(IDS 7.30 on SCO Open Server 3.5.2) is going down. > There is a bug that just bit me, bug #92189, that causes an Arithmetic Exception in 7.24UC5 and is fixed in 7.24UC7 and 7.30UC8. It is triggered by running ANY update statistics on a table with no rows (as the oncheck -pT you posted shows!) The value of nunique in the sysindexes records for the table is zero (it was NULL before the update stats were run which is why the engine runs fine for a while then suddenly it is crashing, you recently updated stats!) The current workaround, and proof that this is the problem, is to update the nunique column of the sysindexes record for ANY table that has a zero there now. Next time the engine crashes set nunique for that table's indexes to '1' after restarting the engine and you will again be able to use the table without crashing the engine. In a separate message I am posting an ESQL/C program to scan through all databases on a server and make this fix to all affected tables' sysindex records. Art S. Kagel