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.
Jon Morisi February 17, 2012 | 10:21 am
Dude you’re hilarious! I’m loving the hot / crazy analogy.
Chris Adkin February 19, 2012 | 6:37 am
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 ?
Chris Adkin February 19, 2012 | 7:05 am
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.
Brent Ozar February 19, 2012 | 7:37 am
Chris – we discuss the full details on the cruise, but I’ll give you two hints: dynamic disks and virtualization.
David Ames February 19, 2012 | 2:53 pm
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.
Brent Ozar February 19, 2012 | 4:00 pm
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.
Pingback: Something for the Weekend – SQL Server Links 24/02/12
Jeff Basso June 13, 2012 | 11:01 pm
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.
Pingback: [SIMS] Speeding up SIMS - Page 2
Pingback: SSDs for Server