Friday, March 30, 2012

long running runnable processess

Some times on over prod. server i found some porcesses running for more than
2-3 hors, they r not in sleeping mode but runnable.
How it cab happen as our frontend uses commandtimout= 3 minutes.
ThanksIs this user process or some scheduled/system task. Please take a look at
one of Erland's script which should help narrow things down.
http://www.sommarskog.se/sqlutil/aba_lockinfo.html
--
-oj
"vicky" <v@.v.com> wrote in message
news:%237T88MhmGHA.3600@.TK2MSFTNGP02.phx.gbl...
> Some times on over prod. server i found some porcesses running for more
> than 2-3 hors, they r not in sleeping mode but runnable.
> How it cab happen as our frontend uses commandtimout= 3 minutes.
> Thanks
>|||This is a multi-part message in MIME format.
--080207000202000207010303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The timeout will just tell the client to give up after 3 minutes and
stop waiting for a response from the server. It doesn't tell the server
to abort the statement. The only way to get the server to give up in
the middle of a statement, assuming the server doesn't encounter an
exception (ie. throw an error) during processing of that statement, is
to use the KILL statement to terminate the SPID (process), which will
also disconnect the client application using that connection.
However, if a process has been running for a couple hours and you kill
it, then presumedly it has been doing a fair bit of work and the server
will need to roll that work back. So killing a process often, but not
always, takes as long as the current statement has been running for
anyway, and you never know if the statement is just seconds away from
finishing; that's the risk you take.
--
*mike hodgson*
http://sqlnerd.blogspot.com
vicky wrote:
>Some times on over prod. server i found some porcesses running for more than
>2-3 hors, they r not in sleeping mode but runnable.
>How it cab happen as our frontend uses commandtimout= 3 minutes.
>Thanks
>
>
--080207000202000207010303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>The timeout will just tell the client to give up after 3 minutes
and stop waiting for a response from the server. It doesn't tell the
server to abort the statement. The only way to get the server to give
up in the middle of a statement, assuming the server doesn't encounter
an exception (ie. throw an error) during processing of that statement,
is to use the KILL statement to terminate the SPID (process), which
will also disconnect the client application using that connection.<br>
<br>
However, if a process has been running for a couple hours and you kill
it, then presumedly it has been doing a fair bit of work and the server
will need to roll that work back. So killing a process often, but not
always, takes as long as the current statement has been running for
anyway, and you never know if the statement is just seconds away from
finishing; that's the risk you take.</tt><br>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2"><a href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
vicky wrote:
<blockquote cite="mid%237T88MhmGHA.3600@.TK2MSFTNGP02.phx.gbl"
type="cite">
<pre wrap="">Some times on over prod. server i found some porcesses running for more than
2-3 hors, they r not in sleeping mode but runnable.
How it cab happen as our frontend uses commandtimout= 3 minutes.
Thanks
</pre>
</blockquote>
</body>
</html>
--080207000202000207010303--

No comments:

Post a Comment