Voice of the DBA

Author: way0utwest

  • Data Loss

    This piece was originally published in Database Weekly.

    Are SSDs less reliable?
    Are SSDs less reliable?

    Two words that no database administrator ever wants to put together are “data” and loss”. We go to great efforts to ensure that our SQL Server data is protected, backed up, available on alternate systems, even replicated to remote machines. Our goal is always to have zero data loss in all situations, even in those situations where we cannot prevent downtime from occurring.

    This past week an article at InfoWorld caught me eye with the phrase “solid-state drives suffer data loss” in the subtitle. The article is written about a study from HP Labs and Ohio State University that studied the effects of power loss on various SSDs. Using a number of “enterprise quality” SSDs from various manufacturers, the authors of the study cut power to the drives while they were in use, a scenario that I’d expect would happen periodically to systems. We reboot all kinds of systems at times without shutting them down at times, for a variety of reasons. I’d expect that file systems and low level software would properly handle these situations in a manner similar to SQL Server, with some sort of recovery running when power was reapplied.

    In the study, there were six potential failure types, and of the fifteen manufacturers whose drives were used, five of these failures occurred. The susceptibility of various kinds of corruption to power faults led the authors to conclude that systems with critical data should not use SSDs, test them thoroughly since they were not aware of ways to design a storage system to account for these potential issues. They did not say that SSDs were more unreliable than hard drives, but in this specific type of disaster, unexpected power loss, there could be problems.

    We can design around these issues somewhat with redundant UPSes, battery backing of SSD cards and more, but disasters in the form of an accident can occur. I’ve seen two occasions where large data centers lost power because of maintenance work on power distribution units resulted in improper fail overs. The more complex our system design becomes, and the more we use SSDs in databases, the more likely for some failure or corruption to occur.

    I wouldn’t panic and remove SSDs from systems, but I would ensure that any disaster recovery processes and procedures I had were up to date and working. You never know when you will need to recover from hardware issues on a primary system and have to restore on completely separate hardware. Advance preparations and practice are the only way to ensure you can successfully recover when the need arises.

    Steve Jones

  • Come Learn at SQL Intersection, Get a Surface Tablet

    This spring I’m speaking at the SQL Intersection conference. It’s a new conference, managed by SQLskills founders Kimberly Tripp and Paul Randal. It’s April 8-11 in Las Vegas, and it’s got a slew of amazing speakers that I’ll be alongside, including Brent Ozar, Grant Fritchey, and more.

    If you register today, and attend one of the pre- or post-conference sessions, and there are some great ones in the SQL Server space, you’ll get a Surface RT Tablet. It’s a great tool to use for mobile work, taking notes at events, in meetings, or even walking around your office.

    The tablet isn’t a reason to attend the conference, but it’s a nice bonus. And it will help you, since you’ll want to take lots of notes in the sessions. All of the speakers are experienced professionals, working with SQL Server and bringing a ton of experience to their talks. There are talks about new features and old ones, best practices, and practical advice.

    If you’re looking to learn this spring, think about coming to SQL Intersection this spring.

    Learning by day, Entertainment at night.

  • Does Connect Work?

    Sometimes I wonder if the Connect bug reporting system is really working.
    Sometimes I wonder if the Connect bug reporting system is really working.

    I had a brief conversation on Twitter about the Microsoft Connect bug reporting system, and received the tweet pictured above. It notes: “I like how you used ‘Connect works’ in that sentence. Great work of fiction.” That made me laugh because it does sometimes seem that Connect doesn’t work all that well for those of us that use it.

    Connect was supposed to be a place where users could report bugs and make suggestions. Some people file a lot of bugs and suggestions, though more than a few seem slightly silly. Others file what appear to be support requests, and I’ve had a number of documentation notes. There are even Connect items filed on Connect itself, though I can’t understand why this particular one is “postponed”. There are some items that have been open for years, even with hundreds of votes.

    The Connect system is supposed to feed directly to product groups and there are more than a few times I’ve received feedback through the system from developers I know personally that provide comments. I know developers are seeing the items, but there appear to be a few times of year when the SQL Server group mass closes lots of Connect items, often without any feedback. The twitter conversation I had above included one of these items.

    I remember being excited when Connect was introduced, thinking this would be a good way to get feedback to the product groups, and hopefully influence the managers to prioritize some of the common requests. However that excitement was tempered with the idea that so many items would be submitted, and it would be hard to triage and rank them. Indeed, I rarely find something in the searches I make before submitting, even I’ll have submissions closed as duplicate.  The number of items submitted is so high, it’s hard to even comprehend how any group works with the submissions.

    With the state of Connect, the lack of feedback, and the mass closures, I’m not sure how well Connect is working these days. However it’s not all bad; I did submit one item that received enough votes to actually make a change in MS policy. Outside of that, I think @SirSQL’s statement might be closer to the truth than I would hope.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Why SQL Server?

    I love this logo, and I love working with SQL Server.
    I love this logo, and I love working with SQL Server.

    Over the last few months I’ve met quite a few people that were just starting to work with SQL Server. For many of them, they’ve attended talks or presentations of mine or others, trying to learn enough to become more competent at their jobs. As is the case for many people starting out with a technology, they were thrown into it at their job and are struggling to understand the technology.

    That’s how I started, but I’m wondering if that’s how most of you started. I would guess most of us didn’t necessarily choose to work with this platform, but since that time, many of us have had other choices. This Friday, I wanted to ask about your work in the SQL Server world and participation at SQLServerCentral.

    Why do you work with SQL Server?

    It’s a simple question, but one that many of you might not think about. Are you stuck with SQL Server? Did you fall into this role and enjoy it? Or have you never considered moving on? A lot of people get stuck in ruts, especially ones that work well for them, without ever considering other options.

    For me, I fell into SQL Server when an instance was installed on my Novell network. I enjoyed working with sets of data and was amazed at how much easier it was to work with SQL Server than Oracle, and how much better performance was over dBase. It didn’t hurt that the pay for database work was great, but I have enjoyed working with SQL Server, and with short forays into the DB2, Oracle, and MySQL worlds, I’ve learned that I enjoy SQL Server more.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.