... can I do something to push DBO Reload running faster?
YES YOU CAN!
Look to the reports from your current reload execution and check the DATA BASE I/O STATISTICS report for the primary database:
If the numbers on the report's RANDOM column are 'fairly high' compared with those numbers on the SEQUENTIAL column, there is too much activity on the random access thread, which slows down the performance for reload (actually most of these values on the RANDOM column should tend against 'zero' with optimal performance).
In addition there are two important numbers also on the SEQUENTIAL column of this report:
The numbers for PHYSICAL I/O and LOAD MODE I/O should be almost identical, which indicates that most of the physical IO operations have been done in load mode, which is most beneficial for reload performance.
WHAT DO I NEED TO DO?
Just allocate more 'BH (Buffer Handler) BUFFERS' on the sequential thread by using execution option BUF4SEQINIT=n on the DBO Reload DBOCTRL DD statement.
The default setting for BUF4SEQINIT depends on the database type and access method - e.g. BUF4SEQINIT=10 is used by default in many cases, which is not enough with fairly unorganized huge databases.
WHICH IS A GOOD VALUE FOR BUF4SEQINIT?
Again, this depends on the database type, access method, the number of segments and how much the database is unorganized - but usually a value of
BUF4SEQINIT=(number of CIs per Cylinder) multiplied by 2
is a fairly good starting point for most databases (the value for number of CIs per Cylinder is also shown on the DBO Reload output - see BLOCKS PER CYLINDER on the DATASET CHARACTERISTICS report).
If the values on the DATA BASE I/O STATISTICS report should still be bad after this change, doubling the number of buffers should again increase the reload performance.
EXAMPLE:
The DATA BASE I/O STATISTICS report shows these values after reloading an HIDAM database containing 13.5 million segments:
DATA BASE I/O STATISTICS
DDNAME: I10D DATA SET NAME: IDI.IMSDB.I10D
SEQUENTIAL RANDOM
__________ ______
BUFFER HITS 13,501,636 2,863
PHYSICAL I/O 318,349 14,301
READS 0 8,582
WRITES 314,913 5,719
ERASES 0 0
CHECKS 0 0
POSITIONS 0 0
ENDREQS 2,863 0
BH BUFFERS 10 10
DBO A/M BUFFERS 91 2
ACTUAL A/M BUFFERS 91 11
LOAD MODE I/O 13
FORMAT WRITES 1
FORMAT I/O 0
The Syslog for this execution shows these performance related values: EXCPS=439742 / ELAPSED=00:03:26.32 / CPU=00:00:15.73
Rerunning DBO Reload using option BUF4SEQINIT=360 changes the DATA BASE I/O STATISTICS report to these values:
DATA BASE I/O STATISTICS
DDNAME: I10D DATA SET NAME: IDI.IMSDB.I10D
SEQUENTIAL RANDOM
__________ ______
BUFFER HITS 13,504,500 0
PHYSICAL I/O 6,939 12
READS 0 6
WRITES 312,049 6
ERASES 0 0
CHECKS 0 0
POSITIONS 0 0
ENDREQS 0 0
BH BUFFERS 360 10
DBO A/M BUFFERS 91 2
ACTUAL A/M BUFFERS 91 11
LOAD MODE I/O 6,951
FORMAT WRITES 1
FORMAT I/O 0
The Syslog for this execution shows much better performance related values: EXCPS=114048 / ELAPSED=00:00:47.20 / CPU=00:00:08.07
OSAM considerations:
The performance enhancements with increased values for option BUF4SEQINIT applies for VSAM as well as for OSAM datasets, however these differences need to be considered:
- the EXCPS value being shown on the Syslog for OSAM datasets is not the actual number of physical IOs, and therefore cannot be compared with that value being shown for VSAM datasets
- the same applies for LOAD MODE I/O and PHYSICAL I/O values on the DATA BASE I/O STATISTICS report - these values also are different for OSAM and cannot be compared with those values being shown for VSAM datasets
- in general loading OSAM datasets needs less elapsed time as well as less CPU time than loading the same datasets with using VSAM
Related topic:
There are additional performance options for DBO unload and DBO reload executions - for more details see
https://docops.ca.com/ca-database-management-solutions-for-ims-for-z-os/19-0/en/managing-database-performance/ca-database-organizer-for-ims/operational-considerations-for-ca-database-organizer/optimizing-performance-in-ca-database-organizer
Contact for additional information on this Update
Dietmar.Lettow@ca.com