Very Computer

running IDS 2000 9.21.UC4 on SGI Irix 6.5.14f.

I have written a perl utility similar to unix top, but displays database
sessions instead of OS processes by virtue of DBI. Unfortunately after
running for a couple of days, it crashes the engine.

Spoke to informix and was told that there is a bug in this version of IDS
2000 which can cause the system to crash when reading from the SMI tables.
Their answer to the problem is not to run queries against the sysmaster
tables. Which leaves me in an interesting situation as I can not properly
perform diagnosis or performance tuning without the SMI stuff. Onstat just
doesn't cut it when you have over a thousand connections to the instance all
doing different queries on over 1500.

Just wondering if anyone else has seen this problem. I believe it relates to
the data in the system tables changing as my script is reading from them.

I upgraded the script to give you the choice of using DBI or onstat, but
unfortunately, with that number of sessions on the database, onstat takes
way to long to glean the required data.

What am I supposed to do now?

Been there, been bitten by that. The answer you were given is something of a
cop out in my view. Some of the commercial monitoring programs out there
do/used to use the SMI for information.

The real answer is probably to upgrade to another version of the engine, or
keep at them to get a fix. You could possibly try recreating the SMI, but I
have not seen any evidense that it helps.

Mark

Quote:> Hi,

> running IDS 2000 9.21.UC4 on SGI Irix 6.5.14f.

> I have written a perl utility similar to unix top, but displays database
> sessions instead of OS processes by virtue of DBI. Unfortunately after
> running for a couple of days, it crashes the engine.

> Spoke to informix and was told that there is a bug in this version of IDS
> 2000 which can cause the system to crash when reading from the SMI tables.
> Their answer to the problem is not to run queries against the sysmaster
> tables. Which leaves me in an interesting situation as I can not properly
> perform diagnosis or performance tuning without the SMI stuff. Onstat just
> doesn't cut it when you have over a thousand connections to the instance
all
> doing different queries on over 1500.

> Just wondering if anyone else has seen this problem. I believe it relates
to
> the data in the system tables changing as my script is reading from them.

> I upgraded the script to give you the choice of using DBI or onstat, but
> unfortunately, with that number of sessions on the database, onstat takes
> way to long to glean the required data.

> What am I supposed to do now?