Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 143
  • Last Modified:

DeadLocks!

I'm having problems with deadlocks and I don't think I should.

I fully understand how a deadlock is caused having a circle of resource requests, so no need to explain that.   Here is my situation..

I have a few parent-child tables that are used for reporting.   A user enters some criteria and a few hundred records are populated into the report tables based on the information entered, the user can then browse the report records created.   All reporting records have a unique report ID for a reporting session.  So each user is only touching those records for that session of reporting

Since every user is only touching records with his own unique report ID, there is no way that someone else's reporting form will access those same records.  They will insert/update records in the same table, but not those records.   So there should never be a dead lock.

So, why am I getting deadlocks and how do I prevent them?

The basic action of the reporting form is to (1) insert records using an insert-select statement (2) update those entered records and (3) delete those records if the user chooses to re-run the report

I was using SQL Server 2005 and now I have gone to 2012 and the problem is worse!
0
gdemaria
Asked:
gdemaria
2 Solutions
 
Phillip BurtonDirector, Practice Manager and Computing ConsultantCommented:
Deadlocks are not just on a record. They could be on a page or the entire table.

Maybe you should use dirty reads perhaps. I note that in your 1-2-3 you don't have any actual SELECT statements, so your summary may not be complete.

Try using Extended Events to see if you can track this down - in 2012 EXtended Events is much better than in previous versions,
0
 
gdemariaAuthor Commented:
Thanks Phillip - I will Google, Extended Events, I am not familiar with that.

Number (1) indicates an insert based on an insert-select statement.   The updates are also using select statements to complete the updates.

Under what circumstance would SQL Server lock the entire table?  And wouldn't that only for for a short time and once unlocked, the other records and proceed?   Why would that cause a deadlock?
0
 
Scott PletcherSenior DBACommented:
What are the clustering keys on all involved tables?

What are the join and WHERE conditions on those tables?

In the meantime, turn on trace flag 1222 so you can get more detailed on the deadlocking:

DBCC TRACEON ( 1222, -1 )
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Vitor MontalvãoMSSQL Senior EngineerCommented:
They will insert/update records in the same table, but not those records.   So there should never be a dead lock.
Inserts will cause a table lock and updates can cause at least a page lock so this may justify the dead locks.
As told above you can use dirty reads if that's not a problem. This can be accomplished by using locking hints. Ex.:
SELECT * FROM TableName WITH (NO_LOCK)
0
 
Phillip BurtonDirector, Practice Manager and Computing ConsultantCommented:
For Extended Events, have a look at:

http://msdn.microsoft.com/en-GB/library/bb630282.aspx
https://www.youtube.com/watch?v=2cbNXFUdAUg
(This is a video)

If you do Google Extended Events, make sure you are reading about the 2012 (or 2014) version - the 2008R2 version is quite different.
0
 
gdemariaAuthor Commented:
I tried to do extended events, but got an error saying I didn't have permission.  I am using Amazon RDS SQL Server Web Edition, it may not be part of that, I have to check with support.

Thanks for the tip on dirty reads,  I don't think that would be a problem because no other process could update the same records.   If I do an insert followed by an update of those just inserted records, the inserted records would be there even though it was a dirty read, right?   Same thing with multiple updates in a row by the same process?

I'm surprised dirty reads is my only route.   Is this a huge flaw of SQL Server?  I used Oracle for years and dead locks were very, very rare.    As I said, the different users/processes never touch the same records so there logically should not be any deadlocks, it seems to be a flaw to lock the entire table - can I tell SQL Server not to do that?
0
 
Phillip BurtonDirector, Practice Manager and Computing ConsultantCommented:
> I'm surprised dirty reads is my only route.

It's probably not the only route, but we are trying to diagnose from a distance. That's why I'm suggesting Extended Events or its equivalents to help you diagnose it.
0
 
gdemariaAuthor Commented:
Got it Phillip, I will try to get more information if Extended Events are allowed.
Thanks!
0
 
Phillip BurtonDirector, Practice Manager and Computing ConsultantCommented:
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Tackle projects and never again get stuck behind a technical roadblock.
Join Now