Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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'm looking at using SSD to improve DB performance in a large data warehouse. In our instance we know in advance that most of the data is write once, read many - especially as it's reference data. Does anyone have experience of doing this for real? In addition for the OS/Application, is it possible to seperate out those files which are changed frequently and put them on normal HDD.

I'm aware of the issues with performance degrading over time and not wanting to write fast changing data to the drive.

Edit -> I realise that I can partiton my DB and point certain tables at certain drives. The question is has anyone done it and was it worth it. Similarly what about the OS assuming Server 2003 - which files should go onto SDD, which onto HDD and how do you persuade the OS to split itself in that way?

share|improve this question

Sure, it's actually quite common to have a dedicated RAID10 array (for example) just to store your database data (mount it to /var/lib/mysql or wherever your database writes to) and then have your OS & applications on a basic RAID1 array. You can do the exact same things with SSDs.

share|improve this answer

Further to rodjek's answer you can usually split databases across multiple datastores (how to do this is both OS and DB dependent), that way you can just have the tables you want fast on SSD

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.