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.
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 PLF. To get an idea of what it’s like, check out the 2012 trailer.
Brent Ozar
Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.
Follow Me:
Dude you’re hilarious! I’m loving the hot / crazy analogy.
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 ?
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.
Chris – we discuss the full details on the cruise, but I’ll give you two hints: dynamic disks and virtualization.
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.
[...] SQL on SSDs: Hot and Crazy Love - Here with another video for you to enjoy, this time looking at SSDs it’s Brent Ozar (Blog|Twitter). [...]