on 2012 Mar 18 10:33 AM
When running 12.0.1.3298 on an Intel Core i7 Q720 with Task Manager showing 8 CPUs, it is possible to run a CPU-intensive query that starts 8 separate "INT: Exchange" connections that report enormous CONNECTION_PROPERTY ( 'ApproximateCPUTime' ) values while the originating client connection reports zero:
SELECT COUNT(*) FROM SYSCOLUMN AS A CROSS JOIN SYSCOLUMN AS B CROSS JOIN SYSCOLUMN AS C;
On a busy server, how do I identify the culprit?
I.e., how do I trace the "INT: Exchange" connections back to the originating client connection?
...and are there any other "INT: ..." connections that behave similarly?
Ahhhhh, that would be CONNECTION_PROPERTY ( 'ParentConnection' )...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
FWIW, doing validation with v12.0.1.3554 shows a similar behaviour, i.e. running several short-living internal "INT: Exchange" connections with increasing "ApproximateCPUTime" whereas the triggering connection does not increment that value.
However, as soon as the internal connections are dropped, then their CPU times seems to get summed up for the parent connection. - During validation, this happens multiple times, as there are multiple cycles of creating, running and dropping internal "Exchange" connections.
Checked on a different connection via:
select connection_property('ApproximateCPUTime', sci.Number), * from sa_conn_info() sci
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
66 | |
11 | |
10 | |
10 | |
9 | |
7 | |
7 | |
6 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.