Voice of the DBA

Category: Editorial

  • The New World Of AI Robots

    It’s been a good time for robots. While on vacation last week I caught this video of a robot running. It’s impressive for a bit, and then it devolves into the inspiration for lots humorous comments as it crashes into a wall. There are some funny comments, but some pedantic ones that note the robot can’t beat a human record because it’s not a human.

    That’s correct, but …

    The comments miss the point. The robot will improve it’s capabilities, and much faster than a human can. The AI/ML advances of the last few years mean that we don’t have to program robots to be precise and exact. The fact that a robot can balance and run and stay inside the lanes is incredible. I suspect these robots, both humanoid and other form factors will start to become more commonplace in our world.

    Which is scary.

    Not for us tech people, though certainly AI advances are worrisome. More, I worry about other jobs. Think about the industrial robots of the last 30 years that have been used in places like car manufacturing. They are bespoke, designed to do certain jobs, and in a certain way. They are programmed with fairly tight tolerances to perform a specific task, often at a quicker and more reliable (and repeatable) way than a human can. There were plenty of false starts here, but today many robots are used alongside humans to assemble cars. You can see them working here, doing tasks that would be slower and harder for humans, even with mechanical aids.

    There is talk of humanoid robots being used in place of some humans, reducing the slow and complex setup . This also lets the robots work in the same places and spaces, moving the same way, as humans do. This might reduce some of the labor costs in the future. That might not seem like a big change overall, as lots of manufacturing uses automation in some way today, but think past this.

    You can purchase a humanoid robot for under $5000. That might not be very capable now, but as LLMs get more capable and perhaps specialized models for different purposes like image recognition, this is an issue. Imagine you own an oil change business. You pay 5 people to do most of the work on cars. Those people likely cost you $2000-2500 a month each. That’s the cost of 2 robots, without the hassles of hiring, termination, breaks, etc. An AI LLM can already identify items from a camera image. Is it a far stretch to think that a robot could identify the oil drain plug and the oil filter on a car by moving around it? How hard would it be for a robot to grab a human ratchet, pick the right socket after a database lookup, and remove the plug. They could tell when the oil finished draining and then replace the plug, tightening it to the correct torque. And being a robot, they might do this without forgetting to position the drain or replace the plug.

    In my mind, a $5k robot quickly becomes capable of a lot of human jobs. There might still be the need for some humans, but we might easily replace 50%+ of them in a lot of common jobs. Stocking shelves, acting as cashiers, who knows what else these AI driven systems might accomplish. That’s truly a scary world, where human labor in many cases might be devalued.

    In the software world, it seems the people having the most success have the best judgment. People who are above average software engineers get above average results from LLMs, and I suspect this will be the case for a long time. Very average, or worse, engineers get worse results and I think are the source of many of the stories of AI coding failures.

    I don’t know what a lot of manual labor jobs will do when management starts to experiment with robots, but I know that in our world you can compete and succeed against AI coding agents by learning to work with them, apply your judgment and use them as tools that make you more effective.

    Steve Jones

  • An Eventual Consistency Scam

    Recently I sold a car. It was an interesting process as I hadn’t sold a car to someone I didn’t know in a long time. I listed the car in a few places and was surprised by the interest. It was an EV (I guess it still is), and with the rising price of fuel in the US, maybe I shouldn’t have been surprised. I arranged a couple of showings, but I had quite a few people offer to buy the car after only seeing a few pictures, asking if I’d take a check.

    Some of you might be wary at this point, and I was. However, my wife had gotten similar offers from a few people when she was selling a horse. She never did, but we talked about where the scam is if someone sends a check and says they’ll wait for the funds to clear. This piece decodes where it is.

    I was curious, so I agreed to take checks from three people. Two of them sent the checks in registered letters, with proof of delivery. This is a USD$20 cost right now. One sent a FedEx letter. That probably cost a similar amount. In all cases, the people said they were sending enough for the car to be shipped, on top of my asking price. I also told them I’d need the check to clear, and they agreed.

    The first one I received, I drove by the bank while in town and deposited the check. I discussed the check clearing with the bank. I was told by the teller that I’d be able to get $400 that day and the rest the next day. I asked about when the check actually clears and the funds were moved, since all three checks were drawn on non-Colorado banks. The teller realized I wanted validation and said it would be 7-10 days and gave me a customer service number to call to check when funds were actually moved

    I haven’t used checks very much the last few years. While I know technology has improved, what has mostly happened is that the banks operate on a system of trust that appears to move faster even though many of the underlying systems are older and still slow. When you deposit a check, the bank doesn’t validate anything. That might seem strange, but it doesn’t. It sends the bank routing number, the account number, and amount through a process that reconciles the money with another bank.

    Think of this as data in two different databases, which it really is. The update in bank 1 isn’t sent to bank 2 for a period of time. The update from bank 2, which debits their account and credits bank 1, takes longer. In this case, the time is in days.

    That’s serious eventual consistency.

    What happened with person 1 was that they asked for confirmation of the deposit, and then texted me 2 days later saying that they’d need a deposit for the shipping company. I repeated that I’d need the funds to clear. They wanted to argue about needing to move fast, but I ignored them. After a few days, they said they were sick and could I front them money for a few bills and they’d drive to get the car. I didn’t agree and eventually they gave up communicating with me. A week after the deposit, I got a “funds failed to clear” message from my bank. No charge to me, but the “money” that appeared to be in my balance disappeared.

    Person 2 texted me the image of their FedEx note, and when I said I would wait a week for the check to clear, they asked me to tear up the check and send them a picture. I declined. Person 3 sent a check blindly, saying they were trusting me. I ignored future texts, but they persistently kept checking for 12 days. In all cases, these are checks on real banks, but fake names and accounts.

    Checks are insecure. And just like plenty of data replication systems that try to synchronize data between two databases, there can be issues if you do not have a two-phase commit.

    I wrote this so many of you would be aware of a scam that is out there. Watch out and warn your less tech-savvy friends. However, also be careful when you work with data that lives in two places. There is a lot of overhead to ensuring the data is correct in all the systems, and there are good reasons for this. Sometimes eventual consistency isn’t good enough.

    Steve Jones

    Note: A few people are concerned about the check images linked. Those are fake people and fake accounts.

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

    Note, podcasts are only available for a limited time online.

  • Never is Not the Policy

    Years ago I worked with a few developers and DBAs that were temp-table happy. As in they defaulted to using temp tables everywhere. This was in SQL Server 6.5, and tempdb was an issue with contention, sizing, and performance. I rewrote so many queries to remove temp tables for our clients that I banned them. I told other developers they could never use temp tables in their SQL code. They, of course, would try to submit code with temp tables in our VCS (Visual SourceSafe at the time), but an early, pre-automated CI/CD would notify me and I’d have the developer rewrite their code.

    There were situations that didn’t perform well with a single query, and we did allow some temp tables. The point wasn’t the ban them entirely, but stop them from being a crutch for developers or a first choice. I wanted them to think about the problem first and try to solve it with SQL. If performance was an issue, then we’d look at a temp table.

    Recently, I saw a post from Jeff Iannucci that noted there are settings you should never change. These were database-level or instance-level settings that he suggests you leave the defaults, or leave a specific setting chosen. An example of the latter is Page_verify set to checksum. The default in older databases, upgraded through different versions, can be none or torn page detection enabled. Fix that if you see it.

    Examples of other settings are things like Auto Shrink and Auto Close, which shouldn’t be enabled. These types of settings should be left off, well, with a caveat from me. There are narrow places where you might want certain things turned on. For example, Auto Close isn’t the worst thing in the world, and there places where it makes sense. Dev servers with a large number of databases that aren’t often used might get help here in conserving resources. Same for production instances where a lot of older databases are kept around for archival, but we don’t want them open and consuming any resources without an explicit connection.

    I don’t mind DBAs or developers having “never” as a policy for certain things, with the caveat that this isn’t a forever rule, but one that strongly sets a guideline that we don’t create exceptions for without a very good reason. Staffs change, internal knowledge is lost or narrowly shared, and often inexperience can creep into your environment. These strongly worded guidelines, even with “never” in them, help to keep everyone on the same path.

    Strong opinions, loosely held. We change our minds and grant exceptions when there is evidence to do so.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Republish: Going Big with SSDs

    Let’s look back. This editorial was originally published on Aug 16, 2011, when SSDs weren’t as common as they are now. Can you even buy hard drives? What do you think about the world 15 years later?

    I’m at the Fringe Festival with my wife today, so you get to re-read Going Big with SSDs.