Question

How can I query the read/write ratio in Sql Server 2005? Are there any caveats I should be aware of?

Perhaps it can be found in a DMV query, a standard report, a custom report (i.e the Performance Dashboard), or examining a Sql Profiler trace. I’m not sure exactly.

Why do I care?

I’m taking time to improve the performance of my web app’s data layer. It deals with millions of records and thousands of users.

One of the points I’m examining is database concurrency. Sql Server uses pessimistic concurrency by default–good for a write-heavy app. If my app is read-heavy, I might switch it to optimistic concurrency (isolation level: read committed snapshot) like Jeff Atwood did with StackOverflow.

Answer 1

Check out sys.dm_db_index_usage_stats:

• seeks, scans, lookups are all reads
• updates are writes

Keep in mind that the counters are reset with each server restart, you need to look at them only after a representative load was run.

There are also some performance counters that can help you:

• Batch Requests/sec: number of Transact-SQL command batches received per second.
• Write Transactions/sec: number of transactions that wrote to the database and committed
• Transactions/sec: number of transactions started for the database

From these rates you can get a pretty good estimate of read:write ratio of your requests.

after your update

Turning on the version store is probably the best avenue for dealing with concurrency. Rather than using the snapshot isolation explicitly, I’d recommend turning on read committed snapshot:

alter database <dbname> set allow_snapshot_isolation on;
alter database <dbname> set read_committed_snapshot on;

this will make read committed reads (ie. the default ones) to use snapshot instead, so it literally doesn’t require any change in the app and can be quickly tested.

You should also investigate if your reads don’t get executed under serialization reads isolation level, which is what happens when a TransactionScope is used w/o explicitly specifying the isolation level.

One word of caution that the version store is not exactly free. See Row Versioning Resource Usage. And you should give a read to SQL Server 2005 Row Versioning-Based Transaction Isolation.