Home The Company Publications Products Links Tips Jobs

Performance With ADASAV


By Rainer Herrmann, Software AG

Last update: 11 July 2006

The elapsed time to backup / restore is of obvious importance to many installations. This request tries to address some of the major issues and parameters, which will affect the elapsed time of a save/restore operation. To simplify the discussion I will concentrate on the save function, but it will apply equally to the restore function.

From ADABAS 524 ADASAV supports ECKD channel programs and ADAIOR will READ Cylinder I/Os, when applicable. ADAIOR uses QSAM to produce the sequential DDSAVE output, usually to 3480 or 3490 type tape.

To cut down on the elapsed time it is important to overlap the reading from disk and the writing out to tape and this can be accomplished to a high degree. Through the use of the drives parameter several concurrent read and write operations can be active and if successful, the maximum possible throughput will be limited by the total channel capacity available to read the database or more likely the total channel capacity to write out to tape, whichever is less.

This is, however, a theoretical limit, numerous benchmarks show that it is not really possible to achieve such throughput rates and a more practical upper limit for the effective data rate is around 80% of the installed channel capacity.

For example a database residing on 3390s, accessible thru a 3990 controller usually has 4 pathes attached, which has a total channel capacity of 4 times 4.2 Megabytes per second or 16.8 Megabytes per second. If the output goes to tape drives residing on 2 control units which are attached to 3 Megabyte channels the total throughput possible is 6 Megabytes per second and the practical limit will be around 5 Megabytes per second.

As this example shows, in many installations today the tape channel sub- system may be the limiting factor, but a lot depends on current hardware installations and the implementation of feature like IDRC etc. OVERLAP of READ / WRITE operations and the effect of BUFNO and ECKD To overlap read and write operations it is important to understand how QSAM works and how it affects ADASAV.

If the numbers of buffers available to QSAM is small or the default of 5 is in effect, QSAM will wait till all buffers are full and only then schedule a chained I/O operation to empty these buffers. When ADASAV passes another record to QSAM before these buffers are empty QSAM will put ADASAV into a wait. Since ADASAV looses control no concurrent I/O operation for another drive can be operated. When many buffers are specified, usually through the BUFNO DCB parameter, QSAM will start an I/O when either 240K of buffers are filled or 31 buffers are full, whichever is less.

Since ADASAV uses 32K buffers, QSAM will not start more than 8 buffers in one I/O. If m o r e than 8 buffers are specified, ADASAV will be able to pass records to QSAM, while QSAM has I/Os outstanding. Consider what happens when ADAIOR reads cylinder I/Os This will bring in between 700 and 800 Kilobytes of data amounting to about 30 QSAM buffers, depending on the database blocksizes (devicetype) in use because ADASAV will write out the used content of one block as one record to QSAM, so it must fit into one QSAM block.

If BUFNO defaults to 5 in the DCB, 5 blocks will be filled and ADASAV will be put into wait, after which this process repeats itself 6 times before ADASAV regains control and can read another cylinder. Very little overlap will occur nor will there be much concurrency, when the drive parameter was specified. In some cases CKD devices with track I/Os may perform better because more overlap and concurrency will occur. It is very important to specify a correct number of BUFNO as a DCB subparameter.

When CKD devices and track I/Os are in use a BUFNO of 16 should be sufficient. Since one track will usually fit into 2 QSAM buffers - the exception could be a user defined blocksize of 18K, which could need 3 buffers for a 3390 track - ADASAV will be able to fill the remaining 8 QSAM buffers, while the first 8 buffers are transfered to tape, permitting overlap.

When ECKD devices and cylinder I/Os are in use many more buffers are needed, because a cylinder read needs up to 30 QSAM buffer. Since up to 8 QSAM buffers may be already filled but not yet written out, the recommended minimum would be a BUFNO of 38 to avoid long QSAM waits. An even higher value may improve performance but to a lesser degree. Even 38 buffers of 32K requires 1216K virtual storage per drive or ddsave statement. And these buffer reside below the 16 MB limit and need to be pagefixed during the I/O operation in the first 16 MB of Central Storage.

The above example assumes that the blocks are full, however since Adasav writes out with a variable blocksize depending on how much used data of complete ASSO- or DATA blocks in sequence will fit within 32K it may be that 8 QSAM blocks do not make up 240K. Therefor QSAM may write out more than 8 buffers in one I/O and the minimumDCB=BUFNO should be slightly higher for good performance, a BUFNO specification of 42 should be okay.

If the drive parameter is specified, it is better to reduce the number of tape drives than to compromise on the BUFNO DCB parameter. It is very important to understand that the ADASAV BUFNO parameter should not be confused with the BUFNO DCB parameter.

With the ADASAV BUFNO parameter several Read I/Os to the same disk can be scheduled concurrently. This parameter is of very limited value, when the tape subsystem is the limiting factor and may degrade performance because of QSAM waits. With cylinder I/Os it is n o t suggested to increase the ADASAV BUFNO parameter, unless the DCB BUFNO parameter is increased likewise in steps of 30 buffers and the virtual and fixed storage implications below 16 Megabyte considered. Even then performance improvements may be less than expected. For track I/Os there may be some improvement provided the DCB BUFNO parameter is at least (8 plus 2 times ADASAV BUFNO) or 16, whichever is larger.

The drives parameter may increase performance by writing out concurrently to different tape drives. The number of drives depends again on the tape device speed and channel speed. On current 3480 or 3490 tapes and 3 megabyte channel speed most performance is gained, when one drive is active per channel, after which additional performance gains per drive are much less and it may be more beneficial to specify alternate drives to avoid QSAM waits during rewind (3480) processing.

With higher channel speeds, in particular if ESCON channels are installed on tape channel subsystem, many more drives can be specified, because one one drive will not be able to stress the channel. If seperate tape control units are available it is important that different drives are allocated on different tape subsystems. Again the storage implications need to be considered. If several ADASAV for different Databases are started concurrently the number of pages fixed for each drive in each job needs to be considered. With Cylinder I/Os at least 200 pages will be fixed during an I/O per drive.

MVS will not raise the multiprogramming level when more than 82% (default) of the first 16 MB of Central Storage have been pagefixed (3358 frames), will start to reduce the multiprogramming level by swapping out jobs, which have a lot of pages fixed, when more than 88% of the first 16 MB of Central Storage have been pagefixed (3600 frames) and MVS will send out a message when 92% (default, 3764 frames) have been pagefixed, that a shortage pageable storage exist.

Of course Adasav will not be the only in the system, who fixes pages. The above needs a small correction. Since Adasav writes out with a variable blocksize, depending on how much used data of complete ASSO- or DATA blocks in sequence will fit within 32K.

For that reason it may be that 8 QSAM blocks do not make up 240K. Therefore QSAM may write out more than 8 buffers in one I/O and the minimum DCB=BUFNO should be slightly higher for good performance, a BUFNO specification of 42 should be okay.

Please see also the updated article published on SL24

Click here to access SL24

Top Page

Back to ADABAS Tips, Tricks, Techniques -- Overview