Voice of the DBA

Category: Editorial

  • Rebooting for a Reason

    I’ve worked with computers for a long time. I’ve helped support various systems and applications, both desktop and servers. One of the most common tricks that has served me well is to press to oh-en-oh-eff-eff switch twice.

    In other words, reboot.

    This is advice that many tech support people use. It’s what is often recommended for everything from personal computers to mobile devices to watches to really any sort of microchip device. It’s been recommended for my Tesla and for a few appliances as well.

    It’s also incredibly frustrating advice to hear that when we expect a device to run constantly, like a watch. Why should I reboot it? Isn’t your code bad? Isn’t it the manufacturer’s fault? Isn’t this a cop-out to get me off the phone/chat/etc. and close out a call?

    This is likely bad code, and it might be a way to get you off the phone, but there is some rationale behind this troubleshooting step. I ran across this article on the unreasonable effectiveness of turning computers off and on again. It provides some reasoning why rebooting makes sense and why it can help. The short answer is this action returns the code and device to a known state. Often when things are broken, we’re in an unknown state.

    There’s also an interesting parable about writing a shell that is very strict with its evaluation of input and crashing when things aren’t right. The author wrote another shell that is loose in its evaluation of input. Read the piece to see which shell actually made more sense to the programmer.

    I found this interesting and fun to read, and it made me feel better about needing to reboot systems. Less excited about the need to reboot a car or a plane (I’ve been on a 787 when it rebooted), but since I’ve seen the former continue to work, I’m less anxious. Take a look today and let me know if this article makes you feel a little more comfortable with giving out the “reboot” solution to others.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Home Setup

    For many years, a home setup has been something us geeky people built to experiment, have fun, maybe play games, maybe for some career learning away from work. I’ve written about various workstations, as has Glenn Berry.

    Then the pandemic hit and many of us were sent home to work. I’ve seen people working on dining tables, coffee tables in living rooms, and even on a spare dresser in a bedroom. I see big and small offices, many of which were thrown together to just get by in the spring of 2020.

    It’s a few years later, and while I wrote about the ultimate home office in July 2020, I know that there are plenty of you still at home, at least part-time. While some companies want to get people back into the office, I don’t know how many people end up working full time in an office with the need for some setup at home.

    I saw recently that Andy Yun was building a home lab for himself and his wife, Deborah Melkin (send congrats to the newlyweds! Hopefully, Andy and Deborah have nice working spaces at home, and they don’t interfere with each other. My wife and shared an office for a few years, and we both had to learn to grab a laptop and leave if the other was on a call first.

    This week I wonder how you’ve changed your setup at home? Have you set up a dedicated space for work, a desk, a new chair, better lighting or larger monitors? What tips do you have for making a home office a real office?

    Let us know what has worked, and maybe what hasn’t. Or better yet, what do you wish you had known in the spring of 2020 when you first moved into your home instead of the office?

    Steve Jones

  • Flexibility in DR

    Disaster recovery is a topic that many people who work with databases find important. DBAs work to ensure their systems are highly available while practicing the skills needed to recover them in the event of a disaster. While we often practice the failure of a complete server or database, we sometimes forget there can be other issues for which we need to plan.

    I ran across a story about a data center outage in London, which was similar to an incident I experienced. In this case, a piece of power equipment failed and systems lost network access. While many of us aren’t responsible for the network, we certainly would still receive complaints if the database wasn’t available.

    In my situation, I was in a data center watching some workman service UPS systems. At the time I was a manager of database systems and thought they had things under control. I left the data center and went downstairs, only to audibly notice when the power dropped that all servers seemed to stop running. Similar to the London outage, a switch that was supposed to change power from one set of UPSes to the other failed. Our entire global infrastructure for 10,000+ people and who knows how many customers went down. This was in the pre-cloud era where we acted as our own cloud. And not very well.

    There are systems outside of our databases that we depend on. We might not be responsible for them, but we ought to ensure they are a part of our disaster recovery plans and account for various things going wrong. At the very least, we ought to question whether power, network, storage, and more are adequately prepared for major issues.

    We also need to think about minor issues. Atlassian had a major outage, at least for some customers, and they realized that they hadn’t planned to recover parts of their databases. A similar issue might occur for any of us, where we might have to restore parts of a database, whether that’s a table, partition, or a series of rows. Corruption or human error might result in a set of data that’s unreadable or even gone. I know I’ve accidentally caused data issues, and I’m careful. I learned to recover from my own mistakes and anticipate those of others. I practice not only full restores but how to copy over part of table from another location.

    A disaster is a major problem, but it might only affect a minor part of our systems. We need to ensure we are ready for any size or scale of problem and be ready to adapt our thinking and process to meet the disaster with the appropriate actions.

    Steve Jones

  • Be Smart

    An engineer at Google recently claimed that one of the AI chatbots might have become sentient. Great headlines, and whether true or not, this might bring some notoriety to the engineer.. It certainly did, and it also resulted in the engineer being suspended from his job. It’s entirely possible this person might be fired. Perhaps I’m cynical, but I think the more talented he is, the more likely he keeps his job. Less talented, likely fired. This might not be fair, but I am a realist. The more value someone brings, the more tolerance for missteps.

    I give a talk on branding, and one of the things I do before giving you practical tips is to remind you to be cautious. A brand can be a very positive asset, but it can be a detriment as well. One of my stories is about Mark Jen, who Google fired after he blogged a few things about his employment. He was highly recruited and worked at Google for only a few days.

    At one point I worked in a public company, in a large Operations group of about 20 people. We were listening to the earnings call one quarter when Security staff walked up and escorted a person out of the building that was sitting 2 or 3 cubicles away from me. They security people then returned to box up the employee’s belongings once he was gone. Apparently our boss told us this person had posted some of our earnings results online while the call was going on. They were posted literally minutes (20 or 30) before the numbers were announced, however, that’s illegal and a violation of securities rules.

    Most of us know not to post passwords, IP addresses, or other sensitive infrastructure data on the Internet. Most of us should know not to post data, especially on a site like SQL Server Central. If we are looking for help with an issue, we need to mock up a situation. We might not be able to post code, and we might not be able to write about the specifics of our job in our blog. That might vary by company, and we need to understand what the rules are.

    I’ve never had an issue with this in over 25 years of blogging and asking/answering questions on forums., but I’ve followed one rule. It’s the same rule I heard someone say was their internal guidance for blogging.

    Be Smart.

    Don’t post anything that might cause an issue. Whether you are in a forum or on your blog. Even inside your company, some information might be sensitive and compartmentalized. If you have a doubt, ask someone. It’s that simple. Just ask someone who can give you a second opinion.

    I do this regularly with SQL Server information and Microsoft. There are times that I am unsure of something is under an NDA, so I ask. This includes words, pictures, and code. I do the same thing at Redgate, as sometimes things on our internal network might not be publicly released yet, so I just ask. On my personal accounts, I might ask my wife if I can post something before I do it. I’ve learned it’s better to ask permission in these cases.

    I haven’t always done that in my job. Sometimes rebooting a system or making a minor change without following every rule, but those have been cases where I had a very strong understanding of the situation and the implications of my actions. It’s not something I do lightly, and it’s rare, but there are times to ask for forgiveness rather than permission.

    However when dealing with public disclosure of anything, I think you are smarter to ask permission first.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.