Voice of the DBA

Category: Editorial

  • A Well Deserved Break

    This is my last day of work. Not forever, just for six weeks. I’m off on my sabbatical after today and won’t be back until August 11. However, everything should run smoothly with Grant and Kellyn holding things down until I return. Have a little patience with them as this site can be a bit of a hectic whirlwind at times, and they still have other jobs to do.

    It’s been a wild first half of the year. After very little travel in Jan/Feb, the rest of the year has been a bunch of travel, including most of May and June being on the road. With coaching responsibilities for two teams from Jan-Apr, I am ready for a break. No big plans, but I am looking forward to being at home, playing some guitar, working on a few projects while trying to be very unwired for six weeks.

    I know most of us tech professionals likely deserve a break from work at some point. I am very lucky to get a sabbatical, on top of vacation allowances. It took my a number of years to understand and learn to relax while on breaks. Too many years of being on call, owning a business, and driving my career forward had me delaying or skipping vacations some years. I carried over a lot of days from year to year at many positions.

    That’s a bad idea.

    We need breaks. We need to recharge, and while I wasn’t thrilled when Redgate’s policy changed, I have come to appreciate it. We can only carry over a week, and I try not to do that in any year. They want employees to take breaks, and I try to do so. My wife certainly appreciates me getting away from work and not checking email, Slack, etc. I was nervous the first few times I left SQL Server Central for a week, often trying to get an hour of work to check on things every morning while on vacation. I come to trust that everyone at Redgate will keep an eye on things and ensure the site keeps running.

    I may still blog about the sabbatical, but I don’t know it will be any sort of priority. I’ve been quite busy up until today and haven’t had time to plan much of anything. That won’t make for any interesting blogs, but it will be a well-deserved break.

    Steve Jones

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

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

  • 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.