title: Can read query cause row lock contention in Oracle
body: <p>I am working in a high transaction financial system. We have a table that is undertaking a massive number of transaction updates concurrently. All queries are optimized and data models are structured to support concurrency flexibly.</p>
  
  <p>One of the peculiar things that I have noticed is that during the updates if we run a query that runs a <code>SUM(balance)</code> function on multiple rows, the AWR report shows that 57% of DB time was spent in row lock contention. </p>
  
  <p>Based on what I read in Oracle locking documentation, no reads can ever acquire locks on rows and can read committed data safely. Would it be the case that if one of the rows that need to be part of <code>SUM</code> function has been locked by <code>Select for Update</code> statement, the read query would need to wait until lock is released? </p>
  
  <p>Without the read query, the transactions sail through with contention as low as 6%. Is it possible that read queries tend to be CPU intensive and causes contention due to CPU starvation?</p>
  
  <p>I did notice that when we are running read query during operation, the CPU rises from 20% to 80% average. </p>