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"

Reply via email to