kevin_nikolai (8/2/2013)
Normally you would use READ UNCOMMITTED in stored procedures of SQL Reports if they pointto Application server database - NOT to impact performance of the Application you would not worry too much about the totals that are slightly out
And the users of those reports know and accept that the results could be completely wrong. Not slightly off due to dirty reads, potentially way off due to missing and re-reading rows.
I've seen a report whose total was 20% off because nolock had allowed a particular row to be read twice and totalled twice into a financial report. Personally I've never met users who would be happy with reports that they know could be wrong. I have however met lots of developers who had no idea what side effects nolock/read uncommitted could have and who would close bug reports about incorrect data as 'cannot reproduce'.
p.s. Snapshot isolation. Read committed snapshot isolation. Database Snapshot. Reporting off log shipping secondary. Reporting off mirror DB. Reporting off Always On Read-only Secondary in SQL 2012.
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