How to Decipher sysschedules

I recently was given the assignment to discover everything that was happening on a client’s 3 SQL Servers. I started where you might expect by taking an inventory of all of the databases. I listed all of the files and their sizes and the options that are returned with sp_helpdb. Then I listed the tables, columns and how many rows each table had and continued to do some other helpful things along those lines.

Then I came to the jobs running on SQL Agent.

Listing the jobs and what they do was no problem. Just queried sysjobs and sysjobsteps and that was all I needed. Here is the query that I used to pull the job steps.

The toughest part about the query above is the last_run field. I did some searching on the trusty internet and found a couple of articles that got it wrong. The last_run_time field is the time stored as an integer but instead of being some interval of time since midnight as some have stated, it is actually the digits of the time stored as an integer. For example, 0 is midnight. But 100 is 12:01:00 and 10000 is 1:00:00. So in order to convert the integer into time you must pad the value with leading zeros and then break it up into parts.

NOTE: I was using SQL 2008 R2. SQL 2012 includes the FORMAT function that would have allowed me to insert the colons and break up the digits in one step using the character mask ‘##:##:##’.

At this point I realized that I was going to have to convert several time values into text using the same logic above so I decided to write a function. In the process I also was able to clean it up a bit so that it displays the time in 12 hour format with no milliseconds and including the AM or PM. Here is the script for the function that will be used below.

Undaunted by that task I moved on to tackle the hard part; how to report the frequency that each job is scheduled to run.

SYSJOBSCHEDULES

First, jobs can have multiple schedules so there is an intersection table called SYSJOBSCHEDULES that contains a job_id and a schedule_id. Pretty straight forward; that is about all we need to find all of the schedules for each job.

SYSSCHEDULES

I used a couple of sources to decipher the sysschedules table. The first is BOL. It contains the definitions for the important fields that I would need. Let’s list the important ones here:

schedule_id: int, ID of the SQL Server Agent job.

name: nvarchar(128), The name of the schedule.

freq_type: int, How frequently a job runs for this schedule. Value is combined with freq_interval and freq_relative_interval to determine the days that the job is executed. See the table below.

Freq_type

Freq_interval

1 Once

Unused (0)

4 Daily

Recurs every freq_interval days

8 Weekly

1 = Sunday

2 = Monday

4 = Tuesday

8 = Wednesday

16 = Thursday

32 = Friday

64 = Saturday

16 Monthly

On the freq_interval day of the month

32 Monthly, relative (also uses freq_relative_interval)

Freq_relative_interval

1 = First week of the month

2 = Second week of the month

4 = Third week of the month

8 = Fourth week of the month

16 = Last week of the month

freq_interval

1 = Sunday

2 = Monday

3 = Tuesday

4 = Wednesday

5 = Thursday

6 = Friday

7 = Saturday

8 = Day (every day of the week)

9 = Weekday

10 = Weekend Day

64 Runs when SQL Agent starts up

Unused (0)

128 Runs when computer is Idle

Unused (0)

Freq_recurrence_factor: int, If Freq_Type is 8, 16, or 32, the job will run every freq_recurrence_factor Weeks, or Months.

Freq_subday_type: int, If the job runs multiple times per day Freq_subday_type describes the units to be combined with the freq_subday_interval. The valid values are:

1 = Job runs once at the specified time

2 = Seconds: Job runs every Freq_subday_type seconds

4 = Minutes: Job runs every Freq_subday_type minutes

8 = Hours: Job runs every Freq_subday_type hours

Active_start_date: int, The date that the job will begin in the form YYYYMMDD

Active_end_date: int, The date that the job will end in the form YYYYMMDD

Active_start_time: int, The time of day the job will start. It is the same logic described in the last_run_time discussion above

Active_end_time: int, The time of day the job will end. It is the same logic described in the last_run_time discussion above

Those are the main fields that are used to control the frequency that the job runs. Now let’s dive into the values and see how to convert into a text description. Notice that the values of freq_interval are powers of 2 when freq_type = 8 (Weekly) This is how the check boxes for each day of the week are stored. So we will need to parse the bits to decode which boxes are checked. I found a good article that describes this bitwise logic here: http://www.sqlphilosopher.com/wp/2013/01/sql-agent-job-frequency-intervals-in-plain-english/

In fact, the above article is the basis for the query that I wrote. You will notice similarities. I merely built on the script that I found there. That article got me pretty far along the process but it had to be repeated for freq_relative_interval when freq_type = 32.

The first part of the script is to declare 4 table variables: @daysOfWeek, @daysOfWeek_relative, @weeksOfMonth and @ordinal. Each table has 3 fields; a Row number, a code for the lookup for the row and the text interpretation.

A couple of things to notice; first, the @daysOfWeek and @weeksOfMonth table code fields correspond to the bit mask that I mentioned above that comes from freq_interval and freq_relative_interval respectively. We will use that in the next part of the script to create a comma separated list for the days of the week and the weeks of the month that the job is scheduled to run. Second the @daysOfWeek_relative table contains some tags (<<wk>>, <<n>>) that will be replaced with text values later in the script. I did it this way because the sentence structure wasn’t quite the same for all of the schedule descriptions but they all used the same basic information. This allowed me to insert the variable text in the right spot for each sentence type.

Now let’s look at how to convert the freq_Interval and freq_relative_interval values from a bit mask into a comma separated list of days and weeks. I did this with two CTEs. One called CTE_DOW for the days of the week and another called CTE_WOM for the weeks of the month.

Each Common Table Expression does essentially the same thing with different fields. The two big takeaways from this part of the script are the ‘&’ bitwise AND operator and the for xml path. As mentioned above the sqlphilosopher.com article does a good job of explaining how that works so I won’t include that here but the for xml path(‘’) is necessary to pivot the data from rows to a comma separated list. This is basically done by creating an XML string with no tags and building the comma separator into each value of the list. Also note that the STUFF command strips off first two characters which will be a leading comma and a space. If you are working with SQL 2005 you can use a substring instead.

At the heart of the query are the two case statements for the Frequency and Interday_Frequency output fields. They interpret the freq_type and freq_interday_type values into the correct sentence structure. The tags that I mentioned above come into play in the Frequency field when freq_type = 32. I didn’t want to add yet another case statement at that point. I noticed that the same values were used in all of the descriptions just in different places so I was able to use two replace commands to insert the variable data in the place where it belonged.

I set up a couple of test schedules in the SQL Server Agent and compared the output of my script to the description that SQL provides to make sure it looked good to me and then worked through the different scheduling options to make sure the solution was complete. Below is a sample of what I was looking at when comparing the two.

You may notice that my descriptions are not identical to the ones generated by SQL Server, but I decided that my descriptions are close enough and they covered all of the options that SQL provides. I hope this helps the next time you have to do discovery on the jobs running on an unfamiliar server. The script should go a long way to seeing when things run at a glance. The code in this article is contained in the attachment decipher_sysschedules.zip