View - SARDBASE LOAD Process Taking a Long Time

Products

• Deliver
• View

Issue/Introduction

The running of a SARDBASE LOAD is taking a long time. What could be the problem?

Resolution

A SARDBASE LOAD will take longer than a SARDBASE UNLOAD because the LOAD optimizes where the reports will go in the new database.
In this instance, the second tape took longer to fill than the first tape because the View Index took up much of the first tape. 

The movement of index data takes less time than the movement of report data, as View will space reports across the data space using space efficiencies.There could also involve additional time if a report spans tapes. 

The SARDBI23 messages indicated an increased data usage percentage, and as the database space becomes full, it takes more effort for View to find the proper space to load the reports.

Loading reports to a database that is continually running low on space, plus having the extents on the same pack, is what would cause the slow activity.

To minimize contention, we recommend that each database extent be placed on a separate dedicated volume. 
Where possible, the size of the volume should match the size of the database extent.
A matching database extent prevents I/O for multiple extents from queuing on the same device address.

Also, the first extent of the index and the database must be placed on separate dedicated volumes because the RESERVE processing uses the dataset name and volume of the first extent to serialize all accesses.

The client's SARDBASE STATUS FULL output showed where the ....D0000001 and ....I0000001 database extents were on the same volume.

Loading reports to a database that is continually running low on space, plus having the extents on the same pack, is what would cause the slow activity.