Voice of the DBA

Tag: DevOps

  • The 2023 Redgate UK DevOps Roadshow

    Years ago Redgate did some traveling events under the SQL in the City brand. These were a lot of fun and kind of amazing. One of the longer tours also made me realize I would hate being in a musical band and touring.

    However, I enjoyed the events and while we’ve moved on from that brand, we have a new one

    The Redgate DevOps Roadshow

    The UK edition of this kicks off in September 2023 and I’ll be in these cities:

    I’ll be traveling with one of our Sales Engineers (Chris Hawkins, I hope), and doing will day sessions for customers on the Flyway suite of tools. You’ll get some practice, learn how things work, and get answers to your questions. Hopefully that day, but if Chris and I don’t know, we’ll query the brilliant engineers back in Cambridge.

    If you’ve ever attended a Redgate event, you know we put on a nice show, we take care of you, you’ll have plenty to eat and drink, and we have fun.

    Hopefully I’ll see some of you in September in the UK.

    Keep watching as well as we’re working on a US edition of this. I’ll do some of these, while Grant and Ryan will do others. I’ll keep my schedule updated as I get more info.

  • Talking about the New Open-Source SQLCMD on Data Exposed

    I was on the Data Exposed: MVP Edition show recently, talking about SQLCMD. I’ve written a few articles on the topics as well, and a blog post about setting up a node HTTP server, which I show in the demo.

    Check out the show below:

    Read these articles for more info:

  • Concurrency Challenges Around Schema Changes

    I saw a great question on Twitter from Frank Pachot, a developer advocate of Yugabyte. He wrote: Without thinking how your preferred database deals with it, what do you expect if:

    • session 1 starts to reads table T
    • session 2 drops table T
    • session 1 continues to read

    The choices in his poll were: session 2 waits, session 2 fails, session 1 fails, both fail. My first thought was SQL Server and the default need for session 2 to get an exclusive lock. In that case, session 2 would wait. Most people answered that same way, but then Frank posted a follow-up with a link to his blog. The answer for Yugabyte is that session 1 fails as it gets the message that the table was deleted.

    Leaving aside the decision to drop a table, imagine this is some schema change instead. In the blog, some good points are raised about how to handle high concurrency changes, and the potential problems with having session 2 wait. On a busy system, this could cause lots of blocking as threads stack up behind session 2.

    It’s an interesting read about the challenges of distributed system design and how to handle changes. In some sense, I get that this makes sense, but I wonder where this causes issues. If any schema change on the table by session 2 were to cause an error in session 1, that would be bad. However, does this mean that the database engine must now evaluate whether a column change impacts a query in flight? Then decide to send an error? What about evaluating views or procedures/functions that depend on

    Does this mean that all nodes need to sync up the schema changes quickly, and at a higher priority than data movements? I don’t know exactly how Yugabyte distributes data, and if there are copies on multiple nodes, but I assume there are. This adds complexity to the communication between nodes, which is likely needed. Honestly, if someone drops a table and they should have, we probably don’t want clients getting results. If they do this accidentally, I’d like to know about it quickly.

    The question is interesting, and there are multiple ways to look at this, but I found it fascinating to spend a few minutes thinking about the complexities of data in distributed systems and the challenges involved. This also made me think that the people who keep data safe and fix problems when they occur are invaluable in the modern world.

    Steve Jones

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

  • Agile West–How Do I Get Started with Database DevOps

    This week I had the chance to deliver a talk at Agile West in Las Vegas. I linked some resources on my blog, and feel free to check them out.

    Tl;Dr – Start with deployments

    After the talk, I had an interesting question from someone in the audience. This person had a lot of developers writing code and then sending to a DBA, who executes it in SSMS. This was for SQL Server development, and that’s a common way many companies deploy database changes.

    Even companies that have software developers who embrace DevOps will still tend to work this way.

    This is error prone, inefficient, and it’s not the way to build better software. We know that DevOps produces better software if you adopt it, and we know that you can’t forget the database. That’s integral if you want to be a high or elite performer.

    My advice for many companies is that they start with deployments. If you have some manual process or DBAs involved, often they’re just running a script you produced in some way. What I’d do is start adding Flyway Community  (or Teams/Enterprise) in and putting those scripts into a folder (hopefully in Git) and naming them as appropriate. That’s a small change for DBAs or Ops people deploying code, but it starts to enable a process.

    From here, I can alter this process to use tooling (Azure DevOps, Bamboo, Jenkins, etc.) and continue to put scripts in a location. Then I can work backwards and start getting developers to build better processes for capturing and saving code.