Answers.Body: <p>Truncate civicrm_job_log as often as you like - the data is only of very very marginal interest and only for a short period</p>
  
  <p>I usually prefer to turn on DB logging - in which case the data in the civicrm_log table doesn't really add anything - it's only a little bit useful IMHO anyway.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-29T10:04:35.553Z
Answers.LastActivityDate: 2016-06-29T10:04:35.553Z
Answers.UserDisplayName: eileen
Answers.Body: <p>I think you can safely trim the civicrm_job_log, only the latest entries are probably useful (and given how little information the cronjobs return, I'd even doubt that ;)</p>
  
  <p>As for the civicrm_log (or subscription history), it might be more risky to remove as you will loose "useful" history of what happened with your contacts, but from a technical point of view, it shouldn't be an issue, as long as you are ok losing that history. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-08T13:16:54.290Z
Answers.Text: Thanks, Xavier. Yeah I think I can live with not knowing that a record was changed some time in 2003, so I'll set up a cronjob to keep these tables trim. Many thanks.
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-08T13:18:43.793Z
Answers.Text: Would be awesome if you would write an extension that provides a browser interface (using the api) for that trimming, ideally with a param to set the cut off date (eg delete everything that is older than "delta" days ago)
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-08T19:53:39.673Z
Answers.Text: What if said extension "archived" the "useful" history from civicrm_log to a separate table, or .sql file?
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-09T09:28:21.517Z
Answers.Text: Is it safe to trim civicrm_log? Since it stores a change history, by removing some of the first rows you might be removing original values?
Answers.UserDisplayName: John
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-09T09:48:12.547Z
Answers.Text: the latest version is always stored into the "real" entity (eg. civicrm_contact). The log mostly doesn't contain any data per se, only meta data (bob changed the contact on the 1st of april last year)
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-10T14:03:37.590Z
Answers.Text: @Xavier Could you take a look at this? https://github.com/artfulrobot/uk.artfulrobot.loglop
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-11T07:59:42.653Z
Answers.Text: Looks good, but please https://github.com/artfulrobot/uk.artfulrobot.loglop/blob/master/api/v3/JobLog/Loglop.php#L36 don't return success when it's clearly a failure, throw an error
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-08T12:57:30.017Z
Answers.LastActivityDate: 2016-03-08T18:42:17.373Z
Answers.LastEditDate: 2016-03-08T18:42:17.373Z
Answers.UserDisplayName: Xavier
Body: <p><code>civicrm_job_log</code> is the biggest table in my database by an order of magnitude. And <code>civicrm_log</code> is the fifth biggest.</p>
  
  <p>Can I trim these somehow, e.g. a cron job that removes old logs? It's making the backups slow.</p>
  
  <h2>EDIT: Here's an extension that keeps the job log from bloating</h2>
  
  <p>Thanks to the input here, I've created the <a href="https://github.com/artfulrobot/uk.artfulrobot.loglop" rel="nofollow">Log Lop extension</a> that allows users to configure a maximum age for keeping job logs. Will submit to the extensions directory after a bit more testing/few more eyes have looked at it.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-08-24T17:42:43.317Z
Comments.Text: In fact, that extension isn't necessary or a good idea either, just enable the core system job "Clean-up Temporary Data and File" [as noted when you click through to that extension].
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-08-25T18:18:43.217Z
Comments.Text: Thanks @AlanDixon
Comments.UserDisplayName: artfulrobot
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-08-25T19:57:46.770Z
Comments.Text: Ah, but thank you for posting the original issue.
Comments.UserDisplayName: Alan Dixon
Tags: <logs><4.6>
Title: Can I safely trim civicrm_job_log and civicrm_log?
ThreadText: # Can I safely trim civicrm_job_log and civicrm_log?
  
  (Asked by: username_0 on 2016-03-07)
  
  `civicrm_job_log` is the biggest table in my database by an order of magnitude. And `civicrm_log` is the fifth biggest.
  
  Can I trim these somehow, e.g. a cron job that removes old logs? It's making the backups slow.
  
  ## EDIT: Here's an extension that keeps the job log from bloating
  
  Thanks to the input here, I've created the [Log Lop extension](https://github.com/username_0/uk.username_0.loglop) that allows users to configure a maximum age for keeping job logs. Will submit to the extensions directory after a bit more testing/few more eyes have looked at it.
  
  **Tags:** logs, 4.6
  
  > **Comments:**
  > **username_1**: In fact, that extension isn't necessary or a good idea either, just enable the core system job "Clean-up Temporary Data and File" [as noted when you click through to that extension].  
  > **username_0**: Thanks @username_1  
  > **username_1**: Ah, but thank you for posting the original issue.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2016-03-08. Score: 4 | Accepted answer
  
  I think you can safely trim the civicrm\_job\_log, only the latest entries are probably useful (and given how little information the cronjobs return, I'd even doubt that ;)
  
  As for the civicrm\_log (or subscription history), it might be more risky to remove as you will loose "useful" history of what happened with your contacts, but from a technical point of view, it shouldn't be an issue, as long as you are ok losing that history.
  
  > **Comments:**
  > **username_0**: Thanks, username_3. Yeah I think I can live with not knowing that a record was changed some time in 2003, so I'll set up a cronjob to keep these tables trim. Many thanks.  
  > **username_3**: Would be awesome if you would write an extension that provides a browser interface (using the api) for that trimming, ideally with a param to set the cut off date (eg delete everything that is older than "delta" days ago)  
  > **username_4**: What if said extension "archived" the "useful" history from civicrm_log to a separate table, or .sql file?  
  > **username_5**: Is it safe to trim civicrm_log? Since it stores a change history, by removing some of the first rows you might be removing original values?  
  > **username_3**: the latest version is always stored into the "real" entity (eg. civicrm_contact). The log mostly doesn't contain any data per se, only meta data (bob changed the contact on the 1st of april last year)  
  > **username_0**: @username_3 Could you take a look at this? https://github.com/username_0/uk.username_0.loglop  
  > **username_3**: Looks good, but please https://github.com/username_0/uk.username_0.loglop/blob/master/api/v3/JobLog/Loglop.php#L36 don't return success when it's clearly a failure, throw an error  
  
  ---
  
  ### Answer by username_2 on 2016-06-29. Score: 3
  
  Truncate civicrm\_job\_log as often as you like - the data is only of very very marginal interest and only for a short period
  
  I usually prefer to turn on DB logging - in which case the data in the civicrm\_log table doesn't really add anything - it's only a little bit useful IMHO anyway.
  
  
  ---
  
  