Performance Tips

Save performance can be a reflection of how you have completed the Robot Save setup panels. This document is meant to explain why saves can have different performance results depending on how you have supplied these values.

In general, the following items affect the performance of a save. See below for tips on controlling these issues with Robot Save.

1: Processor or Tape Drive

Obviously, you can always invest more money into your hardware to resolve performance issues. The tape technology on the AS/400 has improved drastically over the years, as has the AS/400 processor. The capacity of individual tape drives has certainly increased over the years. And, the costs of these tape drives has decreased considerably over time.

For instance, with an IBM 8mm Automated Tape Library (ATL) (20 cartridges), each cartridge can hold as much as 5 GB per tape, uncompressed. Or, if you use an IBM 3590 Magstar 10-cartridge stacker, each tape can hold 20 GB of uncompressed data. The IBM 3570 Magstar MP holds 20 cartridges each of which can hold about 7 MB of uncompressed data. The IBM 3580 LTO Ultrium drive is sold as a standalone unit or as part of the 358x series of AMLs. Each cartridge can hold 100 GB of uncompressed data.

In addition to the IBM tape drives, StorageTek Corporation offers several drive units that are compatible with the AS/400. TimberLine drives use 3490 tapes and hold about 800 MB of uncompressed data. The drives are found in the Wolfcreek, PowderHorn, and TimberWolf tape librarians or can be purchased separately. Or, consider the Twin Peaks drives found in the TimberWolf or as standalone units. These drives also use 3490 tapes holding 800 MB of uncompressed data.

2: Size and Activity Level of the Memory Pool

Save operations on the AS/400 do need more resources than most other tasks. Your performance monitoring process should review performance of the memory pools in which save activities are running. You should make the memory pool for the save as large as possible.

The number of activity levels within the memory pool also can affect the performance of a save. Because saves normally run in batch, it is recommended that you run them in their own memory pool with at least one activity level. If you do run your saves interactively or in a multi-job memory pool, you should make sure that your memory pool always has one activity level available for your save operation.

If you are running in a restricted state, you don’t need to worry about tuning these features of the AS/400.

Time slice is another feature that can be tuned for save operations. In general, large time slice values should be used for save operations. You can easily double the size of the normal batch time slices. Time slices are defined on the AS/400 object, CLASS. You can use the WRKCLS command to modify these objects.

3: Size of the Machine Pool

The size of the machine pool can affect the speed of the save process. If your machine pool is too small, you need to increase the memory pool size during backups. Your machine pool is not performing well if the non-database faults are greater than 2.0 on a CISC machine or 10.0 on a RISC machine. You can determine this by monitoring the machine pool using the WRKSYSSTS command during the save operation. You can schedule this command using Robot, the job scheduler.

4: Size of the Data Being Saved

What can you do? You need to back up your data. We suggest that you make sure the data you are backing up needs to be backed up. On a daily basis, you should only back up the data that changes often. On a weekly basis, back up data that changes occasionally during the week. Once a month, back up your
operating system and the rest of the your data.

So, to help your backups become more efficient, spread them out during the month to back up the most frequently changed data most often. SAVLIB *NONSYS and SAVSYS should be done once a month unless you can afford the downtime more frequently.

5: Types of Objects

Multi-member files—either database or source files—take longer to back up than does a single object with just one member. The system has to check each member of the object for authorization, change dates, locks, and so on. Documents in the QDOC library saved with the SAVDLO operation also are slow to back up. On V4R4 or higher systems, consider storing all PC data in the root directories, not in the QDLS directory.

6: Number of Objects

Similar to the problem with multi-member files is the number of objects in the library. A library with a lot of objects will take longer to back up than a library with a few large objects.

7: Restricted State Saves

These types of saves perform the fastest. The main reason is that, in restricted state, the save operation does not have to check for object locks. A library with many small objects will save much faster during restricted state.

8: Authority of the Users

If the user running a save has *ALLOBJ authority, the operating system does not have to check each object on the system for whether or not the user is authorized. If a user runs a save without *ALLOBJ authority, each object will be checked to see if the user has authorization to the object, slowing down the save. So, all saves should be executed with a profile that has *ALLOBJ authority.

9: Other Activity on the System.

It goes without saying that other activity on the system will adversely affect your save process. It is always best to have no other system activity, if possible. Obviously, it is not always an option to have all other activity halted during your saves.

10: Save While Active

This is a nice feature of the IBM i that allows you to back up libraries while they are being used. Save while active will cause your saves to last longer than normal, but users can be using the library during the save. Save while active has limitations, however. Only record manipulations can be performed while the save is being run. No object manipulations, such as ALCOBJ, RGZPFM, ADDPFM, RNMOBJ, and so on, are allowed. Use the save while active feature to save libraries while users are in the application. You also can use save while active to limit the amount of downtime for a user. To do this, monitor for a message that states the save operation has successfully grabbed a snapshot of the library being backed up. The end user can then be allowed to use the application again, as long as they only do record manipulations (change, add, delete).

For example, assume your save now runs for 2 hours, from 8:00 to 10:00 p.m. If you want to reduce your downtime, you could do the following. At 8:00 p.m, shut down the QINTER subsystem. At 8:02, start the save operation with save while active specified. At 8:10, the save operation sends a message to a user-defined message queue saying it has a snapshot of the library. Your application, which is monitoring the message queue, sees the message and restarts the QINTER subsystem. The end user can sign on at 8:11 p.m. and continue working. The save continues until 10:15 p.m. In this example, the end user has only 11 minutes of downtime. Of course, the actual time frame will vary depending on your library sizes, and so on.

Because save while active does cause saves to run longer; you should use it only when you know for a fact that you will have users using critical files during the save and have no choice.

When you use save while active, specify either *LIB or *SYNC. Use *LIB when backing up one library with the SAVLIB or SAVCHGOBJ commands. Use *SYNC for multi-library backups.

11: Output Parameter

This is a feature for all save commands that has existed on the AS/400 since release V2R3. This option can produce a database file or report that tells you what was saved during the save operation. However, this can affect performance of the save because the file or report has to be built for each library, object, or member, depending on how you specify the parameters.

We recommend you do not use this parameter for libraries other than database libraries, documents, and source file libraries. Some exceptions can be made for program libraries that change frequently due to development changes.

12: Software Data Compression and Hardware Compaction

Software data compression is extremely slow and should be used only in conjunction with writing data to a save file first. The only reason to use it with save files is because you want to conserve disk space on your AS/400. Do not use this parameter to save space on your tapes. Tapes are generally cheap and most drives now support hardware compaction, which is a much better choice.

Hardware compaction will save tape space and it is fast. Consequently, it will not degrade the speed of writing to tape. You should always use hardware compaction if it is available.

Both of these parameters are supported by all save commands.

13: Save Access Paths

This parameter can be specified on both the SAVLIB and SAVCHGOBJ commands. Saving access paths will slow down saves, but you should still specify *YES for this parameter. When you try to restore physical files from tape you will soon understand why you need the access paths. Upon restoration of a physical file, the system has to rebuild the access paths for any index over a logical file if you did not save the access paths. This can take hours, or maybe even days, if your files are very large.

14: SAVLIB *NONSYS or SAVCHGOBJ *ALLUSR

Using either of these operations is faster than saving one library at a time. The AS/400 can work on the next library being saved while saving the previous library. As the administrator of a save, you must make a decision on what is faster. There is a break even point where you should just save everything because you can do it in the same amount of time.

Controlling these Performance Issues with Robot Save

Issues 1, 2, 3, 5, 6, 8, and 9

These issues are the same for save operations with or without Robot Save. You control them outside of Robot Save. Issues 4, 7, 10, 11, 12, 13, and 14 can be controlled a little differently with Robot Save.

Issue 4—Size of the Data Being Saved

This issue can be administered easily with Robot Save. The product allows you to spread out your library backups efficiently. You can set up a strategy to back up only the data libraries that have changed on a nightly basis. Each set definition within Robot Save can have different save operations and different libraries specified. Robot Save also has an option to add any new libraries to a backup set so that no libraries are missed.

Issue 7—Restricted State Saves

This issue can be resolved from the console without an operator by using the Robot Save feature called the Restricted State Utility (RSU). The best results are achieved when you can do a SAVSYS, SAVDLO, SAVLIB *NONSYS, and SAV to your tape drive stacker unit or 8mm drive without having to mount new tapes. The idea is to start RSU at the console, mount your tapes, go home, and have Robot Schedule kick off the saves from console. Robot Alert can be added to page you if the save operation gets an inquiry message, such as an equipment check, out of tapes, and so on.

Issue 10—Save While Active

You can specify save while active on the Backup Class Entry or Backup Set Information panels in Robot Save. Robot Save allows the same options for save while active as IBM commands.

Issue 11—Output Parameter

This issue concerns the output options parameter on the save commands. Robot Save uses this parameter to build its object archive inventory. Object archive is optional; if you do not need a full inventory of every object that was ever backed up, you can turn it off. We recommend that you turn on object archive only for the libraries that contain database files strategic to your business, source files for programs, and documents in QDOC. Object archive in Robot Save can take up lots of extra disk and cause performance degradation. So, make sure you use it wisely. It is a great feature when used appropriately.

Use the System Defaults panel to turn off object archive at the system setup level. Just set the flag to N to turn it off for all libraries.

The Modify Library Save Information panel allows you to turn off object archiving at the library level. Just change the flag to N to turn off the object archive for any of the libraries on your system.

Issue 12—Software Data Compression and Hardware Compaction

These issues are controlled on the Backup Set Information panel. You can turn hardware data compaction on or off by a Y or N flag. You can set software data compression to Y, N, or D:

Y=*YES

If you are saving to tape and the target device supports compression, hardware compression is performed. If compression is not supported, or if the save data is written to a save file or disk, software compression is performed.

N=*NO

No data compression is performed.

D=*DEV

If you are saving to tape and the target device supports compression, hardware compression is performed. Otherwise, no data compression is performed.
Do not set both flags to Y. If a save is running while other jobs on the system are active and software compression is used, the overall system performance can be affected.

If you have hardware compaction, then set it to Y and set software compression to D. The panel below shows these fields.

Issue 13—Save Access Paths

You control the Save Access Paths option on the Backup Set Information panel. This parameter should be set to Y. Saves done outside of Robot Save also should have this flag set to Y.

Issue 14 —SAVLIB *NONSYS or SAVCHGOBJ *ALLUSR

SAVLIB *NONSYS and SAVCHGOBJ *ALLUSR perform faster than saving individual libraries. When you compare the performance of Robot Save to your old method of saving, make sure that you are comparing the same commands. Often, customers compare two unlike operations. The following panel
shows how to specify a SAVLIB *NONSYS in Robot Save.

Summary

Robot Save is a very flexible product. There are many different setup combinations that can affect performance negatively. The product is designed to handle both simple and complex setup. When you do compare Robot Save to your existing backup strategy, make sure you compare the same exact setup. If you don’t know, look at the job log of the save operation to see which parameters Robot Save is using.