The only way that this can be done from what I understand is with our cleanup process.
if you go into the open the Catalog in the UI and then go to "Catalog Update Job Properties" you will see a property called "RESULTS_RETENTION_TIME" you set this to how many days you wish to keep the job results. After doing this, you will need to go into blasadmin and change the setting for the autogeneratedretention to true. When you run our cleanup it will mark items according to their retention time and then the database cleanup will remove them.
1 of 1 people found this helpful
Actually the 'AutoGenerated' policy in blasadmin doesn't affect the RESULT_RETENTION_TIME..
To use the RESULT_RETENTION_TIME of job runs you need to set the property value on the job, and possible in the Property Dictionary as a default, and in blasadmin you need to set the 'enableretentionpolicy' to true in the 'cleanup' section and restart the appserver(s). when you run the 'blcli Delete executeRetentionPolicy' your job runs will be soft deleted.
the autogenerated setting in blasadmin is there to set the retention time for objects (jobs, depot objects, etc) w/ the AUTO_GENERATED property set to true - any object created at a time older than the retention time will be deleted when executeRetentionPolicy runs. typically the remediation and deploy jobs and blpackages that get created by patching will have AUTO_GENERATED set to true as they are typically only run once and then can be deleted.
one thing to be careful of w/ the catalog jobs is that you need to have a good run available for patching jobs to work, so the RESULT_RETENTION_TIME on the catalog jobs should be greater than the interval with which you run the jobs.
Thank you for your answers but it didn't work.
This is what I've done:
- Set the RESULT_RETENTION_TIME value to 90 on the CUJ property.
- Set the 'enableretentionpolicy' to true in the 'cleanup' section with blasadmin utility.
- Restart the appserver.
- Run the 'blcli Delete executeRetentionPolicy'
- Run the 'blcli Delete cleanupDatabase'
- Restart the appserver.
Did I miss something?
you do not need to restart the appserver at the end there.
So - you set RESULT_RETENTION_TIME on the specific catalog update job to 90, saved it, then ran the executeRetentionPolicy and what happened ? were there job runs of the cuj removed that were < 90 days ?
After running executeRetentionPolicy and cleanupDatabase nothing changed. There are the same job runs now than before and there are job runs greater and lower than 90 days.
Follow the below steps and try again:
- set Cleanup EnableRetentionPolicy true
- set Cleanup AutoGeneratedRetentionTime 90 ## This will set for all jobs, if you do not want to set for all jobs, then skip this step
- Restart the Application Server to have this change take effect
- If you want to delete job runs for specific job, then go to Job property and set RESULT_RETENTION_TIME property to 90 days, as Bill said.
- Then run the following command on app server:
blcli_execute Delete executeRetentionPolicy
Step 5 will mark all those job runs as soft delete and it will delete job runs from GUI, in order to delete those permanently, you need to run DB clean up job.
It should work. I have tested in my environment, it worked.
can you show a screenshot of where you have set the RESULT_RETENTION_TIME ? and a shot of the job run history for the cuj ?
Siddu - this is not correct:
set Cleanup AutoGeneratedRetentionTime 90
-> when executeRetentionPolicy runs, this will soft-delete any object that has the AUTO_GENERATED property set to true and is older than 90 days. this will delete the actual object. deploy jobs and blpackages generated by patch remediation jobs have AUTO_GENERATED=true set for example.
They hit below error on their 8.2 SP4 environment:
ORA-02292: integrity constraint (BLADELOGIC.FK1450_SCHEDULE) violated - child record found
I don't think we are setting the RESULTS_RETENTION_TIME value in the right place.
I see we are setting it on the Catalog - "Windows Server 2003 and 2008"
However, we actully need to set it on the job - "Windows Server 2003 and 2008_CUJ-2013-06-24 etc etc"
executeRetentionPolicy and RESULTS_RETENTION_TIME apply to jobs - not to depot objects.
Once you set it on the job, rerun 'blcli Delete executeRetentionPolicy' and it should remove the job runs older than 90 days.
for the cuj he's setting it in the correct place - for catalogs the cuj is kept in the catalog and one of the tabs is for the cuj properties. the cuj name is the catalog name + a string..
This is a bug in 8.2 and 8.3 we have had a call logged for this for some time, the JOB LOGS are cleared by db cleanup by the JOB RUNS remain
I have had some feedback for my call on this issue
"Starting from 8.2 we have removed Catalog update job from the retention based cleanup. Therefore, this is expected behavior"
So from 8.2 onwards you have to manually delete the Job Run entries in catalogue update jobs
I think that it is not possible to manually delete the CUJ runs from the GUI. For other jobs you can right-click delete on the job run, but on the CUJs the Delete option is not available.
Considering the fact that all job run events are being cleaned up correctly based on the retention time, only CUJ runs are still present. Therefore the fact that all CUJ runs are still visible in the GUI will not leave the large amount of old data in the DB.