Voice of the DBA

Author: way0utwest

  • DR Planning

    Data professionals know that protecting and ensuring our data is safe is one of our primary jobs. Many of us worry that if we were unable to recover a database, our job might be jeopardy, which makes sense. If we lose data, an organization might make the decision that we aren’t trustworthy enough to manage a database system. This leads many of us to plan and prepare for different types of disasters, with procedures and systems in place to ensure that we can quickly get things running after an issue.

    Natural disasters, or other large scale disruptions of business sometimes exceed the plans we’ve put into place. Fortunately they’re rare, but I ran across an article that talks about a few items that we might not consider when making plans. Even if you can fail your database over with an Availability Group running in another location, there are still some points you might want to think about.

    Perhaps the biggest one for me is that testing is not optional. I’ve seen some amazing plans put into place, but never tested because no one wanted to disrupt ongoing business activities. Testing is really critical, perhaps because of the second more important item I see cause issues: failback. This isn’t always as simple as we’d like, even with some of the amazing work that Microsoft has done with SQL Server. We want to ensure that we do know that if something happens to our primary systems and we move them, we can come back. After all, these are the primary systems for a reason.

    While other items such as making DR planning something your organization cares about can matter, I think the viability of this depends on how likely these disasters are. If you’re in a seasonal hurricane path, or some other disaster, you likely need to have better plans than if you’re in a stable region. Not that you can avoid any plans, but most of the time a disaster is a rare event and it’s really IT’s job to ensure that systems are resilient.

    I do think it is worth noting that regulatory compliance isn’t optional. While your auditor might have sympathy if they are likewise affected by the disaster, that sympathy dissipates over time. A disaster next month might not factor into an audit review in 20 months. More laws are on the books and more are coming than most of us have dealt with in the past. Design your system and process to be compliant, even in a disaster.

    Lastly, the people side of business can’t be emphasized enough. While some of us might be expected to shoulder a greater workload during a disaster, keep in mind that we would still need support outside of work, perhaps even a replacement worker to handle some of our work tasks or even help with personal items. The longer our lives are disrupted, the less likely we are to work as hard, or remain focused. Part of any plan should be how can our organization help support those that are struggling themselves. After all, the effects of a localized disaster on business could get compounded if staff stops coming to work.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Learning for Feb

    By the time you read this, I’ll have decided, but I just finished the first book and need to pick another. This post is more for me than anyone else, helping me to sit down and think for a minute.

    I don’t have any pressing need to work on any of the other books for work or career. It’s more that I’m interested in various topics, so I need to pick a direction. I’m also cognizant of the future and which books I want to go through.

    Recap

    Here are the books I purchased and plan to read this year:

    The question is, what’s next?

    I’m really not sure, but I do know that I’ll be relatively less busy in February, really busy in March, and April will likely be like January. As a result, I want an easier book in March.

    The challenge for me is understanding what’s easy and hard. I think the Azure/Xamarin one will be hard as I’ll need to practice skills that aren’t useful or tangential to work. The Power BI stuff is likely the opposite. The Python stuff is probably in the middle.

    The Plan

    My thoughts right now are that I need to research for a couple days. It’s Jan 31 as I write this, and I’m on vacation for a couple days. That’s both good and bad. Bad because I want to get away, good because I can find some spare time to just read and no do.

    With that in mind, I’m going to read a chapter of 3-4 books and then decide in which direction to go. By the time this publishes Monday, I should have made a choice, but I’ll be busy working on other stuff, so I won’t get to update this post.

    The four to get through a chapter on are:

    Wish me luck.

  • Why Change?

    I was reading Change is Hard from Jeff Hackert and I started to think about the ways in which I both change and resist change. I then started to think about the ways in which I ask people to change what they’re doing. I do this both at work and in life, with mixed levels of success. The one thing the article got me to think about was the idea that in asking someone to change, I’m implying they are doing something poorly, or wrong, already.

    In some cases, that’s true. When I coach volleyball, I am often telling someone they are not practicing a technique correctly, and they need to change. The trick here is showing them what they are actually doing, since many of us don’t realize when we are moving our body incorrectly. We think we’re doing what we were told, and often it’s only with video evidence do we realize what we’re doing wrong. Once we do, it becomes easier to make corrections.

    In technology, this is often more nebulous. There isn’t often a set way that we should write code. Requirements vary, our schemas and data differ, and we almost always have disparate (and often not enough) indexes. Asking someone to change could very well mean asking them to admit they built something incorrectly. Sometimes we may do that, but often we have confidence in our work. Asking someone else to change how they build or develop software can be hard.

    What can even be harder is getting management to change. We often feel pressure from management, who usually see our systems working well enough. While we may see sub-optimal performance, they see business getting completed. While we see stress and long hours, they see work getting done at the same cost. Changing priorities to improve our applications often becomes secondary when potential new features and functions exist. Telling management they’re wrong is not only difficult, it’s often fruitless.

    Change is hard. Most humans like the status quo to continue indefinitely, even when we know that things can improve with some alteration in our routine. Inspiring others to join in and invest for the future is a skill. It’s one that I’d encourage you to develop, both with peers and management.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Pros and Cons of Terabyte Phones

    A few years ago I wrote a piece about the growth of storage in many devices and the large quantities of data that can be kept. I speculated that we might see terabyte mobile phone storage in a decade. That was 2014 and this past week Samsung announced they had created a 1TB embedded Universal Flash Storage chip for phones. You can already get a Note9 with 512GB of storage, so this isn’t a huge leap, but it does feel like a milestone.

    For many of us, that seems like a good move. We can keep all the photos, videos, movies, and more that we want on our phones. I take a lot of pictures in life, and lately I’ve struggled with a 32GB phone. I keep debating upgrading, just because I’d like more storage. There are certainly challenges with keeping all this imagery and video backed up, but that’s a separate discussion. I’d like to just be able to capture data and make decisions about how to protect it later. There are also plenty of transient items (movies, Pluralsight courses, and more) that I just want to keep on temporary storage for a limited time.

    More is better, but it also creates potential problems. With a 1TB, or potentially larger, storage on my phone, what about the problem of data loss and theft by insiders? Very few of us work in jobs where we can’t keep our mobile device with us. Many of us also work with sensitive data, and there is a potential for transferring a lot of data to a relatively innocuous device. These days we might not even need to plug in our mobiles with bluetooth file transfer programs. Even if we plug in a phone, that’s innocent and expected? Modern smartphones often need charging during the day.

    It’s not just us, but also contractors, consultants, and non-privileged users that might be able to move data. Certainly someone might act maliciously, but what about the potential for new types of malware? Android is more open and iOS, and there have been viruses. How long before there are some virus programs that try to connect to every SQL Server, Oracle, MySQL, etc. database when plugged into your laptop?

    That might seem far fetched, and certainly our databases grow larger and larger, but much of the data is text, and more ERP/CRM programs are in use that contain known schemas where worms, virii, and other malware might target specific tables. A terabyte can store a lot of text data, especially if it’s usernames and password hashes.

    I don’t know of any mobile to PC infections yet, but I do know there are lots of smart people out there. It’s just a matter of time before someone starts to try and exploit the capabilities of modern mobile devices, especially those with large storage capacities.

    Steve Jones