Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

SELECT WITH NOLOCKS Expand / Collapse
Author
Message
Posted Wednesday, May 24, 2006 2:27 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, June 4, 2009 6:22 AM
Points: 65, Visits: 31

All,

I have regularly this message : Transaction (Process ID 59) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction

If I analyze my code, I  can see that issue provide from query 'SELECT'.

I would like to know if I use 'SELECT ... FROM ... WITH (nolock)' is a good idea for to fix this errors ?

Thanks for you help.

 

 




Kindest Regards,

degrem_m
Degremont
Post #282321
Posted Wednesday, May 24, 2006 2:56 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:23 AM
Points: 5,047, Visits: 11,799
It should fix the problem, provided you are prepared to live with the fact that your SELECT might read data from uncommitted transactions that may be rolled back.


Help us to help you. For better, quicker and more-focused answers to your questions, consider following the advice in this link.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.
Post #282325
Posted Monday, March 17, 2008 1:20 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, September 22, 2010 12:25 PM
Points: 16, Visits: 61
Hi I am getting same error even using with nolock in select query???
Post #470111
Posted Monday, March 17, 2008 2:01 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 6:55 AM
Points: 2,366, Visits: 1,845
Hi

Are you sure its the right "select" statement that you have put nolock on. Better check things once again.



"Keep Trying"
Post #470116
Posted Monday, March 17, 2008 3:06 AM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, November 9, 2010 2:56 AM
Points: 32, Visits: 58
Hi,

Be sure you apply 'WITH NO LOCK' on every table of your FROM clause...

On the other hand, I think you should first find which INSERT/UPDATE statement holds locks for such a long time...

P.



Patrick Duflot
Post #470128
Posted Monday, March 17, 2008 7:37 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 2:27 PM
Points: 3,309, Visits: 6,702
You could set Isolation Level read Uncommitted for the whole stored proc that has the select that causes dead locks

-Roy
Post #470230
Posted Monday, March 17, 2008 1:48 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 2:17 AM
Points: 42,831, Visits: 35,962
Personally I'd recommend finding the cause of the deadlocks and resolving that (usually bad code or bad indexing) rather than putting nolock everywhere. It can have some interesting effects (read uncommitted data, read rows twice, miss rows entirely and the like)

Nolock's basically saying to SQL that you don't mind if the data's not 100% accurate.

Enabling traceflags 1204 or 1222 will write the deadlock graphs into the error log. With that info, you can identify the processes involved in the deadlock, what procs and what queries in the procs they were running at the time. You can also see the deadlock resource. With that information, 8it should be possible to fix the root cause of the deadlocks.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #470472
Posted Monday, March 17, 2008 11:07 PM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, September 22, 2010 12:25 PM
Points: 16, Visits: 61
Hello Gail,
U r absoulately correct about putting Nolock every where is not the best way to avoid the deadlocks becouse it will cause dirty read on the tables where we put Nolock while selecting.But it must be the solution to prevant deadlock condition.
But in my case I have put even with nolock condition for each table what I am using to select data eventhough I am getting the same error in peak hours.That means there is no meaning of using nolock??Is QSL Server 2005 Dynamically select locks irrespective of the hints we used in he sql server.......

Alkesh K.
MCP SQL Server Developer
Post #470639
Posted Tuesday, March 18, 2008 9:52 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 2:17 AM
Points: 42,831, Visits: 35,962
Have you checked what the statements are that are involved in the deadlocks?


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #470956
Posted Tuesday, March 18, 2008 10:18 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 10:01 AM
Points: 3,844, Visits: 3,841
I'm with Gail here folks. Why not find and fix the problem instead of masking it with NOLOCKs? If you are 100% OK with dirty reads, maybe consider locking hints/local isolation level changes, but I personally have not seen too many occasions where dirty reads are really ideal.



John Rowan

======================================================
======================================================
Forum Etiquette: How to post data/code on a forum to get the best help - by Jeff Moden
Post #470991
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse