Brandie Tarvin wrote:
A few years ago, when I was getting ready for maternity leave, we hired a contractor to fill my position. While I was training them, I showed them how I start my morning (logging into all servers, checking the Job Activity Monitors on each, etc.) and their first complaint was "Why isn't this automated?". I suppose that's a valid complaint, but I explained my reasoning for doing it and told them if they had a better way, to feel free to come up with something.
So they built a program to scan the logs of several servers and output an email to the DBA team with the 25 most important daily jobs and their status. The email includes job name, date it last ran, and a little "light" to indicate "Done," "Running," and "Failed." Which was kind of neat but I never really liked it for some reason.
This morning I'm going through the Job Activity Monitors (because I'm awake earlier than the job runs) and as I discover a new job that failed and doesn't have notifications set up, it hits me why the contractor's automation bugs me so much. It doesn't give me a true feeling of the state of the server jobs. It doesn't auto-add new jobs, it doesn't cover all jobs, and the last run date is so small on it that I don't notice it half the time and might mistake a successful run from 3 days ago as a successful overnight run if I'm not paying attention.
Am I the only one who likes to actually look at the regular server tools to verify things are working and get a handle on what my day will be like? Or does anyone else feel like there's something to be said about just taking a few minutes out of the start of the day to make sure everything looks good?
When I was responsible for data safety I developed a job which was backing us all databases on the server.
1st step was to scan the list of databases in master database and compare it to the list saved in a user table in a "DBA" database. That table contained the set of parameters for the backup process defined for all databases. If there was a database on the server not mentioned in that table then the job added it with a "default" set of backup parameters.
of course we could edit those parameters at any stage. But at least no database would go missing from regular backups, and no database would grow extremely large TRN file because some junior developer have forgotten about LOG backups.
thats what your contractors forgot to include to their automation - scan for the full list of active jobs.
And you may guess - I don't like to login into servers to verify that everything is working. I prefer to look at things which are NOT working.
"Mr. Corleone is a man who insists on hearing bad news immediately."