Voice of the DBA

Tag: syndicated

  • Monday Monitor Tips: Beyond SQL Server

    Redgate Monitor works with more than SQL Server. Some big changes were announced recently, and I’ll cover the highlights here.

    This post looks at Redgate Monitor and the additional monitoring available for Oracle, MySQL, and MongoDB.

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

    Growing Up

    The world has been slowly growing to embrace more database platforms. Not just as a whole, but I find more and more Redgate clients have lots of different database platforms. Our 2025 State of Database Landscape report shows that while there is a little consolidation from many companies having more than 4 platforms in 2024, there are still plenty that have 2 or 3.

    As a result, we’ve been working hard to bring additional capabilities to Redgate Monitor beyond SQL Server. In 2023 we announced PostgreSQL support. Just recently we also added Oracle, MySQL, and MongoDB support.

    We can see this in the online monitor.red-gate.com demo site. If we scroll down to the staging group, we see both MongoDB and MySQL being monitored.

    2025-05_line0038

    Below these, we see Oracle 19 and 23 being monitored as well.

    2025-05_line0039

    If you click into any of these cards, you’ll see there is a limited amount of information now, but we have teams growing and adding the metrics on a weekly basis. Right now, Oracle shows high level metrics and queries.

    2025-05_line0040

    MySQL is similar

    2025-05_line0042

    as is MongoDB

    2025-05_line0041

    The supported platforms are in the docs for Oracle, MySQL, MongoDB, PostgreSQL, and SQL Server.

    Summary

    Redgate Monitor is growing up. I remember when it was just a small alerting system and now it’s a world class monitoring platform that is growing beyond SQL Server. If you have needs on other platforms, check it out and let us know what’s important to you.

    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.

  • The Book of Redgate: Do Your Best Work

    One of our mission statements in the Book of Redgate says: attempt to do the best work of your life.

    I’d like to think that at most points in time, people are trying to go good work. There are always times when you are distracted, ill, new child, etc. However, doing the best work of your life? Do you think you are always doing the “best work” at a new place? Or being the best version of yourself at this current position?

    I think I am, and this is a good reminder to strive for being the best you can be at that point in time.

    The text alongside this value is: We’d like you to achieve your own greatness and to be all that you can be. We’ll try hard to allow that to happen and we’d like you to try hard too.

    That’s comforting and inspiring. I do think we try to allow people to grow and achieve things. It’s a nice environment.

    I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

  • A DevOps Workshop Tomorrow in Atlanta

    Tomorrow is the Redgate DevOps Day in Atlanta. You can still sign up, so do that if you can make it. Here’s the rough outline

    • Vision Session – w/ Advocate Steve Jones
    • Redgate Flyway hands-on Session
    • 6 ways to Elevate Database Monitoring
    • Whiteboarding Session
    • Test Data Manager Demo Session
    • Networking/Happy Hour

    Lunch is provided and I’m looking forward to this. I’m traveling from Baton Rouge today to Atlanta (probably right now), coming from a customer visit.

    Register and come see me in Atlanta tomorrow

  • T-SQL Tuesday #186–Agent Jobs

    It’s that time of the month again, when the T-SQL Tuesday blog party takes place. I manage this site, and am looking for hosts all the time. This month I managed to convince Andy Levy to host, and I’m grateful for his participation.

    His invitation is asking about SQL Agent jobs and how they are managed. It’s focused, but he gives a lot of choices for how to examine this subsystem in SQL Server.

    Note: if you work in Oracle or PostgreSQL or anything else, how do you schedule work in an automated fashion? Cron? Something else? You can still write.

    If you want to host, ping me and I’ll get you a month.

    Designing Jobs for an Enterprise

    I used to work in a fairly large enterprise (5,000+ people, 500+ production SQL instances) with a small staff. It was 2-3 of us to manage all these systems, as well as respond to questions/queries/issues with dev/test systems. As a result, we depended heavily on SQL Agent.

    We decided on a few principles which helped us manage jobs, with a (slow) refactoring of the existing jobs people randomly created with no standards. A few of the things we did are listed below. This isn’t exhaustive, but these are the main things I remember.

    Name schedules clearly

    Scheduling gets crazy. As a result, we would try to name with the days and times something ran. For days, we’d use SMTWRFSa. If something ran every day, that was in the name. If it were week days, then it had MTWRF in the name. Thursdays only were R.

    We’d include a time, such as 0200 or 1830 in there. If there were just one or two times, we’d list those. If it were more often, we had “every hour” or “every 15 minutes”.

    This wasn’t perfect, but it made most schedules clear.

    Job Names and Descriptions

    We tried to make job names clear with a starting noun (Backup, Maintenance, Sales), which was a little overloaded. It was a DBA thing for most work that DBAs might run and a department for those business level things.

    Job Steps

    I tried desperately to get away from code in the job step and use stored procedures instead. This helps us tune and watch things that run, and it keeps code in code places.

    For DBA stuff, we had a DBA database on each instance for our procs. We’d put our code in there (Ola’s procs, our own custom maintenance things, checks, ETL, etc.). This way we could more easily run server level stuff.

    For business level jobs or things related to a db, we want a proc in there. Then call that. This also let us often have a logging table alongside the proc where we could track progress.

    Alerts/Operators

    Luckily we had a monitoring solution that notified us when jobs failed. We didn’t use these systems. However, we did have an auditing report that queried DMVs and noted job failures and stored this data in a table (rolling 30 days) and used it to produce a daily report we archived in a folder.

    This was for our ISO compliance and auditors loved it. We would store a daily report and then add a daily note of any actions we took. That way we knew what we did and had a record.

    Summary

    For most of the other options (categories, etc.) we ignored them. The goal was to keep things very simple and streamlined. We had a standard job we deployed to most servers as part of a build process.

    We also drove a lot of activity in code off queries as much as possible and only used a table to log exceptions. We might have a table that stored the “FinanceDW” db name as an exception. The backup process would get a list of all dbs, and then delete those in the exception table. Then run as normal.

    K.I.S.S. worked very well for us.