Voice Of The DBA podcast

—

I studied economics in university, which isn’t that close to database work, though I did have to work through linear regression problems by hand. I always enjoyed mathematics, so this wasn’t a hardship. Until I purchased a PC that was capable of letting me do graphs and calculations in PASCAL and BASIC. Then I realized that my enjoyment wasn’t that efficient or useful, and a computer could help me get things done way more efficiently. Many of us work on systems that process tremendous amounts of data, something our organizations couldn’t complete without computer hardware, efficiently or not. We just wouldn’t be able to get the work done by hand. That’s the main reason why downtime is such a problem in the modern world; we can’t fall back to manual systems in many cases. I ran across an article that discusses some of the large-scale failures in recent history (Heathrow, Delta, NYSE, Royal Bank of Scotland) due to computer system failure. Certainly, there are large financial costs and lost revenue for organizations that suffer these outages. However, there are other costs that are borne by the staffers, which don’t often make the news. When it’s “all hands on deck” to solve a problem, other work isn’t being progressed. There is certainly the interruption of Operations people, but often developers get asked questions or pulled into meetings to provide input. That can take them away from their existing work. Apart from the “23 minutes to get their head back in the game,” as noted in the article, can they even focus anymore? Will they be thinking through all the possible causes, and did they actually provide the right information or all the details needed? During a crisis, or even after, it is very hard for humans to focus on anything else. Apart from the technical details, IT staffers can have a range of emotions and thoughts. They might have sympathy for customers affected. They might worry they’re at fault and might be blamed (or terminated). They might be thinking about how they should have coded or configured something differently? Should they have tested more or accounted for issues? They might have simple anger at others who didn’t do their job, or frustration at the failure of a piece of hardware. Perhaps even more concerning is the load management can place on employees to get things fixed. If people work long hours, how do we ease them back into the flow of all the other daily work? I know I’ve struggled to get people to rotate work with rest as a manager. As an employee, I struggle to even sleep if I am sent home while others are still working. I’ve had to work 100+hour weeks and very quickly we get into survival mode, not productive mode. There are lots of costs to downtime apart from the financial impact. If you can’t maintain a stable environment that limits the time employees spend firefighting, you likely aren’t going to survive as an organization. Startups sometimes can do this, but often it’s from a few extremely dedicated employees who make a difference at a smaller scale. And these employees often pay the price in their personal lives with health, relationship, or other issues. The article goes on to look at predictive analytics that might help us reduce some of the issues from hardware issues. I think this is likely true, as we’ve seen digital twins that simulate loads on equipment help proactively catch issues. What do we do with software? If we don’t write well architected software that handles the load, how do we write an analytical system that can predict failures? This seems like a level of static and dynamic code analysis that we aren’t mature enough to build. Heck, even if we could, how hard is for many of you to get queries tuned in a running system? I find too often there isn’t enough effort or enthusiasm from developers, management and others to follow solid tuning advice and change your SQL. Maybe that’s too limited a view. Perhaps the AI analysts of the future will become the consultants of the past, whose recommendations often mimic the words of the current staff, but somehow carry more weight. Maybe they’ll get more things done and changed to help us build more robust systems. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
Remembering Phil Factor

4 days ago

—

One of the most prolific and popular authors at Simple Talk has been Phil Factor . He wrote many pieces on all aspects of database work and has probably written more articles on the Redgate Product Learning site than anyone else. He has entertained, informed, and inspired many database professionals in his many years as an author. Phil, aka Andrew, passed away recently. This was a shock to many of us and a sad day. Tony Davis introduced me to Phil, whom I always thought of as Andrew, many years ago when I first traveled to Redgate. Tony published a tribute to Andrew on Simple Talk and has many more fond memories of Andrew. If you ever get the chance to meet Tony, ask him for a few. Over the years, I’ve had the chance to get to know Andrew better. He, Tony, and I would often go out for lunch when I was in Cambridge. He came to PASS a few times, and he and I had many discussions about technology and ranch life over the years. Andrew lived on a plot of land similar to mine. We both tended to build, fix, and repair things ourselves, and we often discussed our latest projects. He also had a love of bluegrass music and wanted to come to Colorado for the Telluride festival. I’m not sure that he ever made it, though I somewhat regret not being more enthusiastic in encouraging him and offering to go with him. That isn’t my style of music, but does it matter? As I get older, I appreciate the time I get to chat with friends and family. I cherish the opportunities to spend time with others, however long or short. These are the important things in life: the events and conversations. It’s a sad time as Andrew and a few others I’ve known have passed away in a short period of time, but I hold many happy thoughts of the times we’ve spent together. I hope you remember to appreciate the opportunities you have to spend time with others. And in memory of Andrew, flip through his articles and pick one to read today. There are lots of great ones, and some fun ones, like the SQL Limerick . Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
Pushing the Limits of AGs

6 days ago

—

Many of you reading this likely have an Availability Group (AG) set up on at least one database in your organization. Maybe not most, but many of you as this has proven to be a technology that many people like for HA/DR, upgrades, and probably other uses. As the technology has evolved from it’s SQL Server 2012 debut, it has improved in many ways. This might be one of the few features that has received regular attention from the developers in Redmond across multiple versions. That’s not to imply this is a foolproof or bug-free feature. Numerous people have had issues with the various types of AGs. From setup to performance to scale, I’ve seen many people post questions and search for answers on how to get their system running smoothly and reduce any late-night calls. Over the last decade I’ve seen various people test different parts of the AG technology, but not many pieces about how much you can stress the technology at high levels. Microsoft supports up to 8 replicas, but what about groups and databases? The recommendation page says MS has tested 10 AGs and 100 databases, but nothing else. I ran across a post on LinkedIn from Calin Oprea that covers his AG testing. He hasn’t written about it, but says he can make the scripts available. He tested 50,000 databases, maybe more. He says 50k+ in the post and notes anything beyond 500 databases per instances starts to fall apart and 1000 seems to be a hard limit. Failover doesn’t work, even without a workload. That’s quite a test of the technology at it’s extreme. I’ve never run more than a few AGs or databases, and I see people posting and talking about dozens. Most of the people I know doing things at scale are using less than 10 AGs and usually no more than 100 databases max. I wonder how many of you out there use more than 2 AGs on any instance and more than 20 databases. I’m sure there are lots of systems at this scale or larger, but I’d guess the majority are 1 AG and less than 10 databases. Take a look around your environment today and see what the average and extremes are for Availability Groups. And if you’ve never looked at them, it’s a piece of technology you ought to become familiar with. HA/DR is becoming a base requirement in many situations and it’s available in the cloud with the toggle of a setting. If you work on premises, it’s likely your clients expect your systems to easily failover to another location. Check out Stairway to Always On to get started. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
AI Steals Joy

8 days ago

—

Take a moment and think about how much work you do each day. If you write code, how much time do you actually spend writing code around meetings, admin work, and other tasks. If you manage systems and develop scripts, how often do you get to work on a script, change it, upgrade it, or add a new feature? I bet it’s a minority of time for most of you. Studies show that many developers spend only an hour or two writing code each day. I would guess it’s lower for sysadmins or DBAs who incorporate coding into their jobs. Now think about how much you enjoy each thing you do. I assume meetings aren’t the most exciting thing you work on, nor is updating a document for others to read. When I wrote code as the main part of my job, solving the problem, trying different algorithms, experimenting with enhancements, those were the fun times. Now imagine having a competent AI assistant that works with you. What if the AI does the coding and leaves you with the meetings and writing of specifications? It could happen. While it might be fun to direct a team of agents , you still need to understand software architecture and development, but you might not want to get away from writing code. As more developers start to use AI agents to get work done, there is rising dissatisfaction among developers because the AI can do quite a bit of the coding, which is the thing that most developers love. The AI doesn’t help with any of the other busy work, though AI agents might do a better job of ensuring docs match committed code (or released code). What I’d really like is an AI that would take my place at meetings. Maybe do a report for me or take a summary back, get some action items for me. An AI agent could handle things that wouldn’t necessarily be fun for me. Not all tedious things, but it could free up more time for coding. However, that’s not what the GenAI agents are being positioned to do. They’re stealing the joyous part of development. At least, if managers have their way, that’s the place they’ll use GenAI most. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
The Security of Old Tech

11 days ago