| Author |
Topic |
|
lauramayer
Posting Yak Master
152 Posts |
Posted - 2004-06-14 : 11:26:08
|
| Good morning,We have a lot of problems with locking and long running queries. With summer coming an all I want to be doing is something else instead of fixing these processes or watching them crash.My thought is that somehow I have to put all of this together so that the system can sort of fix itself.What I would like to do is listed below:Level 1--An Alert that triggers on a blocked spid or long running query (What do I use for an event to trigger it?)A job that runs to check processes on a schedule Level 2-Procedure to id and kill blocked spids ( run when alert is triggered)Procedure to id and kill outdated spids ( triggered by job run)(This I believe I have.)Level 3-Notification to us with problem handling ( if system ids and kills problem)---Okay no problem here....Notification of long running processes that might be a problem so that we can fix them (Again how to identify them, I have a query that identifies them but again how to trigger the event?)Thanks to everyone for any helpLaura |
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 2004-06-14 : 12:38:57
|
| That would just address the symptoms..you need to fix the real problemYou should fix the blocking...I guess you could do sp_who2 and insert the results to a table, and interogate that....But that's reactive, no proactive...Brett8-) |
 |
|
|
lauramayer
Posting Yak Master
152 Posts |
Posted - 2004-06-14 : 12:46:21
|
| Thanks Brett,I've identified most of it. The problem is the developer can't/won't fix it and I need a way to be proactive and fix it as it's happening and make it fix itself if that's possible.Laura |
 |
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2004-06-14 : 14:01:09
|
| Then escalate it to management and get the developer in trouble if you need to. That's your job as the DBA. He needs to fix his code. You're not being proactive and fixing anything. Killing processes doesn't fix things. It breaks things even worse. Bad code doesn't fix itself; and you can't fix it either. Unfortunately, the same thing is many times true of a bad developer.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
 |
|
|
lauramayer
Posting Yak Master
152 Posts |
Posted - 2004-06-14 : 14:32:43
|
| Derrick,Once again you cut to the chase and the heart of the matter. I can't fix the developer or the code, I just need to make the system run for the users. I've tried escalating it to management but the developer has an answer to every coding problem I discover. So I'm on my own crusade to try to find enough evidence to hang him out to dry and stop bogging down my system.Laura |
 |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2004-06-15 : 17:47:16
|
Grrrr, what I hate most about this forum (which I basically love most of the time) is that "nobody" ever gives a straight answer to a question that is not really best practice. It's always great to know how you can spend ages in meetings with god knows who in your organisation to set a developer straight, but my bet is that Laura has allready considered this and chosen the lesser of two evils for the time beeing. Level 1: Start a sql-server trace that runs continusly and logs to a table in some database. Capture all queries that runs for more than say 3 secs (or whatever causes problems). Level 2: Create a "monitoring"-job that runs on a schedule maybe every 3 mins or something and checks the trace-table for queries that are running too long. Also let this job search the master-database for blocking spids and kill them if you need to (KILL [spidnumber]). If you have to kill something it might be a good idea to log what is happening aswell. To find blocking spids you kan run the procedure which was given to me by Nigel (nr) here at sqlteam (code at the bottom here, sp is run like this: exec sp_nrSpidByStatus 'blk').Level 3: Set up xp_sendmail to notify whoever needs to get notified when something nasty is going on in Level 2. Alternatively I can give you a procedure that uses the ActiveX called aspemail to send emails if a mapi-account isn't available. It's really easy...Level 4: When you have captured enaugh sh**, hand it over to this guys boss. Now you have documentation.Procedure:USE masterGOSET QUOTED_IDENTIFIER ONGOSET ANSI_NULLS ONGOCREATE procedure sp_nrSpidByStatus@status varchar(20) = 'runnable'as/*exec sp_nrSpidByStatus -- all spids whith status runnableexec sp_nrSpidByStatus 'sleeping' -- all spids whith status sleepingexec sp_nrSpidByStatus 'background' -- all spids whith status backgroundexec sp_nrSpidByStatus 'sleeping' -- all spids whith status sleepingexec sp_nrSpidByStatus 'all' -- all spidsexec sp_nrSpidByStatus 'blk' -- all blocked or blocking spidsexec sp_nrSpidByStatus '74' -- an individual spid - also gives subthreadsselect * from master..sysprocesses where spid = 56*/set transaction isolation level read uncommittedset nocount ondeclare @cmd varchar(1000)declare @buf varchar(1000) , @id int , @spid int , @maxSpid int create table #spid (spid int, command varchar(1000) null) create table #temp (x varchar(100), y int, s varchar(1000), id int identity (1,1)) create table #spids (spid int) if isnumeric(@status) = 1 begin insert #spids select @status end else if @status = 'blk' begin insert #spids select spid from master..sysprocesses where blocked <> 0 union select blocked from master..sysprocesses where blocked <> 0 end else begin insert #spids select spid from master..sysprocesses where (status = @status or @status = 'all') and ecid = 0 end select @spid = 0 , @maxSpid = max(spid) from #spids while @spid < @maxSpid begin select @spid = min(spid) from #spids where spid > @spid select @cmd = 'dbcc inputbuffer (' + convert(varchar(10),@spid) + ')' delete #temp insert #temp exec (@cmd) select @id = 0 , @buf = '' select @buf = @buf + replace(replace(s,char(10),'|'),char(13),'|') from #temp insert #spid select @spid, @buf end select blk = case when s.blocked <> 0 then convert(varchar(3),s.blocked) else ' ' end , spid = convert(varchar(4),#spid.spid) , s.physical_io , status = left(s.status,12) , last_batch = convert(varchar(23),s.last_batch,121) , s.cmd , #spid.command , login_time = convert(varchar(23),s.login_time,121) , s.HostName from #spid , master..sysprocesses s where s.spid = #spid.spid and (ecid = 0 or isnumeric(@status) = 1) order by s.status, #spid.spid drop table #spid drop table #tempGOSET QUOTED_IDENTIFIER OFFGOSET ANSI_NULLS ON GO |
 |
|
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2004-06-16 : 04:55:03
|
| The ammunition you need to solve this problem....might be provided by your monitoring application automatically emailing "management" every time, it has to solve a problem (ie kill a spid) for you.......Sometimes spam has it's upsides! |
 |
|
|
lauramayer
Posting Yak Master
152 Posts |
Posted - 2004-06-16 : 06:31:15
|
| Thank you thank you!!! This is great. Thanks so much for all the help.Laura |
 |
|
|
lauramayer
Posting Yak Master
152 Posts |
Posted - 2004-06-16 : 06:37:13
|
| Hi again,You mentioned an alternative to a mapi account see below:..."Alternatively I can give you a procedure that uses the ActiveX called aspemail to send emails if a mapi-account isn't available. It's really easy..."Could you post that please? Thanks so muchLaura |
 |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
|
|
lauramayer
Posting Yak Master
152 Posts |
Posted - 2004-06-16 : 12:02:14
|
| Found it. Thanks again.Laura |
 |
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2005-12-01 : 09:26:26
|
| good thread.good you also schedule the trace to stop and start at certain times? |
 |
|
|
|