SORTLOG—Sort the Log Records during Recovery
The SORTLOG keyword specifies whether to sort the log records before applying them to the tablespaces or indexspaces.
The SORTLOG keyword specifies whether to sort the log records before applying them to the tablespaces or indexspaces. Sorting the log records results in faster performance and faster access to the recovered objects.
When log records are not sorted, objects are recovered in two phases. First, the most recent image copies for the objects are retrieved. Then the log records are used to apply any changes that were made to the objects after the image copies were taken.
When log records are sorted, the objects are recovered in one phase instead of two. Sort work data sets are used to sort the log records by tablespace or indexspace. Each set of log records is then applied to the proper object sequentially during the MERGE phase instead of the LOG APPLY phase. When the last log record has been applied to a particular object, the resources being used to recover that object are released.
Sorting the log records also lets you recover indexes concurrently with their tablespaces. When you specify SORTLOG YES and REBUILD INDEX in the same job statement, the index keys are stripped from the tablespace pages. The keys are sent to separate tasks that rebuild the indexes while the tablespaces are being recovered.
Multiple tablespaces or indexspaces can be recovered concurrently regardless of whether you use the SORTLOG keyword. To recover multiple objects, specify a value of 2 or greater for the MAXTASKS keyword.
Consider the following items when you use SORTLOG:
- If you specify SORTLOG in your SYSIN without including a parameter, SORTLOG YES is used.
- The SORTLOG value in your SYSIN syntax overrides the SORTLOG value inhlq.CDBAPARM(PFR).
- If you omit SORTLOG from SYSIN, the SORTLOG value in your PFR parmlib member is used.
This keyword has the following format:
- NODoes not sort the log records. This value is the default.Use SORTLOG NO when recovering from SNAPSHOTACCESS INSTANT copies, concurrent image copies, inline image copies, and system-level backups.SORTLOG NO cannot be used for RECOVER INDEX processing.SORTLOG NO with OBIDXLAT is not valid with LOG APPLY.
- YESSorts the log records.SORTLOG YES can be used only with sequential copies.If you specify LOGONLY in the job, SORTLOG YES is ignored.
- CONCURRENTSorts the log records after the Db2 VSAM data sets are restored.SORTLOG CONCURRENT with OBIDXLAT is not valid with LOG APPLY.SORTLOG CONCURRENT has been disabled for Db2 12. If CONCURRENT is specified, processing reverts to SORTLOG NO. SORTLOG CONCURRENT processing is still supported in Db2 11.
Example: Sort the Log Records and Rebuild the Indexes Concurrently
The following example sorts the log records before applying them, recovers the tablespace, and rebuilds the indexes concurrently:
RECOVER TABLESPACEdbname1.tsname1TABLESPACEdbname2.tsname2TABLESPACEdbname3.tsname3SORTLOG YES REBUILD INDEX (ALL) TABLESPACEdbname1.tsname1REBUILD INDEX (ALL) TABLESPACEdbname2.tsname2REBUILD INDEX (ALL) TABLESPACEdbname3.tsname3