|
Results |
|
ERO: DB2 performance problems since upgrade to 5.6
An ERO customer recently upgraded to CMN ZMF 5.6.0 from 5.5.0. This upgrade coincided with intermittent DB2 performance problems that when encountered, can stop all other work on their development LPAR. The customer has analysed their DB2 environment with their DBAs but no obvious resolution from a DB2 perspective appears to exist.
|
|
|
KM-Dim9: You can configure Dimensions to use the DB2 Call Level Interface (CLI), which provides tighter integration with DB2, eliminates reliance on unixODBC, and provides a small improvement in performance.
applied FixPack 6 for DB2 , and the native DB2 CLI seems to be working now. You can configure Dimensions to use the DB2 Call Level Interface (CLI), which provides tighter integration with DB2, eliminates reliance on unixODBC, and provides a small improvement in performance. To configure Dimensions to use DB2 CLI:
|
|
|
ERO Audit Performance: How to troubleshoot long running ERO Audit jobs
If your ERO audit jobs are running for an excessive period of time, in some cases, an hour or more, the first step is to perform some basic DB2 maintenance. The primary cause of long running ERO audits is poorly optimized DB2 access paths.
|
|
|
DB2 questions regarding PDSPLAN1-PDSPLAN2 and DB2 option 7
1. Why and when does FDM-DB2 use PDSPLAN2 with (RR) repeatable read? 2. Will option 2 - edit table cause any performance issues for huge table? 3. Option 7 always shows inactive even if I can edit and save table.
|
|
|
ZMF 7.1.3.01 performance spikes – ERO audit processing
A customer has upgraded from ZMF 7.1.1.02 to 7.1.3.01 and have encountered several performance issues. They are a large volume data, highly automated (i.e. lots of custom XML Service routines), ERO & USS shop. We have ruled out all the usual suspects (e.g. DB2 table tuning, etc.) and are now trying to pick through and identify the performance spikes.
|
|
|
Audit Performance Tuning using Date/Time Stamp in audit trace.
This TIME STAMP is needed to highlight which files and or subsystems are causing the problem. When you had the TIME STAMP information you could tell if DB2 was the problem or a large loadlib that needed to have CMNFIX10 run against it was the problem. The TIME STAMP information could also be used to test performance enhancements of staging PDS directories into memory and to reduce DASD Read Contentions.
|
|
|
How can you improve audit performance?
4. Activate CMNEX022 to exclude selected components from audit. 5. Build a secondary non unique index to the DB2 Impact Analysis table. This improves performance accessing the DB2 Impact Analysis table.
|
|
|
Setting UDB/DB2 database parameters for DS installtion
Tables, Store System Temporary Tables) 5. Click Next for "Tune the performance of this database". 6. Click Next for "Specify the locale for this database".
|
|
|
ChangeMan ZMF Compatibility with DB2 Version 8
This is not a ZMF facility. This trace facility in DB2 V8 seemed to cause much more of a performance impact in V8 than in prior releases of DB2 . It is essential that you disable the DSNTRACE ddname in the started task JCL, unless otherwise instructed by ZMF Support. To disable DSNTRACE requires that the ddname be either removed or commented out.
|
|
|
Change Man and DB2 Version 6
These are in the area of User Productivity, and include items such as User Defined Functions, Triggers, and Stored Procedures. Although Stored Procedures are not new, their implementation has changed significantly in DB2 V6. The other enhancements in DB2 V6 (i.e. capacity improvements, performance improvements, Data Sharing, etc. are specific to DB2 and would require no enhancement or change to Change Man.
|
|
|