Parrallel Merge jobs are slow in performance with a FDB (FILES DATABASE)
search cancel

Parrallel Merge jobs are slow in performance with a FDB (FILES DATABASE)

book

Article ID: 399095

calendar_today

Updated On:

Products

Disk Backup and Restore - MVS

Issue/Introduction

Two MERGE jobs running in parallel, but one of the jobs is not working.

Both are using:

MERGE PERCENT=30,MAXVOLS=150.

The MERGE job that is running took 10 hours and the second job took 6 hours to start

Why is it taking so long? Why is performance so slow?

Is it possible to process more volumes within a reasonable time frame?

Resolution

Run multiple MERGE jobs in parrallel but decreasing the MAXVOLS=100 and use USEARCHVOL as well

USE:

 MERGE PERCENT=30,MAXVOLS=100,USEARCHVOL

Set IOCHNBLK9 and MERREPLYY by adding a SYSPARMS in your MERGE jobs with
//SYSPARMS DD *

IOCHNBLK9

MERREPLYY

SYSPARMSB

The MERREPLYY will allow you to end a merge if need be.

If the problem persists set  MAXVOLS=50 

 

Additional Information

https://techdocs.broadcom.com/us/en/ca-mainframe-software/performance-and-storage/ca-disk-backup-and-restore/14-0/using/merge/merge-command.html

USEARCHVOL
Causes MERGE processing to bypass reading records to determine the actual percent utilization of the archive data set. The percent utilization field (ARCPCTUS) in the ARCHVOL record is used instead in the selection process. Because ARCPCTUS is updated during IXMAINT, the USEARCHVOL parameter can provide a significant performance improvement by not reading the records. The longer the period after IXMAINT was run, the larger the percent difference between MERGE with and without USEARCHVOL. This option is only available when a Files Datacom Database is being processed.
This parameter is not supported when merging Unix archvols (MERGEU).