I forgot to do this Saturday, and was traveling all day yesterday, but I’m finally getting this done. Thanks to everyone that attended my talk on building an API with the Data API Builder.
Slides: BuildingAPI.pptx
Demo code repo: https://github.com/way0utwest/DAB-Experiments
Note, the repo is a little unorganized, but I’ve tried to add some stuff in the Getting Started as READMEs. If you have questions, let me know.
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.
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.
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.
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.
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.
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.
I was lucky enough to attend SQL Saturday Austin 2025 a little over a week ago in conjunction with some work at the Redgate office. The opening keynote at the event was given by Conor Cunningham, who is an architect at Microsoft and runs the engineering team in Austin for the Data Platform. His talk was very interesting and engaging. This was about half the room below.
I’ll describe the talk, which was great, but I’m probably mis-stating something. Keep in mind I’m writing this a few days later from memory.
One of the interesting things Conor talked about was the engineering process in Redmond. The main thrust was that they work in 6 month planning cycles. Work gets submitted, voted on, works through groups, and as a result, most of the things approved are related to more revenue in some way.
Good for Microsoft, not something many of us love.
In Austin, they tackled things differently. You can see the outline in the image below. Conor hired a few engineers here, usually out of college, and they work on new features. Things that are too small to make the list in Redmond, but this also helps grow/train engineers on how to write production quality code.
What do they work on? He had a few slides, but IS [NOT[ DISTICNT was one. He described this a bit, but the cool thing was a bunch of the SQL 2022 features were from Austin. String_Split with the ordinal, the bit functions, and a bunch more.
Basically all the cool features I appreciated, including DATETRUNC, came from this small team. I am very glad they exist.
He also delved into the challenges of doing remote work. Building SQL Server is a non trivial procss, and they’ve been working to try and make this easier. They refactor code, they try to break things out so engineers can get quicker feedback, write more tests, etc. to make their software engineering easier.
He also talked about their work with hardware manufacturers and some of the optimizations he’s done with CPU and the ATX instructions to make SQL Server a little faster. For some types of queries, they’ve great improved the speed of internal SQL Server processing.
It was a great talk and quite entertaining. Hopefully some of you will see it elsewhere, or he’ll do it again in Austin and you can come.
lookaback– n. the chock of meeting back up with someone and learning that your mental image of them had fallen wildly out of date – having grown up or gotten old, fallen apart, or pulled themselves together – which shakes your faith in the accuracy of the social puppet show that runs continuously inside your head.
Most of the time I’ve run into someone after time away, they are similar to what I expect. They’re older, or they’re heavier (as am I) or something, but it’s within the realm of what you might expect after the length of time.
I had lookaback a few times in the last few years, though and it’s a bit jarring. I had someone I knew that went through a rough stretch and they had gained a lot of weight. Like 150lbs more than when I saw them. More than the weight, however, their outlook on life, being a bit depressed and without a light in their eyes was a lookaback shock.
I have lookaback at times with kids I’ve coached, where I see them years later as young adults and I keep this image of a 12 or 13 year old that is now in their twenties, more mature, and much more grown up. It’s a contradiction in my head, as I still keep a glimpse of that younger person.
Lookaback can be positive or negative, and I keep hoping when it happens it’s a positive experience.
From the Dictionary of Obscure Sorrows
Voice of the DBA 
