How to figure the read/write ratio in Sql Server?

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 swi开发者_运维知识库tch it to optimistic concurrency (isolation level: read committed snapshot) like Jeff Atwood did with StackOverflow.

All apps are heavy read only.

• An UPDATE is a read for the WHERE clause followed by a write
• An INSERT must check unique indexes and FKs, which are reads and why you index FK columns

At most you have 15% writes. I saw an article once discussing it, but can't find it again. More likely 1%.

I know that in our 6 million new rows per day DB, we still have a minimum of 95%+ reads (an estimate of course).

Why do you need to know?

Also: How to find out SQL Server table’s read/write statistics?

Edit, based on the question update...

I would leave DB concurrency until you need to change it. We've not change anything out of the box for our 6 million rows + heavy reads too

For tuning our web app, we designed it to reduce round trips (one call = one action, mutliple record sets per call etc)

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.

How about finding a ratio of num_of_writes & num_of_reads counters in sys.dm_io_virtual_file_stats?

I did it using SQL Server Profiler. I just opened it before running application and tested what kind of queries are executed while I'm doing something in application. But I think it's better just for making sure that queries work, don't know if it is convenient for measuring server workload like this. Profiler can also save traced which you can analyse later, so it might work.