Voice of the DBA

Category: Blog

  • Grinding Away: Brent Ozar

    Brent Ozar is a very successful DBA/consultant/speaker/business owner in the data platform space. Many of you have likely seen him speak, read his blog, used his sp_Blitz script, or taken one of his classes. He’s achieved a lot and I know many people that would like to get to the place where he is in life. Most of us would love to teach a few classes, do office hours from wherever we are, and custom order a sports car for fun.

    One of the things I’ve enjoyed most about watching Brent move through life is his life quest. You can read this, but I’d recommend scrolling to the bottom (Level 1) and then going up through history. These are various items of achievement, some adventures, some things he had to work through.

    I’ve known Brent a long time. I remember when he started speaking, when his blog started to grow, and I have watched him put in a lot of hard work.

    He’s been grinding for most of his life and only recently slowed down. Before that, he spent a lot of time trying to improve his skills. He worked lots of hours to learn about SQL Server. He got his employer to send him to the SQL Server Ranger class to become a certified SQL Server Master and he studied hard to achieve that. Many of his goals around building his business or speaking to large crowds required investment of time and money to learn how to accomplish the goal.

    And he’s told many of you how to do the things he’s done. He shares lots of thoughts on what has worked for him, some things that didn’t, and given you a blueprint to become a better DBA, consultant, speaker or anything else.

    You just have to do it (and want to do it).

    If you want a good example, one of his early posts is on coding for his class reunion, a volunteer effort. Time spent forcing himself to learn.

  • Monday Monitor Tips: Am I Patched?

    One of the things that I think is neat is that Redgate Monitor helps you track patching on your systems. This is something that has been challenging in every position I’ve had, with some systems being forgotten or remaining unpatched for too long.

    This post looks at how you track patches and versions.

    This is part of a series of posts on Redgate Monitor. Click to see the other posts

    The Challenges of An Estate

    There are two aspects to tracking your systems: the version and the patch level. Microsoft releases versions periodically and unless you’re in the cloud with a PaaS service, you may or may not have just one version of your database platform. Azure SQL Database is evergreen and updates every quarter or so.

    If you install SQL Server 2016, unless you upgrade, it stays at 2016.

    The second part is the patch level. SQL Server 2016 has had 3 service packs, multiple CUs in between those, and a few post-SP3 security patches this year (2024). Are you up to date?

    It’s a good question since you might be vulnerable to issues, and you certainly can be out of compliance with auditors if you aren’t patched.

    What Systems Are Behind?

    The estate tab has a versions page, in which we list the installed versions of SQL Server. I hope PostgreSQL is coming soon as well (and others). Here is the overview, where you can see this estate spans SQL Server 2008 R2 to 2022, and includes the cloud.

    2024-11_0251

    This helps me with upgrades, as I can see which systems might be old and in need of an upgrade plan. I can filter at the top for different groups, tags, etc., but I can see what I have, and I get quick links to the current patch.

    Below this, I have details. Here is where I can dive down to individual groups and systems to see if they are patched, how long ago the last patch was released, and the end of support

    2024-11_0252

    This is a good way for me to see at a glance how patched I am. The yellow up arrows mean I need to patch. The green check mark means I am patched.

    This is a good view so you can tell how out of date you are. It’s one thing if there are patches released within the last month and not applied. It’s another thing when you have systems that are months or years out of date.

    Using This Data

    This isn’t something I’d check every day or week, but I would set reminders to have this monitored monthly and have plans in place to get patched. While lots of patches might not affect security, they often to affect support if you need it, and certainly these affect compliance and auditing.

    Even if no one audits you, if you have an issue and you aren’t patched, someone will use that as an excuse to blame you in some way. Get patched, at least within 60 days if not 30.

    BTW, this data is maintained by Redgate and updated as patches are released. Redgate Monitor downloads a file that populates the latest patches for each version. If your Redgate Monitor Base Monitor cannot reach the Internet, you can update this yourself by downloading this file and copying to your system.

    Summary

    This short posted highlighted what data you get about versions and patches, and my recommendation, which is to review this monthly.

    Having Redgate Monitor keep all this for you is nice and helps you keep a healthy, up-to-date estate.

    Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

  • Big Queries, Big Money

    I had been meaning to post this, so as I finished a piece that referenced this, I decided to post the picture. This was from Small Data SF, where the opening keynote referenced the Google BigQuery demo of a 1PB database.

    Here was the slide shown later in the talk.

    2024-12_0187

    The thing the demo didn’t explain was that query cost $5,580. The conclusion, big data is just too expensive to query often.

  • A New Word: Fardle-dun

    fardle-din – n. a long-overdue argument that shakes up a relationship, burning wildly through your issues like a forest fire, which clears out your dry and hollow grievances and reminds you that your roots run deeper than you think.

    I have had a few fardle-dins. Both in my personal life and at work. The private ones are private, but let me tell you about a work faux-pax on my part.

    I had complained to an individual at a previous company that the way their team approached some software work was incomplete. In my mind, the team often simplified things too often and looked at the software for only a simple use-case, not examining common situations outside of the core use case. At the same time, the teams thought I wasn’t focused enough on different problems to ensure they were well designed.

    After seeing this a few times, I publicly criticized their approach and offended the manager of that team. I received a private tongue lashing for this, with the manager pointing out that they do a lot of different work to consider different situations.

    We ended up working through our differences, with me understanding their view, but the team also starting to understand why their approaches each tended to be over simplifications and created tunnel vision. I apologized publicly and we burned through our issues, creating a better relationship for the long term.

    It’s never a pleasant process when you encounter a fardle-dun, but it can be cathartic and build something better.

    From the Dictionary of Obscure Sorrows