Changes in the TimerJobHistory table maintenance introduced in April 2018 CU for SharePoint 2013

In December I discussed a major change in the TimerJobHistory table maintenance introduced in November 2017 CU.
Historically SharePoint 2013 preserved the timerjob history for all timerjobs which ran in the last 7 days. Starting with November 2017 CU for SharePoint 2013 (build 15.0.4981.1002), the maintenance of the [dbo].[TimerJobHistory] table has been updated in a way that it will never keep more than 10,000 job records.
Several customers provided feedback to us that the new maintenance strategy caused problems in larger farms with long running timerjobs. For these customers the hard coded number of 10,000 records prevented them from seeing if the long running timerjobs succeeded or not, as they were purged from the table at the moment the timerjob finished.
To solve this problem April 2018 CU partially reverted the change in the TimerJobHistory table maintenance back to time based trimming rather than trimming on a fixed number of records. Starting with April 2018 CU the timerjob history for all timerjobs is preserved for 3 days. This is in line to the maintenance strategy used on SharePoint Server 2016.
This also means that it is again important that the Delete Job History job runs successful on a regular basis.

7 Comments


  1. Hi Stefan ,
    So, unlike individual jobs doing their History Clean up job after November 2017 CU to Trim down to 10,000 rows , Now after April 2018 CU or later single Job (Delete Job History ) will be responsible for Cleaning up History like in past (condition before-Nov CU) , However instead of 7 days History will be preserved for 3 days , right ?

    Reply

      1. thanks for Quick response Stefan , it could be compromise between configuration database becoming bloated/Performance & Availability concern vs Visibility of long running timer jobs succeeded or not , Hopefully this brings balance between these two

        Reply

  2. I never thought of our farm as large at only four servers. Certainly nothing compared to some other SharePoint customers. Yet, my custom timer job looses all of its history within three hours with the November 2017 CU change. Now with the April 2018 CU change, I’ll be able to keep the history for 3 days (MUCH better), but still not great. What about the jobs which run weekly or even monthly? I’ll have a mere three days to see their history. Worse yet, the “Last run time” in the job definition page (JobEdit.aspx) in CA shows “N/A” after the job history is cleaned out. It appears as if the job has never ran… but it has!
    The problem could be better addressed by keeping the last 50 or so histories of each timer job. That way, the multitude of jobs which run every minute on each server of the farm won’t clog up the history tables. Besides, would you really need to see the history information for a job which ran 4,320 executions ago (60 minutes x 24 hours x 3 days)?! If a job is disabled, no matter how often it runs, it certainly would be good to see when it last ran… especially if it last ran 300 days ago. And, I definitely need to know when my custom weekly and monthly jobs last ran without having to check it every couple of days.
    PLEASE consider a new approach for the Delete Job History job and related stored procedures. Thanks!

    Reply

    1. Hi Paul,
      SharePoint 2013 is now in extended support. That means that no further hotfix requests or change requests will be considered for this product.
      If you need a different behavior I would recommend to upgrade to SharePoint 2016, open a support ticket against this product and request a design change for SharePoint 2016.
      Cheers,
      Stefan

      Reply


  3. Hello Stefan,
    In SharePoint 2019 server I faced a performance issue on all sites. Got fixed after updating statistics on SharePoint ConfigDB. Noticed that TimerJobHistory table was bloated around 9M records.

    I had also validated below property is set to 0 along with the DaysToKeep=3.
    $history = Get-SPTimerJob | Where-Object {$_.name -eq “job-delete-job-history”}
    $history.TableRowCountThreshold

    Can this property be used to override the default 3 days of timerjob history retention threshold?

    Reply

Leave a Reply to Mohanghimire Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.