Voice of the DBA

Category: Editorial

  • Remember the Simple Things

    This is a hardware post, and not at all database related, but it reminds me of troubleshooting problems in my career, and of a lesson that I thought I’d learned well. Apparently that isn’t the case.

    Over the last year I’ve been using a tablet to record my daughter’s volleyball matches. We’ve saved off the video between matches, often uploading it or sending it to college coaches. After the season, the tablet wasn’t used much, mostly for some movies on trips, but often it sat idle. Not too long ago a software update appeared for the Android operating system and I applied it, promptly forgetting about this.

    I recorded a couple matches earlier this year, but was too busy to download the video. As I was getting ready for a match last week, I realized that I needed to copy some of the video off the device to free up space. I connected it with a USB cable to my PC and …

    Nothing.

    No device appeared, and I couldn’t access video. I played with the settings in Android, even tried some software from Samsung. Nothing worked. I had read that modern versions of Android included some protection from random USB connections, so I ended up prying open the rubber case, removing the small SD card, cursing a few times as I tried to find a micro adapter to read it, watching the clock the entire time. Rushing to copy video and get out the door in time to make the match is not the least stressful part of my life.

    The next day I ran more searches, trying to find a way to connect remotely to the tablet from a Windows device. I kept seeing references that enabling the device visibility should work and Windows should detect the file system. It didn’t work, and this was frustrating. I was ready to purchase some software to allow remote connections to the device.

    Finally, I saw a note that some cables don’t allow data transfer. Apparently a micro USB cable is not a micro USB cable. I decided to try another one I had laying around, but no change. I did notice the message that the device was charging slowly, so I wandered through my desk to find the original cable that came with the tablet. I connected it and

    Voila.

    I had a file system to which I could copy video. I felt both relieved and rather ashamed of myself. I can’t remember the number of printer problems I’ve solved in my career by changing cables. Or the number of times a motherboard wouldn’t boot, but changing a power cable fixed the issue.

    Consider the simple things first when troubleshooting. They won’t always solve your issue, but if they do, you’ll be glad you tried them first.

    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.

  • The Single Pane of Glass

    One of the things that I’ve seen talked about quite in the DevOps movement is a single pane of glass. That phrase seems to be in use to describe a way of quickly understanding the state of your environment. It could be the view of the software versions deployed in environments throughout the development process or the status and capabilities of your infrastructure. In either case, it’s a holistic view of your portion of the organization.

    I don’t think this is much different from the idea of a global dashboard that might be produced for business people. I’ve seen no shortage of those during my career. Certainly lots of business intelligence projects have been based on the idea of a single view of data that provides insight and assists decision making. Those ideas have been adopted by plenty of organizations that are moving to a DevOps process for software development.

    I’m wondering if any of you have a dashboard for your particular job? This could be in infrastructure as a DBA, where you have a single view of your database servers, maybe status and alerts? Perhaps you just a monitoring system like SQL Monitor to keep track of important data related to all the instances under your responsibility. Perhaps you have custom information important for your organization such as the flow of data in ETL processes, numbers of transactions, or some other measures to measure health or performance.

    Maybe you’re a developer that wants to know the status of all builds for the various projects under active development. As teams look to produce more reliable software, they often want to know the where their changes are deployed, if the code passes all tests, and even which work items are in which states. Azure Boards or DLM Dashboard are examples of how teams keep track of their responsibilities.

    There are any number of ways that organizations can keep an eye on the state of their systems, but I do think that any high performing group will have some way of measuring their work. After all, if you don’t know the state of your system, how can you determine if you’re getting better or worse.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Start the DevOps Journey

    More and more, I find that getting someone’s mindset to change is the major impediment to changing to a DevOps process. Once a person starts to believe in DevOps and accept a new way of working, they can rapidly start to improve the efficiency of their work. Moving on to change the mindset of a team (or teams) is even harder, but this is arguably the most important part of changing your software development process.

    I don’t have a great way of changing everyone’s mindset, but if you want to start, I have a thought for you that might add a little work, but will help you understand how to make changes in the way you work and experiment with a better way to deploy database changes.

    The tools are the easy part, and I want to help you get comfortable because the harder part is then trusting your process and helping others to learn how to trust a DevOps flow as well. To get you to start that journey, you need to learn one skill: how to execute your changes from the command line.

    That’s it. Think about how you will manually execute your tasks now, and then ensure there are command line execution processes for these. This could be a call to SQLCMD with a filename as a parameter or it could be a DACPAC deployment with sqlpackage.exe. If you are a Redgate customer, we have PoSh cmdlets for deploying changes with SQL Change Automation or command line SQL Compare calls.

    A command line interface (CLI) is really the key for the DevOps toolset to succeed. That’s only a small part of the process, since you need cultural change, you need to still model your database well and write good code, and you still need to learn how to improve your code over time. Adding a DevOps process allows you to spend time on code quality, testing, and skill improvement, instead of assembling changes and files for that next deployment.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Cloud Backup

    I think that backup and restore are the most critical things for any database professional to master. Whether you’re a professional DBA, a developer setting up a system, or a seasoned DBA, I would argue having your data safe is the primary task. Security comes next, then performance, availability, and a number of other tasks that could go in any order, but if we don’t have a way to restore our data when hardware fails, we’re in trouble. And given enough time, or enough difference pieces and parts, something will fail. If you can’t restore a system when a problem occurs, that’s what Grant would call an RGE.

    Over the years companies have moved to many different technologies to handle backups. Tape was common early in my career, but all disk systems, with de-duplication capabilities have become popular. I really don’t think about anything other than getting a second (or third) copy of data these days, so I can’t speak to any particular way of managing backups. However, for SQL Server, I do want the option to set full, differential, and log backups based on my RPO and RTO requirements.

    There seems to be a new trend for companies that I ran across: they’re moving to the cloud. Here’s a short slideshow of some stats that show cloud use is increasing. This is a survey, so it’s not all companies, but the trends are clear. More data is being backed up, and it’s likely easier (and cheaper) to use cold storage in the cloud. That makes sense since it’s data that you expect you’ll very rarely need to use in a restore.

    There are a couple of other interesting items I saw in the survey. The number of companies that are backing up more than 100TB grew quite a bit, even as the number of companies backing up < 25TB fell. That’s a sign that we’re capturing more data. Whether we need to, or whether legislation like the GDPR will get companies to trim some of that data, remains to be seen.

    Another interesting item is that more companies are testing their DR plans. Fewer never test them, but the frequency is increasing with more companies testing quarterly or monthly. That’s smart as we become more dependent on computer systems. I know some organizations can’t roll back to paper, as we’ve seen in a number of airline IT issues. If you never test your DR plan, I hope that you don’t have an issue when you can ill afford to find another job, becuase you might suffer those consequences. Really, I hope that you actually know this isn’t professional and you start working on ways to test a restore of service.

    More companies are moving to the cloud, and the resistance for security, cost, privacy, etc. reasons is going down. I think many of the concerns that both executives and IT professionals have had in the past are proving to be non-issues. This is especially true as more vendors institute government rated or more secure data centers as a part of their product offering.

    If you don’t like the cloud, that’s fine. If you don’t know anything about it except rumor, guesses, or hearsay, I’d suggest you learn more. The cloud is likely coming into your career, so learn a bit about it. At least enough to give reasons why you don’t want to move your data there. If you do, you might be surprised that the cloud is not that bad a place to be, at least for some workloads.

    Steve Jones

    The Voice of the DBA Podcast

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