Re: Update statistics bug

Vickey Crouch wrote: > I have a very strange problem that I'm hoping someone can help me with. > I am running Informix on-line (both 7.12 and 7.23) on a Sun platform. I > have a variety of unrelated jobs (i.e. PB apps that run stored > procedures, ESQL/COBOL programs that insert data, etc,) that spawn > multiple threads and use up memory rapidly, but only periodically. > NAME STATUS > sqlexec cond wait(sm_read) > group_1. cond wait(await_MC1) > join_2.0 cond_wait(await_MC2) > join_2.1 cond_wait(await_MC2) > hjoin_3. cond_wait(await_MC3) > join_4.0 cond_wait(await_MC4) > join_4.1 cond_wait(await_MC4) > scan_5.0 cond_wait(await_MC5) > scan_6.0 cond_wait(await_MC6) > Why are all of these different threads running? What do they mean? > What is, for example, MC1? An even bigger qestion is, is there some > documentation available that REALLY explains the onstat output? This looks like multi-level four or five table join using PDQPRIORITY>1. If the onstat -g ses <sesid> does not show such a query as the current SQL that indicates that probably resources from prior queries have not been released. This usually happens when cursors are redeclared and reopended and/or statements are re-prepared without having closed/free'd them before hand. Make sure that you either reuse existing cursors (by closing and reopening them) or make sure to close and free the cursor before redeclaring it. The same for statement ids. Either use the existing statement id repeatedly to declare new cursors or free the id before repreparing it. Art S. Kagel