Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a thousand web servers writing their logs to a SQL Server 2008 database. The log information can be up to 100 GB per day, and we keep 1 month’s worth of logs.

Each day, we run queries on the log data and store the results of the queries in the database. The total size of the query results for a day is about 10 MB.

Right now, the table which holds the log data and the tables which hold the query results are on different filegroups on different physical drives.

Would it make a different from a performance point of view to have the log data and the query results stored in two separate databases (which would be on separate physical drives)?

share|improve this question

migrated from Sep 6 '12 at 5:05

This question came from our site for professional and enthusiast programmers.

up vote 0 down vote accepted

well I think so. One of the bottleneck in transaction for sql is the writing in the ldf (sql log file) file. Of course you may split the sql log on several physical files, but I'm quite sure you can't manage the dispatch of transactions between those physical files.

When having two databases you will have two sql logging and then can set them on two different physical drives and then gain better performance.

but this is really pertinent in case of concurent transactions.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.