I was having a conversation with my colleagues on Db performance, when it veered into Solid State Drives for TempDb. Assuming that since TempDb is very high writes and less reads, the faster the disks can write, the better it is, and the more you have the I/Os split up, the faster it will be.
That got me thinking - for places that manage a number of databases or even 1 with high volume, wouldn't it make significant difference if we drop in a solid state drive for Temp? This got me further thinking - if all Temp is expendable, and not really stored, why should it be a drive at all.
Why not use RAM Disk instead? Power outage - doesn't matter - since the data is all Temp anyways!
But what about taking it up a notch. (If it's not done already - I'm claiming rights to it :-) ) . Why not storage providers like EMC or others offer Tray's of just RAM for Temp storage? DBA's could potentially create the TempDb / Tablespace on the RAM Disks. When DBAs are managing large number of instances (Oracle) they could just as well point to this RAM disk in this tray.
Wouldn't that significantly improve performance? Instead of always looking at increasing I/Os on disks - especially for Temp, wouldn't this be a better way to go?
I'm writing this before any research on this topic, but I couldn't stop myself! Have any of you done any experiments with this? Do you know of / have any articles on this topic? If so - can you send me a link :)
3 comments:
You're definitely not the first one to dwell on this concept for any length of time. See Cary Millsap's note on it.
---- True, but I'm talking about actual Tray's of RAM. Your TempDb is pretty much a sandbox for the database, but thats where it gets its most writes. I'm more interested in that and performance of that!
I think the better research would be to see how much time is spent in tempDB reads and writes. There are a ton of fascinating improvements that can made to all sorts of things, but if the application is rotten at the core, it won't matter. The low-hanging fruit can probably be found in the application's code, where you can do WAY more significant improvements to response time on a case-by-case basis than you will every get by mucking with a tempdb.
Post a Comment