Voice of the DBA

Category: Editorial

  • Accounting for Typos

    When I watched Star Trek as a kid, I was amazed by the technology. Talking to the computer, the touch screens, the handheld communicators. We have most of those devices now, without the space travel. Hopefully that will start to change with all the efforts being made by various organizations.

    One of the things that always bothered me was the chance for mistakes. A mis-spoken (or mis-heard) command to a computer that didn’t verify things as a human might. The chance to hit the wrong part of the screen as the starship moved. It seemed as though soft buttons would have allowed more mistakes than hard ones. Certainly humans make mistakes with physical switches, but I think I make more mistakes trying to hit a part of the screen in my Tesla than using one of the (few) buttons or wheels to change something. Interestingly enough, my 23 year old decided on a slightly older car because it had more physical buttons and fewer soft ones.

    We are human. Frail and faulty. We make mistakes. Some are small (I ran a SELECT query on the wrong database), some are bigger. A mistaken copy paste error sent US$36 million away. That is the type of mistake that could happen to any of us, though hopefully not at this scale of financial loss.

    This type of mistake is a main reason why I think DevOps and automated flows for development, testing, and even for production updates are a good idea. This doesn’t prevent human error, but it does serve to limit it and reduce silly mistakes. Often these types of errors are caught when we force someone to work through a bit of a process. An easy and quick process, but still a process.

    In the case in the article, you would hope that someone looking to make changes would write an update that can be tested in a second environment before applying to the production blockchain. Perhaps with some idempotent wrapper and a pre-check that verifies the target. That might seem like overkill, but it’s the type of care that most of us take when we know we aren’t going to be the one executing the code. If you submitted a script to a DevOps process, you’d want to be sure the process running your code made the proper decision of whether to run the code or stop because of some error.

    We won’t prevent all errors, but a lot of automation and light DevOps process is designed to limit simple, silly human errors because we are tired, distracted, or otherwise unfocused. I am a proponent of having humans design systems and processes, but then letting the computer handle the drudgery of following the process over and over on a regular basis.

    Steve Jones

     

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

  • Long Term Storage

    Data storage has always been a concern for data professionals. Early on in my career, we dealt with large ESDI, IDE, and SCSI drives, all of which would fail unexpectedly in servers. Sometimes after a few years, sometimes after a few weeks. We learned to use RAID and tape backups to ensure that our data was recoverable.

    In many places tape was the long term storage medium used. These days, I know many people have moved to secondary disk storage of some sort, often rotating data across a few disk types that give you recovery for days, weeks, or longer. I don’t know how long term storage work in Azure or AWS, but I assume some sort of combination of technologies are in use. I also know I don’t trust them completely to be readily available and recoverable after a few years.

    For most of us, database backups aren’t really relevant after some number of weeks or months. We usually just don’t need to recover things from long term storage. The exception might be for some types of data that do need to archived for legal or financial purposes. I know we used to keep a end of year tape for 7 years after we’d closed the financial records at one company. I don’t know if that would be the case today, especially with so many “digital records” of transactions. Would we really need to recreate a system as it looked on a particular day from 5 years ago?

    However, there are types of data that we might want to archive for a long time. An example might be the arts, where we have lots of music and video that can preserved. There might be other records, such as historical government records, which are suitable for WORM (write-once-read-many) systems.

    A new type of recording uses glass and may provide archival storage for thousands of years. Obviously we don’t know this is the case as we haven’t been recording digital information for thousands of years, but it’s an interesting medium. It also doesn’t require the algorithms to be maintained as the idea is machine learning systems can read back the data and learn to interpret it.

    To me, that might be the most interesting part of this project. Using computers to learn to read the data rather than requiring us to know have an MP3 player, a database system like SQL Server, or any other particular technology. Instead, we can let the computer learn how to read the data and then play back that recording of Prince in the year 3510.

    Steve Jones

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

  • Onboarding Remote Employees

    I guess that I was a remote employee that needed to onboard at a new company at one point. When Redgate Software bought SQL Server Central, I lived in Colorado and the company was (mostly) in Cambridge, UK. However, I was hired mostly to continue the same work I did at SQL Server Central, so I didn’t really on board with the company. I signed a contract, and set up payroll paperwork, and that was it. I used my same workstation and laptop, albeit with a new account, password, and VPN, but almost everything was the same for me.

    Over the last two years, we’ve hired many people at Redgate, with most of them being brought onboard remotely. Plenty of them have never seen any of our offices, and quite a few didn’t meet any other employee in person for months. Our blog posted a couple of stories from people we’ve hired in the last year about the remote onboarding process.

    The stories are a bit light on details, but I know that we send out packets of info and boxes of equipment to people, and we use Zoom and Slack extensively to help people get themselves configured and set up for work. I also know that our managers are good about regularly reaching out to people and connecting them with resources if they need assistance.

    For many technical people, I think getting a pre-configured machine and then credentials would allow us to get working easily. A URL or path to source code and server names ensure we can work on a database or a set of code. Asking a few questions of current employees should solve any minor issues with connecting to development resources.

    I don’t envy anyone that starts a new job without being able to see or talk to someone in person at a new company, doing new work. However, I do think this is a process that is likely to continue for some time. Even those companies that have open offices and employees available likely have learned how to send someone packages and get them productive quickly without needing to schedule everything face to face. Even most signatures can be handled electronically these days.

    I do think we miss something by not getting together, at least periodically. I know I enjoy traveling to the Redgate offices, and I think most people would gain something from being in the same room as their co-workers some of the time.

    Steve Jones

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

  • Better Communication of Information

    Many of us work with data in some way that helps a customer better understand data, use it to make a decision, or support a some conclusion. The way we present data (or help others present data) can impact how well a consumer understands the information represented by the data. There are people whose job it is to design visualizations and ensure the final product communicates well, but often I find a developer or DBA is the person that gets asked for help.

    What do we recommend when looking at a set of data and deciding how to format it? A few posts I saw recently help with decisions (when should I use a map) or basic knowledge (what is a square chart). I’ve seen presentations that help me understand the impact of my decisions and how to better design my informative reports for more people. In fact, I hope more people produce content on how and why they have built reports. It’s helpful for many of us that would like to do a better job.

    The other side of this is actually producing some report and then getting feedback on it. I’ve been working on a report for the kids I coach and need to write some blogs on the way I’ve built report and how I think others might use it. I certainly could use some feedback and I know someone will have suggestions on how to better structure a report, color it, choose a different style, or something else.

    I might even get some better feedback on how I chose to store the data. That certainly isn’t a set or known thing, and I would guess that there are some things I haven’t thought about in building a structure.

    Ultimately there is information to be gleaned from the data we capture, store, and manage. While it might not be our job to help convey that information, we are a part of the process and the more we know about it, the more we might do our jobs better, or help others do theirs better. I do hope that I see more posts on not only how to query information and solve problems but how to better present the data from those queries.

    I’m looking forward to some blog posts, articles, or maybe even someone hosting a T-SQL Tuesday on this topic.

    Steve Jones

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