Category: Editorial

  • The Google Solution

    I was watching a talk from Google on how they back up their data. After all, one of the biggest assets Google has is the tremendous amount of data that they have collected over the years. There are many systems at Google, and certainly lots of data in each of them. In this case, Gmail was the system being discussed, and the data is in the exabyte range. If you don’t have an hour to watch the talk, then there’s a nice summary at highscalabilty.

    In the talk, there are certainly things that Google aims to do with their approach. First, they can’t lose data. That’s a priority, as it should be for all of us that manage data. They also focus on restores, not backups. In fact, if they can make restores easily by adding work and complexity to backups, that’s a trade-off worth making. I haven’t typically viewed the restore process this way, though I do think restores are ultimately the most important part of any recovery task. However, I haven’t really thought about how I could actually make restores easier by changing something at backup time. I’ve often tried to make backups quicker, or take them more often, but perhaps this is an area to re-examine. Are there things you can think of that would make restores easier? Maybe not easy enough for your cat to kick off (as discussed in the video), but easy for the average sysadmin at your company?

    Google wants redundancy, which includes people. They can’t depend on any one machine, one tape, or one person. Therefore, they need to have multiple copies of data and more automation that reduce those single points of failure. Along those lines, our clients and customers don’t need to know if we have 3 copies, 7 machines, or any other configuration. Our responsibility is to ensure our customers can access data.

    Why should we care what Google does with GMail or any of their systems? Well, I only see our databases growing, with sizes going from GB and millions of rows to TB and billions of rows, or even to PBs. There are lessons that we can learn about the management of data at scale, and the ways in which our customers might perceive the availability and accessibility of their information. Google has learned they need to be more efficient with resource usage. Whether that’s disks or people, they can’t require 1000 times more resources for 1000 times more data. We should take note of that.

    Perhaps the best lessons from Google are in the areas of testing and expectations. They test constantly, to ensure that they can actually recover data. While I think the SQL Server backup system is very solid, I’d be regularly testing restores to ensure that I really can recover from backup files, from external disks and tape, or even complete a restore on a backup system. The other lesson is that Google expects things to fail, so they plan for that, and aren’t surprised by failures. SQL Server gives us options here with Always On and other HA technologies if we can take advantage of them. With a single RDBMS instance, there isn’t a lot most of us can do, but we can at least be prepared to rebuild our instance elsewhere as a last resort.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Go Code

    Should we be teaching more people to code? That’s a question I ponder, especially after re-reading an old view against the idea, a newer one, and a pro-code piece. At the end of the day, I think that coding is a basic skill, similar to reading and writing because so many of us, perhaps most of us in the developed world, will need to work with computers.

    I don’t mean to imply that everyone should be able to write an MVC application or produce a graphical application. I also don’t expect most people to understand calculus or produce a thesis. However, I do want a core competency that allows them to work effectively with a checkbook and communicate a point effectively. I want them to understand enough coding to appreciate the logical and methodical way in which computers process instructions. I’d like to have most people appreciate how to create, store,  shuffle, and retrieve a digital deck of cards.

    Certainly I think that those people who continue to learn and advance in many industries can benefit from an understanding of what a database is, how to write a query that might logically fetch information. Even if you use a tool such as Excel, Power BI, Tableau, etc., knowing the ways in which we store information and need to process it can help you better work with the computing machines in your life.

    Perhaps seeing how easy it can be to produce bugs will help people also appreciate the need for better security. I’d hope this would also have them demanding that professional software developers produce better work. Quality matters, and while I might be able to build a car, I would expect that one produced by professionals would be of a much higher quality, and much more reliable than my own efforts.

    Having a basic understanding of how computers think will not only help us understand our systems better (or the people that design them), but can also help us develop thoughts and views on how we should reconcile the digital with analog world. I strongly feel that our understanding of, and the expectations we have in the analog world are very much inadequate for assessing a digital world that can accomplish things many people would have viewed as magic a few years ago. Certainly our legal structures aren’t well equipped to work in a digital era. To help us move forward, I’d like more people to understand computing.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Bring Solutions

    This editorial was originally published on Feb 13, 2013. It is being re-run as Steve is out of the office.

    What’s your job? Most of you will answer “DBA”, or “developer”, or “manager”, or something that corresponds to your title. That’s partially true, but for the most part if you are in Information Technology, I think your job is to solve problems. You should ensure that your systems, or your code, or whatever you work on, is running smoothly for the people that use them.

    That isn’t always possible. There will be times that things break, that bugs crop up or systems fail. When that happens, people don’t want to hear about the inherent problems, or even what went wrong. They might ask, and they might be curious, but really what they want to know is when will the system be fixed and what will it cost.

    I’ve never had a manager that was really interested in the problems that caused a failure when systems were down. I’ve rarely had managers interested in potential problems I’ve noticed in our organization. Managers might be curious about the issues, but they don’t want you to bring them problems. They want you to bring them solutions when you see a problem, multiple choices to fix things, and a recommendation for the option you feel is best. They want a solution that works well, doesn’t cost a lot, and can be implemented quickly.

    Competition for jobs gets more intense all the time and the employees that look for problems and provide solutions without being asked will be the most valuable. They will stand out from their peers and are more likely to not only keep their jobs during down times, but will get asked to solve the interesting and challenging problems.

    Steve Jones

     

  • What’s Your Backup Speed?

    I ran across a thread recently where someone was looking to estimate the time it too to perform a 600GB backup. I’ve seen other threads with similar questions. The general advice is that you need to run a backup and see how long it takes. After all, your hardware, your workload, the compression settings, and more will affect your backup.

    In researching speeds, I didn’t find much info out there, so I thought I’d start a poll. This might be fun for you, so I’m hoping quite a few of you will answer.

    How long does it take you to back up 1TB?

    I know some of you don’t have a 1TB database, and probably a few of you have much larger ones. However, look at your backup and extrapolate (or interpolate) the time it would take to complete a 1TB backup. Assume that your hardware would scale appropriately to allow you to run a 1TB backup if you actually had that much data.

    If you can share your setup, or your configuration, that would be very interesting. I know some of you use striped backups, some compress, some use third party tools to help, and maybe you even have another way to actually get data from a live system into a backup file.

    Over the years I’ve seen some amazing improvements in the backup and restore functionality that SQL Server provides. I think it’s one of the most solid subsystems in SQL Server, and I’m looking forward to seeing just how fast some of you can create backup files.

    Steve Jones

    The Voice of the DBA Podcast

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