Ravi, As you may remember, at Level3 we needed to use the NOLOCK hint on a lot of our processes, and even included it in the ar.cfg. The up side is that none of your queries will ever be blocked due to locking at the row or table level. The down side is that your queries could be considered 'dirty' because your query MIGHT get data that is not yet committed to the DB, and subsequently rolled back, so in effect the results returned may not be 100% accurate, but in general I don't consider that to be too much of an issue. For greater concurrence, not having NOLOCK could cause your queries to take longer (waiting in line for inserts and updates to complete before returning results), but for accuracy, NOLOCK could cause 'inaccurate' results. So, as with everything in life, there are tradeoffs for everything you do, you just need to determine if your performance means more than your accuracy.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of ravi rai Sent: Thursday, November 01, 2012 2:47 PM To: arslist@ARSLIST.ORG Subject: No Lock Setting on AR CFG ** Hi, We are getting few DB lock cases and planning to implement READ-COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION (Long term) There was a recent thread on NO Lock in Ar.cfg. Planning to add No Lock for short term What impact it has on performance of the system. Anyone implemented it faced any issues BMC suggested:NOLOCK should NOT be enabled - this is contrary to our guides, but is the correct settings per BMC Performance and deployment teams Please suggest Thanks Ravi Rai _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
