Voice of the DBA

Category: Editorial

  • Representative Data Challenges

    One of the areas where machine learning and artificial intelligence have had lots of success is with image work. Whether identifying people in pictures or helping cars stay on the road and out of each other’s way, this capability of computing has worked well. It’s not perfect, and not necessarily as accurate as most humans, but it works well. At least well enough. Sometimes it’s even better than humans.

    There are issues, however, and I think some of them are because of poor data sets. Last year when the pandemic hit, education was challenged with how to conduct remote exams. While there are some solutions, they don’t always work well. Sometimes the algorithms don’t recognize people, especially non-Caucasians.

    The issues raised reminded me of the issues with some bathroom gadgets. I have fairly dark skin, and I’ve always wondered why some sinks and soap dispensers wouldn’t work for me. I hadn’t thought much about it until I saw a few reports like the one listed above.

    I don’t think there is anything malicious here, but I do think that often we find teams work on a happy path when building some new tool. They test it often themselves, but they don’t think widely about how a variety of customers will use things. While I’ve seen many personas, I often don’t see anyone creating personas that might consider something like skin color, or even a different culture. We often consider roles, without deeply examining how those roles are implemented.

    We need to work with representative data in whatever area we work, but data that does include some of the edge or corner cases that might come up. Our dev and test areas can start with small data sets, including those that we build, but at some point we need representative data. Whether we’re building OLTP software, sensors, or image recognition, our data should be well rounded.

    While systems don’t need to solve every issue, we ought to consider a large percentage. In the case of imaging, certainly understanding the wide variety of type of people that can use products would seem to be important. Hopefully future teams won’t make the mistake of assuming that most of their customers look exactly like them.

    Steve Jones

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

  • Default Credentials

    Years ago I got a call to help someone with a database. I walked over to their desk (when this was possible) and sat down. They asked me how they could get into a database they had been told about. I quickly realized this was an Oracle database and asked for credentials for SQL*Plus. This person didn’t have any, but I was able to log in with SYSTEM and MANAGER. This was a small department system of some sort, but it always struck me that the default credentials were available. Since then, every time I’ve encountered an Oracle database, I’ve tried those credentials. I’ve been amazed how often they worked, even for production systems.

    Recently there was a report that the Nissan corporation had some of their source code leaked. While I would prefer that the code running inside cars was open and widely examined, I was more dismayed that the leak was from an internal Git server with default credentials. Maybe even worse is the defaults are admin and admin, something that might not be hard to guess.

    I understand people make mistakes, and I do get that there are pressures people feel to get work done, but there isn’t a good excuse to stand up any server in production with default credentials, and I’d argue a VCS server is production. Even if you didn’t install the server and were just moving it to a new role, or you take over administration, you can’t leave default credentials around. You certainly can’t accept “admin” as a password in 2021.

    To me, this is grounds for termination. If nothing else, it’s certainly a reason to remove someone from a privileged position. Being this lax with security would worry me, and I don’t know that I could trust that you’d been careful with other parts of your job. If I encountered this, I would request that every other system under management be audited for improper admin accounts.

    Steve Jones

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

  • Improving Availability Groups

    Availability Groups (AG) were introduced in SQL Server 2012, with the idea that we could dramatically improve (and ease) the burden of dealing with high availability in SQL Server. At the time the (code named) HADRON technology seemed full of possibilities.  Since then, there have been some enhancements, but it seems that setting up and managing an AG, especially across subnets, isn’t as simple as Microsoft would have us believe.

    One of the problems with AGs is that there are non database resources (logins, jobs, etc.) that create dependencies. Working around the issues is a headache for many administrators, and it shouldn’t be. While there are some enhancements potentially coming, I don’t know what shape these will take or if they will make things easier.

    Some of my previous work as a DBA relied heavily on SQL Agent and jobs, neither of which are handled by AGs, or by plenty of other HA/DR technologies. Instead, administrators cobble things together, save scripts, and manually repair issues after failover. To me, this is one area that I’d hope Microsoft enhanced for AGs.

    Another area is the listener, which seems to be brittle. It works great, or it’s a nightmare to get working, without always an easy way to debug. I’d certainly welcome improvements here, including the ability for tooling to support multiple listeners easily.

    Many of you work with AGs now, and many more of you may in the future as the need for HA grows all the time for databases. Are there improvements you’d like to see in AGs, or any other SQL Server HA/DR technology? Feel free to leave a comment or submit something to Microsoft.

    Steve Jones

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

  • Security in the Aftermath

    Not too long ago was a very sad and embarrassing day for the US. The US capital was breached and rioters had hours inside without authorities. Ignoring the reasons and politics behind the event, think about the security of the building and systems after the criminals were removed from the building.

    Someone else brought up this point, which I think is fair. Can you trust any system in the building? Keyloggers, cameras, who knows what devices might have been planted. As a friend noted, anything with a plug should be thrown out. Who knows what might have been replaced or altered to create a security vulnerability.

    I haven’t had intruders in an office, but I have had to evacuate offices and returned to find unsecured systems. I’ve seen unlocked computers, when there were law enforcement or fire department staff walking around unsupervised. I doubt they did anything, and certainly never heard of any breach, but it is something to think about before you have to deal with the event.

    Have you thought about this or had to deal with this situation? Are you ready to audit systems and ensure nothing happened? Forget about spy devices, though those are certainly possibilities in this day of hot-plug USB keyboards, what about someone accessing information? If someone left a machine unlocked, would you think to check the history of the machine? Look at sites visited or emails sent? I don’t know I’ve ever thought about this, though in today’s world, this is something to consider. We are seeing some crazy types of attacks on systems, and I suspect it will continue to get worse.

    I learned a long time ago to lock my machine when I leave for any reason. A large group of administrators took delight in changing configurations, wallpaper, even sending embarrassing emails from unlocked machines to the group. After making a couple mistakes, it became a habit to lock a machine before you stood up for any reason.

    Most of us won’t deal with criminals walking around our office space, but we certainly should be careful and aware that unsupervised people around privileged systems is always a bad idea. I used to hate taking out the trash from a computer room I worked in, but I now appreciate that allowing cleaning staff into that space might not have been a good idea in a nuclear power plant.

    Steve Jones

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