Reporting on a SQL DB Server with many write operations and few read operations I know this is a generic question, but I have to clarify some basic questions.
I know that when a write is happening to a SQL Server database table, a read to that table will have to wait.
My question here is: the SQL database server I am working on is being exposed to many writes and a few reads. And a few SSRS reports are also being run on the same server.


What is the ideal or recommended way to accommodate this?


I know that it is always best to perform reporting from a duplicated instance of the same database. But for a few reports, is it worth to set up a duplicate instance for reporting?

I get complaints sometimes that some reports are running slow.


Can it be the read wait while a write happens?
I know that when a write is happening to a SQL Server database table, a read to that table will have to wait.


This isn't necessarily true. Proper indexing can help mitigate blocking waits by giving queries adequate paths to data, and helping modification queries find the data they're going to be modifying.


  I know that it is always best to perform reporting from a duplicated instance of the same database. But for a few reports, is it worth to set up a duplicate instance for reporting?


Potentially, because:


  I get complaints sometimes that some reports are running slow.


Finally:


  Can it be the read wait while a write happens?


Take a look at SNAPSHOT ISOLATION. If the reports are slow because of blocking, this can help. If the reports are slow for other reasons, at least you'll know pretty quickly. Heh.