How to handle reporting of an extreme amount of databases in SQL Server 2005? I'm looking for some advice on how to handle reporting for our environment.  We currently have 16 servers with 20 instances of SQL Server 2005.  We have over 6,600 databases and growing across these instances (1 database per customer).  The majority of our databases run in size from 200mb to 7gb with about 60 databases running in size from 11GB to 110 gb at the largest.

We are using a SAN for storage and we are running into issues with the running of the reports affecting IO.  

One idea we had was to pull the 60 larger databases and then use transactional replication to replicate these databases and run reporting on the replicas.  

That would then leave all the smaller databases to run without the stress of the larger databases.  In the future we don't believe there will be any more of the the larger databases based on our company goals.

Any thoughts?
In our shop at my previous job, we had a secondary set of servers where we tested our restores. For our busiest customers we would restore tonight's backup, mark it as read_only, and their reporting tomorrow would connect to that copy of the database for all reports from yesterday back. This offloaded about 90% of the reporting workload and doubled as a backup/restore validation method. So if most reports don't need today's data, you could consider alleviating some of the production workload this way with some cheaper hardware - if you're not using Enterprise features you could even use Express for all the databases that are &lt; 10GB. (Well, I see it's 2005, which had a lower DB size limitation, but you could always restore your copy forward into 2008/R2.) This would allow you to really distribute the databases to many low-end commodity servers (VMs or pizza boxes).