Voice of the DBA

Category: Editorial

  • The Technical Debt Anchor

    I ran across an article on the 7 types of tech debt that can cripple your business, which is a great title. It certainly is one that might scare a lot of CTOs/CIOs/tech management. I am sure that much of the IT management gets concerned on a regular basis with how quickly their staff can evolve their software to meet new business needs.

    The first two items have to do with data, which is understandable. Data is the core of how many organizations operate and move forward, and if you don’t have the ability to easily work with data in a flexible way, you can struggle. Many of us technical people know this, but I find many non-data-professional staffers don’t get this and are often unwilling to work at improving the situation. They things to just be magically better without changing how they do their jobs.

    Many of us data professionals know that data quality is crucial. Many others assume we have quality data. Both of us need to understand that some of our data is suspect, but most of us is pretty good. Don’t get drawn into a black/white argument that our data is amazing or horrible. No matter what we do, there will be errors, so account for that. At the same time, do some testing, some evaluation, and double-check yourself.

    We also need to ensure some level of performance from our data stores (databases, data lakes, etc.). Too often we see queries start to slow down and blame the DBAs. We ask them for better performance without being willing to press on developers (or vendors) to improve the performance of their code. Don’t just expect to build bigger machines, make sure you train staff to write better queries and help DBAs learn how to better index systems. We’re a team, so let’s work as a team on our performance issues.

    There are a few AI-related items and a couple of DevOps items as well. All tech debt is a problem; it just depends on how much you have as to how big a problem it is for your systems. However, the seventh item is cultural debt. AI is part of this, as staff can have job-threatening views of AI, but that’s really a lack of trust. Management has to build trust with staff and ensure they are cared for if management expects staff to be accountable for code. Workers have to drive themselves forward, as a part of the technology revolution is that change is a given. Don’t expect to do the same job you’ve done for years. Learn to use new tools and learn to use them effectively in your position.

    At the same time, management has to value employees and be clear about what’s expected or workers. Be fair with employees and value their efforts. Working together is what will drive your organization forward.

    Steve Jones

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

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

  • The Data Warehousing Choice

    Each time I compile and curate the Database Weekly newsletter, I find lots of Fabric content from the various sources I watch to compose the newsletter. Since I primarily deal with the Microsoft Data Platform stack, this makes sense. Most of the things I am interested in are related to Microsoft, and as a result, I tend to use sources that also use SQL Server, Power BI, Fabric, and related technologies. I do look for other related data items, but I am heavily MSSQL focused.

    Recently, I stumbled on a piece that contains Fabric Alternatives in AWS, GCP, and OCI. It covers some of the options on these cloud platforms at a very high level. A product name and short description, but it shows there are other choices. I found it interesting that Databricks is mentioned, but not Snowflake. I’m not sure why that is, as Databricks is on Azure (and other platforms) as is Snowflake, but perhaps the author doesn’t consider Snowflake a peer? That seems strange.

    I don’t have a lot of customers using Fabric, but when I work with SQL Server heavy clients, they always ask my opinion on Fabric. Microsoft has devoted a lot of resources (engineering and marketing) to Fabric, and that has many customers considering Fabric for a data warehouse. However, my view is still that Fabric is an incomplete system and unfinished (from an engineering view) platform. I would still be hesitant to adopt it, especially after some high-profile outages.

    AWS has several warehousing options, and I find a number of customers using Databricks or Snowflake as their main warehousing options if they have left on-premises platforms. Both of these seem fairly mature, well understood with lots of documentation, examples in online articles, and plenty of staff that can work on these systems. If I were thinking about a data warehousing system separate from my OLTP SQL Server (on-prem, Azure SQL, MI) database, I’d look at one of these.

    Those of you reading this are likely in the Microsoft space, so do you feel the same way? Or have you bought into the Fabric marketing? Microsoft is spending a lot of money there, and even adding a SQL Database to the platform. Microsoft clearly thinks they can compete with these other options (Databricks and Snowflake).

    Do you?

    Steve Jones

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

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

  • Multiple Monitoring Tools

    Part of my Redgate work is with customers who need to monitor their database servers. With estates growing quickly, both in scale and types of database platforms used, keeping an eye on everything can be challenging. Add in the lack of staff growing as quickly are the number of servers, and I find many companies seeking out monitoring tools to better help them manage the entire estate..

    When someone evaluates a tool, one of the first questions from many people is about load. They are concerned about the load a tool puts on the system, which is always some amount. Most tools say they use less than 2% of total resources, some might hedge at 5%. Hopefully, there’s no more impact than 5%, though that might seem to high, especially if you have a busy database server already.

    I’ve seen several customers who have multiple monitoring systems. Often this is because each tool does something well, but lacks a feature or capability that another provides. Each of the tools needs its own data, which can result in more performance impact.

    Is it worth the overhead? If you had a second tool that provided more capabilities, would you ditch one of your tools? I know I work for a vendor that produces a monitoring tool (Redgate Monitor), but I’m genuinely interested in how many of you view the world.

    We often make trade-offs, but sometimes we aren’t willing to change. Perhaps you have a tool that works very well doing a certain task, and you don’t want to stop using it. I know I’ve been in that situation, and unless another tool adds that thing, or more things I desire, I’d likely continue to use two tools to accomplish all the things I need done.

    Specialized tools have a place, and it can be worth the hassle of using them when a more general tool just doesn’t get all the work done.

    Steve Jones

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

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

  • SQL Server 2025 Excitement

    Are you looking forward to SQL Server 2025? Or perhaps you think this is just another release, or perhaps you are not looking for new features or capabilities in your environment. Maybe you don’t care about new things, but are looking for enhancements to features introduced in 2017/2019/2022. There is certainly no shortage of things that can be improved from previous versions (cough graph *cough).

    I ran across an article on the five things that one person is looking forward to in SQL Server 2025. It’s a good list, and the things included make me consider an upgrade. Certainly, any improvements in the performance area, especially with all the investments made in Intelligent Query Processing over the last few versions, are worth evaluating. They might help your workload, or they might not, but if they do, then upgrade.

    However, test, test, test. I can’t stress that enough. Test with your workload, not some random queries. Spend some time setting up WorkloadTools or find some other way to replay a set of queries from multiple clients to see if performance improves. It’s far too easy to look at a query in isolation and make a snap decision. With a load, sometimes performance looks different.

    The HA improvements are also enticing, especially the idea of offloading backups more easily. Of course, this means you need to ensure you can and know how to, restore a complex set of backups in an emergency situation. Distributed systems are complex, and backups from multiple nodes (remember, you might get unexpected failovers) are a distributed system. Make sure you consolidate those, and plan for potential disruptions if your backup system/share/location is gone. Local backups are always nice, but Murphy’s law might cause you problems in multiple ways with multiple nodes and backups moving across them.

    Again, test, test, test, and consider weird situations taking place. They will occur, and you should ensure your staff has a simple way to deal with them.

    We’ve had a few SQL Server versions that leaped forward. SQL Server 2005 changed the paradigm, and I think SQL Server 2016 was another time of dramatic growth. Will SQL Server 2025 be one of those versions, or is it one that has a few incremental improvements?

    Let me know your thoughts today.

    Steve Jones

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

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