SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


with nolock in sql server please advice


with nolock in sql server please advice

Author
Message
Jai-448139
Jai-448139
SSC-Enthusiastic
SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)

Group: General Forum Members
Points: 174 Visits: 106
I have read lots of article about with nolock, and have seen many projects using with nolock option.

Please advice me if i am right.

I have read lots of article about with nolock, and have seen many projects using with nolock option.

Please advice me if i am right.

1.Normal select queries can use with no lock
2. Batch jobs should not use with no lock.


please guide me, am i right.

Thanks
SQL ORACLE
SQL ORACLE
SSCertifiable
SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)SSCertifiable (6.6K reputation)

Group: General Forum Members
Points: 6587 Visits: 1314
Here is my input.
I do not think we have a clear cut on your questions.
Generally speaking, when there are many users and objects are huge, we may need to use NO_LOCK. Our decision is made based on our the above factors and the torlerance of our users.

NO_LOCK may cause insistencies if we abuse it, however.
GilaMonster
GilaMonster
SSC Guru
SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)

Group: General Forum Members
Points: 216889 Visits: 46278
No lock's not something you should be using all the time. It's for when you have concurrency issues and you don't mind the chance of inaccurate data.

Selects can be run with no lock, however all forms of data modification will take locks, even if you specify the nolock hint.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
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


Ian Yates
Ian Yates
SSCarpal Tunnel
SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)

Group: General Forum Members
Points: 4484 Visits: 445
And, in a really busy environment, your No Lock query could say there's table corruption when there really isn't. I cannot remember the exact cause but it's to do with the nolock allowing another query to change the linked pages, etc and then when the nolock query comes across that bit it doesn't necessarily see the change straight away.

Run your DB with nolock to see how it goes. If need be you should probably change the transaction isolation level rather than explicitly specifying locking hints.



EdVassie
EdVassie
SSChampion
SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)

Group: General Forum Members
Points: 13531 Visits: 3894
If you are doing aggregation queries, where the consistency of the result is not critical, you should make NOLOCK your default choice. Also make NOLOCK your default choice when querying static data, as there is no need to get SQL to do more work then required. This often means that data warehouse (BI) queries are often a good candidate for NOLOCK.
If you are doing queries against operational data (e.g. checking quantity in stock before promising delivery) then you need the protection of locking, otherwise you may make the wrong business decision. This means that OLTP type queries normally do not have NOLOCK or the application uses some form of optimistic update logic to handle the integrity issues. Even with OLTP applications, static data queries can use NOLOCK.

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005. 14 Mar 2017: now over 40,000 downloads.Disclaimer: All information provided is a personal opinion that may not match reality.Quote: When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist. - Archbishop Hélder Câmara
dtevlin
dtevlin
SSC-Enthusiastic
SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)SSC-Enthusiastic (192 reputation)

Group: General Forum Members
Points: 192 Visits: 77
Be aware that you can get duplicate data back in a query using NOLOCK.

Itzik Ben Gan demoed this and you can find a code example here.

http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/11/16/1345.aspx

--Dave



Joe Clifford
Joe Clifford
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2095 Visits: 619
You've got to watch those hints and use them sparingly, in SQL 2005 there are better alternatives than NOLOCK in T-SQL. Have you looked into snapshots?

One gotcha to avoid, SQL 2008 and beyond "Specifying NOLOCK or READUNCOMMITTED in the FROM clause of an UPDATE or DELETE statement when applied to the target table of the statement." will no longer work.

Joe



Santa Ana
Santa Ana
SSC Rookie
SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)

Group: General Forum Members
Points: 33 Visits: 42
Does the WITH (NOLOCK) option work with sql server 2005 ?
Or is it depricated ?

I was facing some serious deadlock issues in a high transaction table, i was not bothered about inaccurate data, i added nolock to a select statement.

Even after i added nolock directive to my select, this select statement becomes a deadlock victim at times.

I do not understand why and how can this happen? ( a select with nolock is not locking anything at all, how does it participate in a dead lock situation ? )

can someone throw some light on this please ?

fyi. there could be other transactions that update the data that the select with nolock transaction is trying to select.

Thanks in adv.
appreciate your help.
GilaMonster
GilaMonster
SSC Guru
SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)SSC Guru (216K reputation)

Group: General Forum Members
Points: 216889 Visits: 46278
Santa Ana (3/31/2009)
Does the WITH (NOLOCK) option work with sql server 2005 ?

Yes

I do not understand why and how can this happen? ( a select with nolock is not locking anything at all, how does it participate in a dead lock situation ? )


You're going to have to show us the code to be sure, but I have before seen deadlocks resulting from schema locks as a result if enabling and disabling triggers and even selects with a nolock have to respect a Sch-M lock.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
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


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search