In case your intention is to determine long running queries in active sessions, so currently ongoing queries:
as you might know (and not applicable here, but still interesting): since 14.10.xC6 "onstat -g ses <...>" (and "onstat -g sql <...>") would show 'Clock time elapsed' with any sessions currently executing any SQL. This time is the duration so far of the current SQL.
What's available since 11.70.xC4, also in "onstat -g ses <...>", is an execution counter. That's the number in brackets in the "Current SQL statement (#
) :" or "Current SQL statement (#
) in procedure <db>:<udr>" line; it counts the executions of SQL statements and is shown only if the session is currently executing a statement, i.e. if onstat -g ses output contains that "Current SQL" block.
This can be used comparing two such outputs for the same session: if both outputs have this block showing the same execution counter value (and same SQL statement), this means that this instance of SQL was the currently executed SQL at both times, so its execution must have started before first output and hasn't completed yet at second point in time. Conversely, if the same SQL statement is shown in two such outputs with differing execution counter, you could tell it's not this statement taking so long, but (this or any other SQL) statement being executed 'so frequently'.
Now "long running" can mean very different things (and not necessarily a problem), besides "being a session's current SQL statement over a certain period of time":
- a super-frequent query could be considered long if taking a second or two (or even much shorter)
- some ad-hoc query for a certain purpose taking longer than expected
- a query for a monthly report having to go through vast amounts of data, thus taking its time
And it can result from, or be accompanied by, a variety of things:
- consuming a lot of cpu -> you'd see the executing thread in 'running' state a lot (i.e. it would occur in onstat -g act)
- spending time with disk i/o -> you'd frequently see it in "IO Wait" state (or bufwait if IO is performed by read-ahead thread)
- frequent or long waits on client -> you'd see it in "cond wait netnorm" (for tcp connections) or "cond wait sm_read" (with ipcshm)
- other waits (on buffers, locks, other conditions, mutexes, cpu, ...)
... and of course all of these typically being immediate rather than root causes.
So after identifying such long runners, you'd always have to have a closer look at thread states etc. over their duration (many rather than only two outputs will be useful.)
Since such investigation typically involves wading through large "onstat -g ses 0" outputs, there's an enhancement, since 12.10.xC13: "onstat -g ses <state>" and "onstat -g sql <state>" (s. onstat usage)
This allows selection of sessions (their thread(s)) in a given state (or collection of states), implicitly meaning "currently doing work", i.e. having a current SQL.
-> best shot at "what is my system doing in this moment, SQL wise?"
Sent: Fri May 28, 2021 08:15 AM
From: AMIT PATEL
Subject: Long Running Query thru shell Script
I need to write a shell script to find long running Query in Informix 11.70. (We will upgrade with 14.10 in August 2021).
As it includes three main steps
1. Search onstat -g act -g -x (x= 1, 2, 3, 4, ....)
2. Check tcb column with Non ZERO value and run onstat -u | grep <Non ZERO value>o
3. Now get session id and run onstat -g ses <ID>
But we can get multiple rows while running onstat -g act -r 1 ......
So can someone please guide me how can I write script to find the exact session id which is causing the Performance.