SQL Server Agent Job Monitoring (did a Job even start?)

Question

I am a BI developer and was entrusted with a task of a DBA. It's about monitoring SQL Server Agent jobs respectively getting information about the following key figures, which are to be prepared after all frontend:

1. Failed Server Agent Jobs and Jobsteps
2. Run-time of jobs and Jobsteps
3. Find out if a job has even started
4. Memory allocation: evaluation and monitoring of the moving and stored data volumes

The goal is to monitor and, if necessary, provide an indication of any discrepancies in the key figures.

I got the first two points. In each case I show in a table whether a job or whether steps are enabled/disabled. I have also recorded the terms of each step and thresholds can be used to warn if critical ranges are reached.

The biggest problems for me are the jobs that did not even start (Point 3.). To my knowledge, these are not recorded in the MSDB tables. I would like to know when a job or jobstep has not even started. Can you tell me how to get this info? Maybe someone already has a suitable script for this problem ready?

On the subject of memory usage, I'm interested in how much free space is left on the hard disk, how big the partition is and how the consumption changes over time.

On the internet, I could find nothing to the points 3rd and 4th. I would be very grateful for your help! (and forgive me my bad english :) )

Answer 1

I get as a result, when the next run of Job xy is planned. He does not appear in the table. However, he appears on the SQL Server Agent in the job history. There, however, the information is missing when he should run the next time. My plan was to take the next_scheduled_run_date column from the sysjobactivity table and then compare a run later to the run_requested_Date column. But obviously some records are missing in the sysjobactivity table. The other table, which otherwise contains target_start times, is the sysjobschedules. Unfortunately, this only has the currently scheduled date. I have not found another table that contains a history of the target run_dates. Of course, one could have manual tables (analogous to the target values) but that would be too much effort.