November 6, 2003 at 4:47 am
Hi!
I use this query:
select
min(l.ACCTDESC),
g.ACCTID,
sum(TRANSAMT)
fromlegacy..GLPOST g (nolock)
join legacy..GLAMF l (nolock) on g.ACCTID = l.ACCTID
whereg.ACCTID in ('990001', '990002', '990015')
group by
g.ACCTID
Get:
Server: Msg 1205, Level 13, State 1, Line 1
Transaction (Process ID 78) was deadlocked on thread | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
If I remove min(l.ACCTDESC) works fine:
select
g.ACCTID,
sum(TRANSAMT)
fromlegacy..GLPOST g (nolock)
join legacy..GLAMF l (nolock) on g.ACCTID = l.ACCTID
whereg.ACCTID in ('990001', '990002', '990015')
group by
g.ACCTID
Why?
Thanks.
November 6, 2003 at 5:13 am
Is it the only thing accessing the table?
If so try with maxdop = 1.
Do you have the latest service pack?
There have been some bugs fixed with parallelism causing deadlocks.
Cursors never.
DTS - only when needed and never to control.
Cursors never.
DTS - only when needed and never to control.
November 6, 2003 at 5:45 am
This is the version I have:
Microsoft SQL Server 2000 - 8.00.818 (Intel X86)
May 31 2003 16:08:15
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
The query was ran for about 5 seconds, i.e. the value for [cost threshold for parallelism
]. Increased it to 60 seconds,- it works fine now. So the cause was, most probably, parallelism bugs. What fix I need for it?
What is "maxdop"? (Could not find it in BOL)
November 6, 2003 at 6:03 am
see the option clause on the select statement.
I can't find the knowledgebase article about it.
Try posting this on the microsoft site
http://msdn.microsoft.com/newsgroups/
I'll do some more research and see if I can find it.
Cursors never.
DTS - only when needed and never to control.
Cursors never.
DTS - only when needed and never to control.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply