SQL Server 2000 - 'Performance: Deadlock'

Question

We had to restart our SQL Server today, we had made no changes to it.

When it came back up we immediately started getting this error from the server

DATE/TIME: 2/27/2014 3:09:31 PM

DESCRIPTION: The SQL Server performance counter 'Number of Deadlocks/sec' (instance 'Database') of object 'SQLServer:Locks' is now above the threshold of 1.00 (the current value is 2.00).

COMMENT: (None)

JOB RUN: (None)

We ran the DBCC TRACEON (1204) command and have watched the log's but it's not reporting any deadlocks.

Any idea what could trigger this to just go off? We are getting the alert every minute yet can't find any actual deadlocks.

Edit: I should add that before this reboot we had never received this error

Edit 2: We used SQL Server Profiler as well to look for deadlocks, let it run for 5 minutes over which we received 5 error alerts and when we checked the details we had NO deadlocks found.

Edit 3: March 06/2014: Ran the query and it worked, but it reports what our other details have said that we have no locks we where still getting the error above the whole time.

Thanks again for all your help!

Edit 4: March 06/2014: I ran the query and here is a sampling of the result set, I will admit I am not exactly sure what I am looking at here, that is to say I am not sure if it shows me something that I can act on or not.

Edit 5: March 07/2014: Image below shows the Alert that generates this error all of a sudden.

Thanks

Answer 1

Update March 5th 2014

-- Removed the CTE and any options that could be incompatible with SQL SERVER 2000

if OBJECT_ID(N'tempdb..#process', N'U') is not null
    drop table #process
GO

if OBJECT_ID(N'tempdb..#tmp', N'U') is not null
    drop table #tmp
GO

select spid as victim, blocked as blocker
into #process
from master..sysprocesses p1 
where spid > 50
and blocked > 0
and spid <> blocked

insert into #process
select spid as victim, blocked as blocker
from master..sysprocesses p 
inner join #process
on #process.blocker = p.spid
where spid > 50


select  distinct 'dbcc inputbuffer(' + CAST( victim as nvarchar(4)) + ')' as cmd, 'sp_who2 ' + CAST( victim as nvarchar(4)) as spwho, *
into #tmp
from #process 
where blocker = 0
order by victim


select *
from #tmp 
order by victim

DECLARE @cmd nvarchar(400)
DECLARE @spwho nvarchar(12)

DECLARE curseur CURSOR
FOR
    select  cmd, spwho
    from #tmp 
    order by victim

OPEN curseur
FETCH NEXT FROM curseur INTO @cmd, @spwho

WHILE @@FETCH_STATUS = 0
BEGIN
    print (@cmd)
    exec (@cmd)
    print (@spwho)
    exec (@spwho)
    FETCH NEXT FROM curseur INTO @cmd, @spwho
END

CLOSE curseur
DEALLOCATE curseur 

GO

select
    db_name(dbid),
    'dbcc inputbuffer(' + CAST(a.spid as nvarchar(4)) + ')',
    a.spid,
    a.blocked,
    a.status, 
    a.cmd, 
    a.cpu,
    a.waittime,
    a.loginame,
    Base = DB_NAME(a.dbid),
    *
from master.dbo.sysprocesses a
where 1 = 1
    and a.spid > 50
    and spid <> @@spid
order by
    a.blocked desc,
    a.waittime desc,
    a.cpu desc         

Update 3/6/2013

So we've seen that no sessions are being blocked. Now we can also look at all current locks on your system.

Show locks server wide MSSQL 2000

Monitoring Lock Activity

select convert(varchar(30), suser_sname(p.sid)) as login,
       convert (smallint, req_spid) As spid,
       convert(varchar(30), db_name(rsc_dbid)) As db_name,
       case rsc_dbid when db_id()
            then convert(varchar(30), object_name(rsc_objid))
            else convert(varchar(30), rsc_objid) end As Object,
       rsc_indid As indid,
       substring (lock_type.name, 1, 4) As Type,
       substring (lock_mode.name, 1, 12) As Mode,
       substring (lock_status.name, 1, 5) As Status,
       substring (rsc_text, 1, 16) as Resource
   from master..syslockinfo s
   join master..spt_values lock_type on s.rsc_type = lock_type.number
   join master..spt_values lock_status on s.req_status = lock_status.number
   join master..spt_values lock_mode on s.req_mode = lock_mode.number -1
   join master..sysprocesses p on s.req_spid = p.spid
   where lock_type.type = 'LR'
     and lock_status.type = 'LS'
     and lock_mode.type = 'L'
     and db_name(rsc_dbid) not in ('master', 'msdb', 'tempdb', 'model')
order by spid, lock_type.number
go

The output will you tell you 1. what type of lock is being held: database, table, page. 2. the mode of the lock: S shared, X exclusive, RangeS-S where a range of values is locked in an index

Update 3/7/2014

I have updated your screen shot with some basic explanations. What we are seeing, is just a bunch of shared database locks.

To be brief, the locks on your system are shared (in other words, they don't block other sessions from accessing the database) and those locks are meant to prevent the database from being dropped, detached or renamed while data is being read and/or written from and to that database and its contents.

Getting back to your original question; there are no deadlocks or blocked sessions on your server. I don't remember having seen this message before, but from what you are sending back, this is definitely not about deadlocks and more likely to be just an informational message.

Or use sp_lock

sp_lock [[@spid1 =] 'spid1'] [,[@spid2 =] 'spid2']

Which will give you a more detailed view of all locks currently being held on your server.

http://technet.microsoft.com/en-us/library/aa238824(v=sql.80).aspx

Answer 2

While this counter says /sec, I believe it is a cumulative counter. If I'm right, this means you have had a TOTAL of 2 deadlocks since the service has been up.

I'm not at a machine where I can test this, but I suspect that if you simulate your own deadlock - once - you'll suddenly be getting 3.0 deadlocks "per second" until another deadlock occurs or you restart the service.

There are many scripts out there that will help you force a deadlock, basically:

-- window 1

Create table dbo.x(a int); create table dbo.y(b int);

Insert dbo.x(a) select 1: insert dbo.y select 2;

Begin transaction;

Update dbo.x set a = a + 1; 

-- window 2

Begin transaction;
Update dbo.y set b = b + 1;
Update dbo.x set a = 5;

-- go back to window 1

Update dbo.y set b = 22;

Now, if the counter goes up to 3.0, you know what to do: go find that pesky alert and disable it, or keep getting the alert but become desensitized to it unless the number changes drastically.