January 5, 2015 at 11:36 pm
hi ,
i studied , it ll not allowed to table get lock. DBA team suggests that it ll increase your query performance. eg, try with nolock and with out nolock in select statement from table which contains large volumes. u ll see the difference.
thanks
Kannan
January 6, 2015 at 12:17 am
Kannan Vignesh (1/5/2015)
thanks for your clarification. i will correct it.Ok jeff. with out nolock, if many peoples accessing same table means it cause any performance issue..?
thanks
Kannan.
Only if there's bad code doing inserts or updates. Selects don't cause performance problems for other Selects.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 6, 2015 at 12:22 am
Kannan Vignesh (1/5/2015)
hi ,i studied , it ll not allowed to table get lock. DBA team suggests that it ll increase your query performance. eg, try with nolock and with out nolock in select statement from table which contains large volumes. u ll see the difference.
thanks
Kannan
The DBA Team is making a bad suggestion for the wrong reason. If it takes a little longer without it, that's a whole lot better than possibly reading uncommitted that that could be duplicated or rolled back.
Don't use WITH(NOLOCK) as a performance tool. Fix the bad code that's causing the performance problem, instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 6, 2015 at 6:03 am
Jeff Moden (1/6/2015)
Don't use WITH(NOLOCK) as a performance tool. Fix the bad code that's causing the performance problem, instead.
+1000
http://www.jasonstrate.com/2012/06/the-side-effect-of-nolock/
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply