Voice of the DBA

Category: Editorial

  • Easily Repeating Work

    I love this idea from Ken Fisher: saving your work. I don’t act as a DBA anymore, but when I did, I did something similar. We often logged the scripts we used in a file,  as a part of a log, so that if we broke something and another DBA got a new ticket, they could check what you had done. Over the years, we tried two different methods. First was using the desktop of the instance itself, since we often went to a room to log into the server in those days

    The second way was in an Exchange public folder, where we added a new entry for each day. This way we could note the server and the scripts run. Since most tickets were dated, we could easily find the scripts if we were looking at a ticket. Since a user often updated or re-opened the ticket, we could use the public folder as a central note location from the DBA team. We could even point to this folder for our ISO and SOX auditors to show them what had been logged by people who supported the systems. Not a perfect auditing system, but one that often was accepted by auditors.

    However, the one thing missing in there, from my perspective, is version control. While I think it is important to track these scripts in a team of DBAs, I also think we want to ensure that as we grow and change these scripts, we know how and why. Junior people can learn from changes made by senior ones, and if a DBA alters one of these scripts and breaks something, just as a developer might refactor code and introduce a bug or break functionality. After all, these scripts are code.

    If there is a problem, we want to be able to roll back, which means that we ought to save these scripts into a repository of some sort. While I like the idea of a share that all DBAs can access, I more like the idea of a (secure) Git repository that can be downloaded anywhere, provides a second backup, and can be audited over time. All of these are important features that any enterprise should implement, especially one that is regulated. We want to protect ourselves if a DBA gets hit by the proverbial bus.

    I like collaboration, sharing knowledge, and tracking the work you do in a team. It’s important for raising the skills of everyone on the team and helping new members get up to speed quickly. This facilities consistent results, and if done using a tool like version control, helps ensure that your scripts are backed up in a way that preserves the knowledge in your code through any changes made by the team.

    Steve Jones

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

  • The Level of Security These Days

    Passwords aren’t going anywhere. While I would have thought there would be more advances by this time, and there are, the basic password is still required in many places, especially for resetting an account. Even those MFA places where I can click a notification or enter a code, I still sometimes need a password.

    That’s fine, and I think MFA is a good solution, but it doesn’t alleviate the need to have a strong password. Troy Hunt has written about this topic because we as a collective do a poor job of building passwords. Especially with regards to length. Some of that is poor app (and database) design where we unnecessarily limit password length. However, some of the issues are our fault, as we continue as a group to use poor habits and practices.

    There are many guidelines to use with passwords, one of which is the length. The length you should use keeps increasing because hardware power keeps growing. Because of new attacks and techniques, we ought to review what we think is strong on a periodic basis. My password manager defaulted to 8 characters when I started using it over 20 years ago. Since then I’ve increased that to 12, and now 15. I ask for mixed upper case, lower, and numbers, along with symbols. These are so random that every time I need to give one to my wife to enter in, she’s annoyed with the length and mix of keys that need to be pressed.

    I haven’t seen the brute force table from Hive Systems before, but I like the visual. It helps you determine how strong your password is with modern hardware. This is a similar graphic to the one I used in an encryption talk years ago, where it showed how much it would cost to rent compute power on AWS to brute force crack various algorithms. In case you were wondering, about 5 years ago you could crack a 512bit key on AWS for less than US$75.

    I like the graphic, and it shows that my 15 character passwords should be safe for years. This Friday, I’m wondering if you’re comfortable with your password lengths? Are they crack-able in less than a year? Take a look at the graphic and let us know.

    Steve Jones

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

  • The Right to Repair

    I’m a do-it-yourself (DIY) person in many ways. I work on equipment on the ranch, repair or improve things in the house, and often tackle electrical or mechanical tasks. I’ve replaced hydraulic hoses, changed oil, replaced brakes, changed outlets, wired up lights, and more. I keep a hand cleaning degreaser handy and use it regularly.

    I think many people who work in software development are the same way, and often I find they want to rebuild things themselves rather than adopt or improve what’s there. Many organizations have a fair amount of NIH Syndrome inside that results in money and resources spent on software that might be better used elsewhere. I think some of this is going away as current trends in software make use of APIs, OSS, and services to cobble together a workflow rather than just building something from scratch.

    However, that’s not always something we can do. In fact, we often can’t take apart commercial software and fix it, not even when it’s broken and in need of repair. That same philosophy is starting to pervade products in the real world, which is disappointing to me as someone that likes to be able to repair something I own.

    There is a good article on the right to repair over at Make magazine. In this case, the argument is that there are certain restrictions manufacturers put in place to limit the ability of individuals or third parties to repair products. In the physical world, I think this is a problem for actual devices, but it’s also becoming an issue as software pervades the operation of many physical devices. One of the higher-profile complaints has been with tractor service.

    I don’t know how we reconcile the right to repair and own something with the intellectual property rights of software. It is a thorny issue, and one that I am not sure of how I would want to frame the rights, but I do hope that we at least ensure that physical products people own can be repaired by individuals, including the ability to “reset” software as needed.

    Steve Jones

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

  • Is CosmosDB the One?

    The question asked of Keanu Reeves in the first Matrix by many of the characters is whether he is the one. THe one that can save the world, and make a difference in their war. It’s a fun movie, and one I’ve enjoyed many times. Keanu doesn’t really believe he’s that special until the end. That’s in contrast to the products that most vendors build. Most of the times I think developers, marketers, salespeople, or all three think that whatever they’ve recently released is the best thing ever.

    CosmosDB is mentioned in a piece as the potential one database to rule them all. The article talks about some of the basis and value that come from the platform, which Microsoft continues to push as the database that can store any kind of data and meet the needs of any application. Whether you believe that or not, I find many articles and blogs from developers that are experimenting and building systems on top of CosmosDB.

    I do think the consistency models for CosmosDB are interesting, and having a variety of these models across a distributed RDBMS table would be great. I’d love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. I realize I’m asking for something that seems like a bit of magic, but I bet Microsoft could add this to the SQL Server relational engine.

    CosmosDB is very interesting to me, and it’s an item on my list that I want to learn more about. I think there are certainly domains of problems where CosmosDB would fit very well. If any of you are working with CosmosDB, I’d be interested in knowing why and how it fits for your particular environment.

    There was a quote in the article that I thought was interesting. A Microsoft Technical Fellow said, “No data is born relational. In the real world, nobody thinks in terms of schemas — they think graphs or maybe JSON document if you’re an IOT device…”

    That’s interesting. If I produce a JSON document, am I not thinking relational? Do I not expect that most strings, values or arrays will exist in most of the documents? Am I not thinking schema, even ragged schema, from the beginning? I’d think most data relational. It’s just not easy to get it into that format when you deal with many instances of data.

    Of course, dealing with many instances of data is hard for most humans. That’s why we built relational databases.

    Steve Jones