Fixes are available
APAR status
Closed as program error.
Error description
Operations Console, as shipped at 8.7 has some performance and scalability problems. If the Operations Console database contains a very large number of job runs, for example (c. 200,000), then response time from the UI is very slow and as the number of job runs grows it will eventually fail due to memory usage problems. This is true of both job runs and job log entries. The time for the UI to retrieve the service status is also very slow, irrespective of number of records in any table. The first problem occurs because all rows are returned to the client, before any selection or sorting is performed. The solution to this is to perform all selection and pagination on the server side via the database. Only the required rows are then returned to the client. The second problem occurs due to an internal design problem which means the status information is retrieved twice each time before it is displayed. The retrieval time can be halved by only retrieving the data once.
Local fix
Problem summary
**************************************************************** USERS AFFECTED: Users of Operations Console with high numbers of job runs. **************************************************************** PROBLEM DESCRIPTION: If the Operations Console database contains very large numbers of job runs, then the UI can have memory and performance issues, even when getting single pages of rows. **************************************************************** RECOMMENDATION: Apply patch or fix pack. ****************************************************************
Problem conclusion
Re-work selection of job run data so that only the a page worth at a time of data is returned to the client, when data is being paged. Re-work selection of job run data so that only the a page worth at a time of data is returned to the client, when data is being paged. IMPORTANT This fix changes the structure of the DSODB database. IF YOU HAVE CREATED A DSODB DATABASE AND HAVE NOT PREVIOUSLY INSTALLED THE OPERATIONS CONSOLE ROLLUP PATCH FOR 8.7: After installing the fix pack, there is a manual step that must be performed before the patch is usable. The patch requires an update to the operations database schema content, where this update adds some new database functions that are required by this patch. The instructions to follow are described in the readme.txt file in the path Server/DSODB/scripts/{database}/readme.txt where {database} is the database type for the DSODB database, for example DB2_LUW_9_7. Note: For DB2 v10, follow the instructions for DB2 v9.7 Step A in the readme.txt must always be followed even if a DSODB database already exists, as this step will generate the scripts to either create a new database to include these additions, or to add the required schema additions to an existing DSODB database. When running Step A, the 'upgrade' option will only need to be specified if the DSODB database already exists. If a DSODB database already exists then the other arguments to the command in Step A must be the same as were specified when the DSODB database was created. The actions for Step B are dependant on whether a DSODB database already existed before installing this patch, and are as described in the readme.txt file. If a DSODB database already existed then after running this manual upgrade to the database, the AppWatcher process will need to be restarted. For Windows, this can be done from the Control Panel services menu or from a command window: net stop "DataStage AppWatcher Service" net start "DataStage AppWatcher Service" For Unix/Linux, this can be done by running the following command as the datastage administration user (e.g. dsadm) IBM/InformationServer/Server/DSODB/bin/DSAppWatcher.sh -stop IBM/InformationServer/Server/DSODB/bin/DSAppWatcher.sh -start If the Operations Console Rollup Patch for 8.7 has previously been installed, or if no DSODB database has been created, these instructions can be ignored.
Temporary fix
Comments
APAR Information
APAR number
JR41540
Reported component name
WIS DATASTAGE
Reported component ID
5724Q36DS
Reported release
870
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2011-12-22
Closed date
2012-01-30
Last modified date
2012-10-12
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
SERVER
Fix information
Fixed component name
WIS DATASTAGE
Fixed component ID
5724Q36DS
Applicable component levels
R870 PSY
UP
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSVSEF","label":"InfoSphere DataStage"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.7","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
11 October 2021