How the system restores access paths

The description for a database file contains a description of its access path, if it has one. When you save a database file, you can save the access path with the file. This depends on the type of file, the type of access path, and how you performed the save operation.

When you restore a file, the system either restores the access path with the file or rebuilds the access path based on the information in the file description. The process of rebuilding the access path for a large database file can take a long time. This topic describes when the system restores access paths and when it cannot. If possible, you should plan your save operations to avoid having to rebuild access paths during a restore operation.

The system always restores the access path for a keyed physical file of type *DATA unless the access path was not saved. The access path for a keyed physical file is always saved, unless the access path is not valid at the time of the save.

Normally, source physical files are not keyed. The default value for the CRTSRCPF is to create a non-keyed file. When you restore a keyed source physical file, the access path is rebuilt after the restore operation.

Access paths that are owned by logical files are restored if all of the following conditions are true:

• The system saved the access path. Although this seems obvious, the system only saves access paths if the certain conditions are met.
• All based-on physical files are in the same library and are being restored at the same time on the same restore command.
• If the logical file exists on the system, it does not specify MAINT(*REBLD).
• The logical file owned the access path at the time it was saved.
• If the logical file is created again by the restore operation and it shares an access path that already exists, the key length for the access path must be equal to the maximum key length of the logical file or you receive an error.

If you meet these conditions, you minimize the rebuilding of access paths. However, during the restore operation, the system checks the integrity of each access path. If it detects any discrepancy, the access path is rebuilt.

In a few cases, the system might decide to rebuild access paths even though they were saved. For example, you might have defined a new logical file that specified the same key as the physical file but also specified UNIQUE. The based-on physical file was in use at the time that the logical file was created. Therefore, the system had to create a new access path for the logical file. Assume that you save these two files with a single command. If you restore them with a single command, the system will determine that they can share a single access path. Instead of restoring the two access paths, it builds a new, shared access path for the two files.

A database index, which is a type of logical file, cannot be restored if the associated physical file is missing. If the physical file is restored first, the index must be rebuilt, which can be time consuming. However, if the index is restored first and you specify a defer ID, the index is deferred and can be restored later, along with the physical file's data space. A deferred restore eliminates the need to rebuild the index. When you restore both the logical and physical files, specify the same Defer ID (DFRID) value on the Restore Object (RSTOBJ) or Restore Library (RSTLIB) command.