Hi Scott,

There have been several fixes provided to improve the performance of this background job.

Apart from that it is always recommended to filter the amount of data that will be captured in the background job (for example executing the job for a limited time duration - valid from and valid to period) and executing it during times where user activity is minimum (off peak hours).

Fix IDs include 141973, 146002, 149062, 148596, 148701, 161158, 148854, 148768

You may already have some of these fixes and I have included the provide solution in some fixes.

------------------------------------------

Fix ID 146002: R&D Solution -
1. Creating Activities for Active PM action will be created, separately
2. Background job of Active PM Action break into several jobs. 500 PM will execute in one job. All Preliminary PMs will execute in one background job.

------------------------------------------

Fix ID 149062: Functional enhancement

This is a functional enhancement that has been done to improve the performance of the calendar generation, by giving the user the ability to split and create multiple background jobs at an execution. If the user enables the parallel execution from their end, these split jobs will run in parallel with better execution time.

Design
New Parameter is added to the calendar generation dialog, selection parameters.

Without PM Group/Merge
When the user ticks this checkbox, only the PM Actions that do not include a PM Group ID will generate work orders

A new group is introduced to the calendar generation dialog in name of “Splitting Options”. It includes parameters below
*PM Group ID checkbox
*Split Interval field
*Object ID checkbox
*Maint Org Checkbox
*WO site checkbox

PM Group ID checkbox
This checkbox will be enabled only when PM Group ID is null or equal to ‘%’ and when Without PM Group/Merge checkbox is not selected. When this is selected, a background job for a single execution is split into several jobs, based on the PM Group IDs that are applicable for WO generation for the period specified by the user (start date and end).

Split Interval field
This will split a background job by the number of days defined by the user.

Object ID checkbox, Maint Org Checkbox, WO site checkbox
These checkboxes will be enabled only when the Without PM Group/Merge checkbox is selected (i.e: when no PM group/merge applicable). But the user must be cautious to the fact this might not handle replacement.
Also, these will enable only at a time when the corresponding fields are kept empty or equal to ‘%’ (ex: object id checkbox enables only when the object id field in selection option is empty or equal to ‘%).

When these checkboxes are selected, the execution could be split by object ID, Maint Org or WO Site correspondingly. Split background jobs are validated for basic generation factors to reduce the cost, therefore some splits will be skipped if there are not having generatable PM Actions and sometimes there could be splits that didn't generate any PM Actions due to the fact we are doing only basic validations while splitting and they have been recognized not generatable in actual execution.
All these new features can be used in combination or as user wishes and matches to their data.

------------------------------------------

Best Regards,

Thilini

Thank you for the information Thilini.  I’ll see if we have any of these fixes applied but I don’t believe we do.  For the jobs to run in parallel, is that a matter of configuring the background job queue to allow for multiple jobs to execute at the same time?  I have setup a separate job queue for these calendar generation jobs to execute but I currently have it set to 1 process, I wasn’t sure if setting that to a higher number would cause any conflicts with multiple PM generations running at the same time.

This information might help related to changing the number of processes of the batch queue.  Before increasing number of processes, you must check that the database has a sufficient number of processes assigned in the init parameter job_queue_processes.  Be sure the value assigned is greater than the number of batch queue processes +2 or 3.

To check value of init parameter - either locate and open init<sid>.ora file in Windows Explorer (or if on Unix, go to directory and use editor or more to view the file).  If you do not have access to or cannot locatethe file, you can connect to Sql Plus as IFSAPP or SYSTEM and type: show parameter job. The job_queue_processes parameter will appear and display the value.