Purging old job definitions

[ikkynikinae]

I have an issue in our development environment.  There are literally 4x the number of definitions due to some copying and pasting of entire job groups with hundreds of jobs in them.  I now have tons and tons of duplicates that are not active definitions.  Along the lines of like 40k definitions in development for 10k production jobs that I actually care about.

I'm encountering some performance issues and support is telling me that even the inactive jobs have a large impact on performance.  To the point of saying "well with 40k definitions, you are a large implementation and need more cores, RAM, etc" per the SP2 performance tuning guide.  We are running 6.2.1.315

By this logic, it seems it would be more prudent to permanently purge the 30k definitions I don't need.  Has anyone had any experience along these lines?  

The jobs are already inactive, and what I really am looking to do is purge them completely so that I'm back to a number of definitions (active and inactive combined) that my hardware is scaled for already.  I am struggling already with the assertion that inactive jobs give me as much a performance hit as active jobs in terms of defining the implementation size.

Thanks!

[Dinesh Sankaranarayanan]

How about deleting all the jobs in development and migrating(using Transporter) the 10k jobs from production to development ? would that work ?

(of course, there are additional precautions to be taken in such cases)

[Joe Fletcher · Accepted solution]

There's a new feature in the works which will allow import/export of job definitions to XML files.

Once they release that you will be able to export any unwanted jobs to what is effectively an offline store and delete them from your active instances. Unlike now you will have a useful recovery method should you ever want to restore those job defs.

Other than that about the best thing to suggest is you snapshot the database to preserve a record of what's there and start pruning anything you don't want or need. Transport a copy of anything you might want to keep from your Prod instance to DEV/UAT before you start dropping stuff.

Then, once you've cleared Production repeat the exercise on DEV/UAT.

I'd also recommend you maybe reduce the retention times for job run history to the minimum you can stand. 

Cheers

[Derrick Au · Accepted solution]

Hi ikkynikinae,

Support is right, even inactive jobs may have an impact on performance. Just want to make sure that you have automatic history deletion enabled along with X number of days retention history for jobs, triggers, and message logs, and this you can find under Activities -> Configure Scheduler. What are your current scheduler settings?

Also, run a simple SQL query against the msglog table: select count(*) from msglog. How many rows of data you have? Even though the jobs are inactive now, they may have possibly been active at some point and all the audits get logged in there. So double check scheduler configuration settings, table sizes, and delete the jobs you don't need will lead to a better Tidal experience.

BR,

Derrick Au