Re: Informix issues -- ouch!

In article <383329F6.8C7CB5C7@bellsouth.net>, Carlson@WHSmith <carlson1@bellsouth.net> writes >IDS 7.30.uc10 >HPUX 10.20 > >Just upgraded (over the weekend) to 7.30.uc10. One of my users ran a >very basic report, and brought the Informix down. The system ended up >with six assert failures within a four hour period. Called the down What are the af files/online.log entries produced? Have you tried 7.31.UC4-1?? >system group; they've analyzing the situation. I ended up regressing to >7.30.uc7. > >I reinstalled uc10 on my test system and cut my production data over. >Since then I've been able to either hang the engine up or crash it using >the same report. BTW, this report ran well under uc7. > >Are there any outstanding issues with uc10? Are there any gotchas that >I may have missed? (It's the first time I've had to regress to an older >version . . . hence the 'ouch'.) > > >Thanks in advance! > >John Carlson >Informix DBA >WHSmith USA -- David Williams

Here's the relevent portion of the online.log (quite consistent): 10:27:38 Checkpoint Completed: duration was 0 seconds. 10:29:53 Assert Failed: No ExceptionHandler 10:29:53 Informix Dynamic Server Version 7.30.UC10 10:29:53 Who: Session(20, mis_95@whsprod1, 10981, 0) Thread(49, sqlexec, 0, 1) File: mtex.c Line:314 10:29:53 Results: Exception Caught. Type: MT_EX_OS, Context:mem 10:29:53 Action: Please notify Informix Technical Support. 10:29:53 stack trace for pid 10946 written to /lawson/lawson/print/af.311b70 10:33:06 10:33:06 mtex.c, line 314, thread 49, proc id 10946, No Exception Handler. 10:33:06 PANIC: Attempting to bring systemdown Here's the stack trace: 15:56:50 Stack for thread: 49sqlexec base: 0xcfd3d018 len: 36864 pc: 0x00000000 tos: 0xcfd3f0a0 state: running vp: 3 ( 0) 0x00366574 afstack + 0x124 [/usr/informix/bin/oninit] ( 1) 0x00365e18 afhandler + 0x630 [/usr/informix/bin/oninit] ( 2) 0x0036579c afcrash_interface + 0xa4 [/usr/informix/bin/oninit] ( 3) 0x003674f4 mt_ex_throw_sig + 0x254 [/usr/informix/bin/oninit] ( 4) 0x000355a4 afsig_segv + 0x2c [/usr/informix/bin/oninit] ( 5) 0xc0141a08 _sigreturn [/usr/lib/libc.1] ( 6) 0x0004afb8 tmalloc + 0x40 [/usr/informix/bin/oninit] ( 7) 0x00119798 selec + 0x7c0 [/usr/informix/bin/oninit] ( 8) 0x00118e48 opselec + 0x3d8 [/usr/informix/bin/oninit] ( 9) 0x0011720c opfiltr + 0x51c [/usr/informix/bin/oninit] (10) 0x001173e0 opfiltr + 0x6f0 [/usr/informix/bin/oninit] (11) 0x00116650 opinit + 0x140 [/usr/informix/bin/oninit] (12) 0x00115614 sqoptim + 0x454 [/usr/informix/bin/oninit] (13) 0x001186ec cnttabs + 0x19c [/usr/informix/bin/oninit] (14) 0x00118a18 cnttabs + 0x4c8 [/usr/informix/bin/oninit] (15) 0x00117ec0 opcntab + 0x1b8 [/usr/informix/bin/oninit] (16) 0x00116dcc opfiltr + 0xdc [/usr/informix/bin/oninit] (17) 0x001173e0 opfiltr + 0x6f0 [/usr/informix/bin/oninit] (18) 0x00116650 opinit + 0x140 [/usr/informix/bin/oninit] (19) 0x00115614 sqoptim + 0x454 [/usr/informix/bin/oninit] (20) 0x00169398 sq_bind + 0x4f8 [/usr/informix/bin/oninit] (21) 0x000e7260 sqmain + 0x98 [/usr/informix/bin/oninit] (22) 0x00367a90 startup + 0xa0 [/usr/informix/bin/oninit] (23) 0x00367990 mt_swap_threads + 0xdc [/usr/informix/bin/oninit] I'd like to rey 7.31.uc4, but I'd need to verify that Lawson has certified that much of jump. (Of course, I can't install it until January 15 due to our software freeze.) Thanks in advance John Carlson Informix DBA WHSmith USA David Williams wrote: > > In article <383329F6.8C7CB5C7@bellsouth.net>, Carlson@WHSmith > <carlson1@bellsouth.net> writes > >IDS 7.30.uc10 > >HPUX 10.20 > > > >Just upgraded (over the weekend) to 7.30.uc10. One of my users ran a > >very basic report, and brought the Informix down. The system ended up > >with six assert failures within a four hour period. Called the down > What are the af files/online.log entries produced? > Have you tried 7.31.UC4-1?? > > >system group; they've analyzing the situation. I ended up regressing to > >7.30.uc7. > > > >I reinstalled uc10 on my test system and cut my production data over. > >Since then I've been able to either hang the engine up or crash it using > >the same report. BTW, this report ran well under uc7. > > > >Are there any outstanding issues with uc10? Are there any gotchas that > >I may have missed? (It's the first time I've had to regress to an older > >version . . . hence the 'ouch'.) > > > > > >Thanks in advance! > > > >John Carlson > >Informix DBA > >WHSmith USA > > -- > David Williams

In article <38341F80.E4C8DC79@bellsouth.net>, Carlson@WHSmith <carlson1@bellsouth.net> writes >Here's the relevent portion of the online.log (quite consistent): > >10:27:38 Checkpoint Completed: duration was 0 >seconds. >10:29:53 Assert Failed: No Exception>Handler >10:29:53 Informix Dynamic Server Version >7.30.UC10 >10:29:53 Who: Session(20, mis_95@whsprod1, 10981, >0) > Thread(49, sqlexec, 0, >1) > File: mtex.c Line:>314 >10:29:53 Results: Exception Caught. Type: MT_EX_OS, Context:>mem >10:29:53 Action: Please notify Informix Technical >Support. >10:29:53 stack trace for pid 10946 written to >/lawson/lawson/print/af.311b70 >10:33:06 >10:33:06 mtex.c, line 314, thread 49, proc id 10946, No Exception >Handler. >10:33:06 PANIC: Attempting to bring system>down > > >Here's the stack trace: > >15:56:50 Stack for thread: 49>sqlexec > > base: >0xcfd3d018 > len: >36864 > pc: >0x00000000 > tos: >0xcfd3f0a0 >state: >running > vp: >3 > >( 0) 0x00366574 afstack + 0x124 >[/usr/informix/bin/oninit] >( 1) 0x00365e18 afhandler + 0x630 >[/usr/informix/bin/oninit] >( 2) 0x0036579c afcrash_interface + 0xa4 >[/usr/informix/bin/oninit] >( 3) 0x003674f4 mt_ex_throw_sig + 0x254 >[/usr/informix/bin/oninit] >( 4) 0x000355a4 afsig_segv + 0x2c >[/usr/informix/bin/oninit] >( 5) 0xc0141a08 _sigreturn >[/usr/lib/libc.1] >( 6) 0x0004afb8 tmalloc + 0x40 >[/usr/informix/bin/oninit] >( 7) 0x00119798 selec + 0x7c0 >[/usr/informix/bin/oninit] >( 8) 0x00118e48 opselec + 0x3d8 >[/usr/informix/bin/oninit] >( 9) 0x0011720c opfiltr + 0x51c >[/usr/informix/bin/oninit] >(10) 0x001173e0 opfiltr + 0x6f0 >[/usr/informix/bin/oninit] >(11) 0x00116650 opinit + 0x140 >[/usr/informix/bin/oninit] >(12) 0x00115614 sqoptim + 0x454 >[/usr/informix/bin/oninit] >(13) 0x001186ec cnttabs + 0x19c >[/usr/informix/bin/oninit] >(14) 0x00118a18 cnttabs + 0x4c8 >[/usr/informix/bin/oninit] >(15) 0x00117ec0 opcntab + 0x1b8 >[/usr/informix/bin/oninit] >(16) 0x00116dcc opfiltr + 0xdc >[/usr/informix/bin/oninit] >(17) 0x001173e0 opfiltr + 0x6f0 >[/usr/informix/bin/oninit] >(18) 0x00116650 opinit + 0x140 >[/usr/informix/bin/oninit] >(19) 0x00115614 sqoptim + 0x454 sqoptim() ?? look like an optimzer bug.. espiecally with function names like opinit(),opfiltr() and opselec(). What was is the sql that this session is executing?? >[/usr/informix/bin/oninit] >(20) 0x00169398 sq_bind + 0x4f8 >[/usr/informix/bin/oninit] >(21) 0x000e7260 sqmain + 0x98 >[/usr/informix/bin/oninit] >(22) 0x00367a90 startup + 0xa0 >[/usr/informix/bin/oninit] >(23) 0x00367990 mt_swap_threads + 0xdc >[/usr/informix/bin/oninit] > >I'd like to rey 7.31.uc4, but I'd need to verify that Lawson has >certified that much of jump. (Of course, I can't install it until >January 15 due to our software freeze.) > Pity since it includes all the latest y2k patches! Overall it includes the follow y2k fixes (some of which are in earlier version but I'm not sure about 7.30.UCXX) - 29th Feb fixes - Datetime fixes - DBCENTURY 2 digit date fixes - DBCENTURY and interpretation of 2 digit datesin stored procedures + triggers as well as the fix for buffer priority aging. >Thanks in advance > >John Carlson >Informix DBA >WHSmith USA > > >David Williams wrote: >> >> In article <383329F6.8C7CB5C7@bellsouth.net>, Carlson@WHSmith >> <carlson1@bellsouth.net> writes >> >IDS 7.30.uc10 >> >HPUX 10.20 >> > >> >Just upgraded (over the weekend) to 7.30.uc10. One of my users ran a >> >very basic report, and brought the Informix down. The system ended up >> >with six assert failures within a four hour period. Called the down >> What are the af files/online.log entries produced? >> Have you tried 7.31.UC4-1?? >> >> >system group; they've analyzing the situation. I ended up regressing to >> >7.30.uc7. >> > >> >I reinstalled uc10 on my test system and cut my production data over. >> >Since then I've been able to either hang the engine up or crash it using >> >the same report. BTW, this report ran well under uc7. >> > >> >Are there any outstanding issues with uc10? Are there any gotchas that >> >I may have missed? (It's the first time I've had to regress to an older >> >version . . . hence the 'ouch'.) >> > >> > >> >Thanks in advance! >> > >> >John Carlson >> >Informix DBA >> >WHSmith USA >> >> -- >> David Williams -- David Williams

See below . . . David Williams wrote: > > In article <38341F80.E4C8DC79@bellsouth.net>, Carlson@WHSmith > <carlson1@bellsouth.net> writes > >Here's the relevent portion of the online.log (quite consistent): > > > >10:27:38 Checkpoint Completed: duration was 0 > >seconds. > >10:29:53 Assert Failed: No Exception> >Handler > >10:29:53 Informix Dynamic Server Version > >7.30.UC10 > >10:29:53 Who: Session(20, mis_95@whsprod1, 10981, > >0) > > Thread(49, sqlexec, 0, > >1) > > File: mtex.c Line:> >314 > >10:29:53 Results: Exception Caught. Type: MT_EX_OS, Context:> >mem > >10:29:53 Action: Please notify Informix Technical > >Support. > >10:29:53 stack trace for pid 10946 written to > >/lawson/lawson/print/af.311b70 > >10:33:06 > >10:33:06 mtex.c, line 314, thread 49, proc id 10946, No Exception > >Handler. > >10:33:06 PANIC: Attempting to bring system> >down > > > > > >Here's the stack trace: > > > >15:56:50 Stack for thread: 49> >sqlexec > > > > base: > >0xcfd3d018 > > len: > >36864 > > pc: > >0x00000000 > > tos: > >0xcfd3f0a0 > >state: > >running > > vp: > >3 > > > >( 0) 0x00366574 afstack + 0x124 > >[/usr/informix/bin/oninit] > >( 1) 0x00365e18 afhandler + 0x630 > >[/usr/informix/bin/oninit] > >( 2) 0x0036579c afcrash_interface + 0xa4 > >[/usr/informix/bin/oninit] > >( 3) 0x003674f4 mt_ex_throw_sig + 0x254 > >[/usr/informix/bin/oninit] > >( 4) 0x000355a4 afsig_segv + 0x2c > >[/usr/informix/bin/oninit] > >( 5) 0xc0141a08 _sigreturn > >[/usr/lib/libc.1] > >( 6) 0x0004afb8 tmalloc + 0x40 > >[/usr/informix/bin/oninit] > >( 7) 0x00119798 selec + 0x7c0 > >[/usr/informix/bin/oninit] > >( 8) 0x00118e48 opselec + 0x3d8 > >[/usr/informix/bin/oninit] > >( 9) 0x0011720c opfiltr + 0x51c > >[/usr/informix/bin/oninit] > >(10) 0x001173e0 opfiltr + 0x6f0 > >[/usr/informix/bin/oninit] > >(11) 0x00116650 opinit + 0x140 > >[/usr/informix/bin/oninit] > >(12) 0x00115614 sqoptim + 0x454 > >[/usr/informix/bin/oninit] > >(13) 0x001186ec cnttabs + 0x19c > >[/usr/informix/bin/oninit] > >(14) 0x00118a18 cnttabs + 0x4c8 > >[/usr/informix/bin/oninit] > >(15) 0x00117ec0 opcntab + 0x1b8 > >[/usr/informix/bin/oninit] > >(16) 0x00116dcc opfiltr + 0xdc > >[/usr/informix/bin/oninit] > >(17) 0x001173e0 opfiltr + 0x6f0 > >[/usr/informix/bin/oninit] > >(18) 0x00116650 opinit + 0x140 > >[/usr/informix/bin/oninit] > >(19) 0x00115614 sqoptim + 0x454 > > sqoptim() ?? look like an optimzer bug.. espiecally with function > names like opinit(),opfiltr() and opselec(). What was is the sql that > this session is executing?? > That's what I thought, too. Nothing from Tech Support on that, yet. Here's the SQL: select sum ( balance ) from sl_ledger_bal where sl_ledger_bal.company = ? and sl_ledger_bal.fiscal_year = ? and sl_ledger_bal.sl_period = 12 and sl_ledger_bal.dept_num = ? and sl_acct_num = 5 and sl_ledger_bal.store_num in ( select acct_unit from lawfin:glnames where company = ? and var_levels [ 3 , 5 ] = ? ) It wouldn't bomb or hang on just this particular SQL, but each time the program assert failed on me, the SQL was something along this line. I've tried all the possible combinations in dbaccess, with no recreations. > >[/usr/informix/bin/oninit] > >(20) 0x00169398 sq_bind + 0x4f8 > >[/usr/informix/bin/oninit] > >(21) 0x000e7260 sqmain + 0x98 > >[/usr/informix/bin/oninit] > >(22) 0x00367a90 startup + 0xa0 > >[/usr/informix/bin/oninit] > >(23) 0x00367990 mt_swap_threads + 0xdc > >[/usr/informix/bin/oninit] > > > >I'd like to rey 7.31.uc4, but I'd need to verify that Lawson has > >certified that much of jump. (Of course, I can't install it until > >January 15 due to our software freeze.) > > > Pity since it includes all the latest y2k patches! > One of the reasons that I wanted to get it in. > Overall it includes the follow y2k fixes (some of which are in > earlier version but I'm not sure about 7.30.UCXX) > > - 29th Feb fixes We're OK there! > - Datetime fixes I believe we're OK here too. What was the problem with datetimes?? > - DBCENTURY 2 digit date fixes OK. > - DBCENTURY and interpretation of 2 digit datesin stored procedures + > triggers doesn't affect us. > > as well as the fix for buffer priority aging. and the recording of seqscans in onstat -p and SMI (table-level info). John Carlson Informix DBA WHSmith USA > >David Williams wrote: > >> > >> In article <383329F6.8C7CB5C7@bellsouth.net>, Carlson@WHSmith > >> <carlson1@bellsouth.net> writes > >> >IDS 7.30.uc10 > >> >HPUX 10.20 > >> > > >> >Just upgraded (over the weekend) to 7.30.uc10. One of my users ran a > >> >very basic report, and brought the Informix down. The system ended up > >> >with six assert failures within a four hour period. Called the down > >> What are the af files/online.log entries produced? > >> Have you tried 7.31.UC4-1?? > >> > >> >system group; they've analyzing the situation. I ended up regressing to > >> >7.30.uc7. > >> > > >> >I reinstalled uc10 on my test system and cut my production data over. > >> >Since then I've been able to either hang the engine up or crash it using > >> >the same report. BTW, this report ran well under uc7. > >> > > >> >Are there any outstanding issues with uc10? Are there any gotchas that > >> >I may have missed? (It's the first time I've had to regress to an older > >> >version . . . hence the 'ouch'.) > >> > > >> > > >> >Thanks in advance! > >> > > >> >John Carlson > >> >Informix DBA > >> >WHSmith USA > >> > >> -- > >> David Williams > > -- > David Williams

> >I'd like to rey 7.31.uc4, but I'd need to verify that Lawson has >certified that much of jump. (Of course, I can't install it until >January 15 due to our software freeze.) They told me last week that v708 environment is OK with v7.31UC3. I can dig out the call log if you like. Neil