Re: Deadlock incidence greatly increased after upgrade from 11.5.1 to 12.5.3 - Suggestions?

Hi

They may not execute simultaneously, but each user process only gets a
certain amount of processor time allocated before another one runs.

When the time is up for the 1st process, the 2nd process might run, and the
2nd process might walk into a deadlock scenario, before the 1st process can
be switched back in to run.

Query parallelism makes this scenario even more complex. You never know when
a process will be interrupted and who comes next in the queue.

Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@xxxxxxxxxxxx

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

<tomb@xxxxxxxxxxxxxxx> wrote in message
news:1133731128.998858.61990@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Mike Epprecht (SQL MVP) wrote:
>> Hi
>>
>> No, you did not miss anything.
>>
>> The older system was probably disk bound, so queries were waiting on each
>> other. You now have more processors and more RAM, so more queries will be
>> run simultaneously, increasing the changes for deadlock.
>>
>> Look at the code and follow the basic rules of how to not create
>> deadlocks.
>> (http://www.sql-server-performance.com/deadlocks.asp a SQL Server link,
>> but
>> applies to Sybase too)
>>
>> We had this problem show up very prominently on an 11.9 to 12.5.1
>> upgrade.
>> The new box was just so fast that the bad application coding from 6 years
>> ago was starting to fall over itself.
>>
>> Regards
>> --------------------------------
>> Mike Epprecht, Microsoft SQL Server MVP
>> Zurich, Switzerland
>>
>> IM: mike@xxxxxxxxxxxx
>>
>> MVP Program: http://www.microsoft.com/mvp
>>
>> Blog: http://www.msmvps.com/epprecht/
>
> Thanks for the link Mike.
>
> The new system is a single CPU box like the old one though, that would
> exclude queries from executing simultaneously wouldn't it?
>
> Tom.
>


.

Relevant Pages