Replicating plan data in the database
Storing information about objects in the plan into a database makes accessing the plan data easier and faster. When large numbers of users are accessing the HCL Workload Automation backend environment concurrently, performance and reliability can be compromised. By replicating the plan in a relational database, users can access data quickly and reliably.
- Running baseline reports
- Displaying the plan in a graphical view
- Displaying the job stream graphical view
- Triggering actions
- Refreshing job and job stream monitoring views
All of these modelling or monitoring activities required access to the plan and, if you multiply these scenarios by the number of users who concurrently request access to the plan to perform one or more of these activities, the result is slow response times and overall performance.
To address this issue, HCL Workload Automation replicates the plan in a relational database where SQL statements are used to retrieve data rapidly and reliably. New message boxes, mirrorbox.msg and mirrorbox<n>.msg, are used to synchronize the database with the Symphony file. If the mirrorbox.msg file becomes full, for example, if the database remains unavailable for a long period of time, then the plan is automatically reloaded into the database using the information in the Symphony file.
In particular, the performance and response times of the UpdateStats script have greatly improved with this new way of managing plan data.
In addition, each time the plan is extended, the plan in the database is scratched and re-created, making the latest information available to all users. To manually replicate plan data from the Symphony file to the database, run the planman resync command.
The synchronization of the Symphony file with the database is enabled automatically when you add the Sfinal file to the database with the composer add Sfinal command. A new job, CHECKSYNC, has been added to the FINALPOSTREPORTS job stream contained in the Sfinal file that is responsible for monitoring the state of the process of replicating the Symphony file in the database. it sends the progress and status of this process to the job log. If the CHECKSYNC job should fail, then refer to the job log of the CHECKSYNC job, as well as the WebSphere Application Server Liberty Base log to determine the problem. After resolving the problem, run the planman resync command to reload the plan data from the Symphony file into the database.
To simplify integrations, a set of database views for a set of tables containing plan data in the HCL Workload Automation database are provided.
To see the database views containing information about HCL Workload Automation objects in the plan, see the views beginning with "PLAN_" in Views available with HCL Workload Automation.
When running operations from the Dynamic Workload Console that retrieve current plan data, if you suspect the data is not up-to-date, you can run planman resync to update the plan data in the database with the latest information in the Symphony file. If the message box, mirrorbox<n>.msg, responsible for synchronizing the database with the Symphony file becomes full, for example, the database is unavailable for a long period of time, then a planman resync is automatically issued so that the plan is fully reloaded in the database.
The following syntax is used to replicate plan data in the database with the data in the Symphony file:
planman [connection_parameters] resync
- connection_parameters
- Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server Liberty Base to the master domain manager. For more information, see Planman command line.
- If you are upgrading your IBM Workload Scheduler environment to version 9.2, then there are a few manual steps you need to implement before your plan data is replicated in the database. See Customizing and submitting the optional FINAL job stream and Automating production plan processing for more information.
- Replicating plan data in the database requires that DB2 JDBC Driver Type 4 is installed. DB2 JDBC Driver Type 2 is not supported.
- Ensure that in the database configuration the CUR_COMMIT property is set to ENABLED. See DB2 documentation for more information about this setting.
For more information about how to optimize the process of plan replication in the database see Tuning plan replication.