Blog

SQL Server and SSD make for a hot and crazy relationship. In this webcast, you’ll learn about the wild obsession of the database and solid state storage. It might just be time for you to consider the siren song of the SSD, but know what a dangerous mistress she can be. http://www.youtube.com/watch?v=FVPmsrXpKjI This session is a subset of a 2-hour presentation Brent’s doing on SQLCruise 2012.  Come join us – there’s still a few spots left on the May 26th cruise to Alaska.  The training is $895, and your cabin is as low as $850 per person for double occupancy.  Often companies pay for their employees’ training cost and let them go without taking vacation time, and the employee’s just responsible for the cruise & airfare costs.  It’s a pretty fun way to learn a lot and network with some great presenters, including all of Brent Ozar Unlimited®.  To get an idea of what it’s like, check out the 2012 trailer.

↑ Back to top
  1. Dude you’re hilarious! I’m loving the hot / crazy analogy.

  2. What was the reason behind the erratic writes times to the tempdb files on the flash PCIe card ?, was this a combination of cell wear and write amplification ?

  3. This is a bit high brow, but a good explanation of the SSD “Write cliff”: http://bit.ly/nml7vO and might be a factor in the tempdb datafile write performance issue you mentioned.

  4. Brent, what are your thoughts on using a single FusionIO card for tempDB on each node of a cluster? IE, in case of cluster failure, you “recover” by failing over the cluster to the other node and swapping out the card.

    • David – it’s totally up to the business, not the DBA. If the business is okay with having SQL Server fail over when a single part fails, then a single FusionIO makes sense for TempDB in that kind of cluster scenario. I’ve seen scenarios where the business was okay with a single SSD in one node, and magnetic storage in the other node to act as the failover – and also scenarios with paired SSDs in each node because the business needed multi-instance (active/active) clustering with fully redundant TempDB storage in both nodes. Us IT guys are here to serve the business’s speed & reliability requirements.

  5. Pingback: Something for the Weekend – SQL Server Links 24/02/12

  6. When we started to look at SSD we figured out a way to stop the “fail at once” issue. Swap drives out of the raid controller one a month for the first 12 months. The issue we had as reading health of the drive behind the raid. Now that we plan on reading the health of the drive once pulled (not behind the raid) we can feel somewhat comfortable that we will not loose all of them at once.

  7. Pingback: [SIMS] Speeding up SIMS - Page 2

  8. Pingback: SSDs for Server

  9. Hi Brent,
    I’m looking to experiment with some of your advice about moving TempDB off to SSD’s. Dell have told us that we can only use the enterprise level for our Dell R710’s… I’m a little dubious ! I read a couple of articles that a number of commodity SATA drives will work on a SAS controller.. any advice on how we could implement your suggestion as at 1300 quid a pop, Dell’s ones are a non starter as I guess you need at least 3..

  10. Just want to thank you…it’s about one of the things i learned from one of your videos…i was able to use it earlier today…More power to you Brent! :)

  11. Thanks Brent!

    Here’s another site that does good comparisons : http://www.harddrivebenchmark.net/
    Also gives a drive rating / price chart, which shows best value for the money drives.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

css.php