Voice of the DBA

Category: Editorial

  • Reverse Engineering Disasters

    If you are responsible for managing systems, you should have some sort of disaster recovery plan. Even if you are only managing the one system you carry with you on a regular basis, you should ask the question: What would it take to destroy this data?

    It’s a good question, and in the post I’ve linked above, a technologist talks about some of the failings of disaster recovery plans because they forward engineer plans to recover systems. People think of specific problems and try to prevent them. They don’t reverse engineer to find out what events would cause them to lose their system.

    That’s really the key to a lot of design and architecture in computer science. You can’t think about just what you expect to happen, or even what you want to happen. You have to consider the other ways in which events could occur or the issues that could cause an problem in your system. In development, the things you expect are considered to be the happy path. A good architect or engineer will think about everything else in addition to the happy path.

    I sometimes think that far too many decisions are made while considering the happy path, but ignoring or discounting the other paths available. These other paths may be unlikely to occur, but having worked with computer for over 25 years, I can tell you that I often find the least likely events occurring far too frequently.

    As the author says, you should never say “I never even thought of that happening.” Consider reverse engineering problematic situations and then make a judgment of how likely is it that any of the events will occur. That way you have at some idea of what could go wrong and what events you are willing to protect against.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Smooth Database Deployment at SQL in the City 2014

    One of the themes at Red Gate Software this year has been “ship often, ship safe”. Actually, that’s been a theme (and goal) for us the last few years as we’ve learned how to build software faster, maintain quality, and get features into the hands of our customers. We’ve been working hard on expanding our knowledge , both through tools and education, to help our customers deliver their database software in a better way.

    Grant and I have traveled around the US giving free seminars on database development, deployment, and delivery, with ideas on how you can more easily manage your software pipeline. This fall, we’ve revamped our talks and added a new one on testing, and we’ll be delivering these talks at our 2014 SQL in the City events. We’ll be in London on Oct 24, 2014 and Seattle on Mon, Nov 3, 2014 talking about software, along with a number of our Friends of Red Gate. These will be full day conferences with a variety of DBA related topics featuring a number of speakers that are experts working with SQL Server. Quite a few of our developers and managers will also be available to share our knowledge about the process of building, testing, and deploying software, particularly database driven software. We’d also love to hear about your challenges and issues you face on a regular basis. If you can come, we’d love to meet you.

    Our events are a casual, fun, educational way to learn more about SQL Server. You’ll get ideas and tips for becoming a better developer or DBA that you will want to experiment with and put into place every day to make your job more enjoyable. We hope you join us at one of these events, or at one of our seminars in the future.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Testing is Your Best Investment

    I signed up for the FlowCon 2014 conference in San Francisco this September. It’s a two day event about software development and how we can do better. My job is starting to encompass more work in this area, and I’m excited to go see some of the ThoughtWorks developers talk about what they do well. Part of the reason I wanted to go came after watching a few videos from last year, including this one from Randy Shoup.

    There are some interesting things in the talk, but one thing really caught my eye at the 9:52 mark. Mr. Shoup made a statement that “tests help you go faster” and “the best investment you can make in your own code …[are] tests for your code.” Those statements are a short part of the talk, but they make a lot of sense to me.

    It’s easy to ignore testing, after all, it’s hard to test for everything that can possibly happen, and writing tests can be extremely tedious. However building tests JIT, when you find bugs or problems, can give you good code coverage, especially in the areas where you find developers are likely to make mistakes.

    And like with all other software development skills, the more you work on writing tests, the easier, and faster you become at building them.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • The Flash Database

    I caught this piece on the impact of flash storage on database engine design this week. It’s interesting as there’s been debate for years as to whether SQL Server should alter its behavior if it detects SSDs being used for storage instead of physical disks. It doesn’t, and perhaps that’s fine, though the article makes me think there are performance gains to be had if behavior changes.

    The article really looks at a few of the NoSQL products, though the design changes aren’t necessarily specifically limited to those products. I particularly thought that two ideas in the piece were interesting: indexes in memory with data on disk and the realization that threading can be he bottleneck with SSDs. I’m not sure if Windows and/or SQL Server could use these ideas, but they are interesting.

    I do wonder sometimes if a little more control of indexes would be helpful in SQL Server. Imagine if I could limit a large slice of memory to strictly non-clustered indexes and then have other data on SSDs. Would there be a way to tune SQL Server to run better for some workloads? Perhaps the algorithsm that choose query plans would change if they knew a scan of an NCI could be completed in a fraction of the time that a seek took place on a CI? Maybe we’d be willing to perform more seeks on in-memory indexes before performing lookups on disk.

    The idea of more concurrent operations, requiring more threads, also seems to be an area where I could suspect that both Windows Server and SQL Server could benefit from SSDs. If the systems changed their read and write algorithms and used many more threads with SSDs, could we get more throughput? Should our systems be more aware of how many controllers and paths might be on a system? I wonder, especially as some of this hardware becomes cheaper and cheaper. I could certainly see more organizations looking at using lots of smaller SSDs for a few servers that require high performance than a SAN.

    However it’s not as though SQL Server isn’t trying to take advantage of technology changes. The In-Memory OLTP system  and Buffer Pool Extensions in SQL Server 2014 are designed to take advantage of more memory and SSDs to dramatically improve performance. I don’t know what else might be coming in the next version of SQL Server, but I do hope that as new ideas emerge, SQL Server considers taking advantage of them.