Use REPOS UPDATE option to update the old objects Repository table instead of reactive method (with an old objects data set) to obtain old object structure definitions.
OLD OBJECTS is deprecated with PTF BQU2282.
The following figure shows the syntax for the OPTION statement.
DASD DATASETS nnn
Determines the number of recalled data sets that Log Master attempts to maintain on DASD at any one time. Use this keyword to minimize DASD requirements that might result when log processing requires large numbers of archived files.
To honor the DASD DATASETS value, Log Master issues requests to migrate any recalled data sets to their original migration status and level. If a job requires more data sets than this value, Log Master issues requests to migrate data sets even if the value of the MIGRATE keyword is NO.
Depending on how quickly your environment processes migrate requests, for short periods of time, the number of recalled data sets on DASD might be greater than the DASD DATASETS value. Log Master can migrate only data sets managed by the IBM DFSMShsm product. If DFSMShsm is not available in your environment, Log Master might not be able to honor the DASD DATASETS limit value.
Enter a number to limit the number of data sets that are maintained on DASD. To avoid imposing a limit, enter 0. The default value is determined by the DASDDSNS installation option (see the DASDDSNS=10 entry in Installation option descriptions).
Determines the format that Log Master uses to display date and time data on all reports. Log Master supports the following date and time formats. The default value is ISO.
When running on DB2 Version 10 and later, Log Master supports precision timestamps up to 12 digits, and inclusion of a time zone in the timestamp (
Log Master does not update the Repository. If you specify NO, you cannot specify the REPOS UPDATE or REPOS DELETE keywords on the LOGSCAN statement.
Limits the amount of memory that Log Master uses to store compression dictionaries during processing.
Adjusting the value can change the performance of log scans that read compressed table spaces. By default, an unlimited amount of memory is available for storing compression dictionaries, and BMC recommends using retaining the default. However, if you change the DICTIONARYSPACE value to limit the memory, the following considerations apply:
For information about estimating overall memory, see Estimating overall memory (REGION).
Directs Log Master to determine whether any log files that it requires have been migrated (marked as archived in the ICF catalog). If so, Log Master issues requests to recall the required data sets before they are needed for log processing. This action avoids delays in log processing by giving the storage management software in your environment time to retrieve the required data sets.
You must set EARLY RECALL to YES to enable any of the other early recall keywords (such as MIGRATE or DASD DATASETS). The SMSTASKS keyword defines limits for the EARLY RECALL keyword. The Log Master early recall feature works with most storage management software. The related data set migration feature can migrate only data sets that are managed by the IBM DFSMShsm product.
Before you enable early recall of archived data sets, evaluate the settings of the SMSTASKS, MIGRATE, and DASDDSNS keywords to be sure that they are appropriate for your environment.
Specifies the execution mode for Log Master.
To complete log records for objects that do not exist in the DB2 catalog, take two actions:
Assigns a relative cost to the act of reading a separate file, mounting a tape, or reading a segmented table space. Log Master uses the FILECOST values only if the IMAGESOURCE keyword is set to ANY.
Log Master uses the cost values as it chooses a source for row completion processing. Use this syntax to adapt Log Master row completion processing to your environment. To enter cost values, express them in terms of the cost of reading one page from the DB2 log.
Determines how and when Log Master obtains DB2 catalog information (DBIDs, OBIDs, or PSIDs) for the DB2 objects that are named in a filter. Log Master reads the DB2 catalog to resolve the names of DB2 objects into numeric identifiers. Log Master can read the catalog either once during the initial analyze phase of processing for all objects, or repeatedly as it encounters each object in the DB2 log.
Consider the following performance implications as you choose a value:
BMC Software recommends retaining the default value unless you experience degraded performance during the Log Master analyze phase. Use the elapsed time values provided by message BMC097024 ANALYZE FINISHED to determine the performance of the analyze phase.
If you select dynamic filtering (DYNAMIC), do not specify the following items. The processing required for these items is not compatible with dynamic filtering.
See also FLTRMTHD=STATIC.
Specifies the relational operator that Log Master uses to connect multiple filters.
Determines the output that Log Master generates when it encounters DB2 log records that reflect a LOAD REPLACE action. When a DB2 Load utility runs with the REPLACE option, the DB2 log contains log records that Log Master can interpret as a 'mass delete' action (similar to a DELETE statement with no WHERE clause or a TRUNCATE statement). This keyword controls whether Log Master includes the mass delete action in the generated output.
For more information about LOAD REPLACE actions, see the GENMDEL=YES entry in Installation option descriptions.
Determines whether Log Master uses a key store to perform heuristic completion. A key store is a Log Master internal memory and file structure. Heuristic completion is a special type of row completion processing that is separate from and different than the more extensive row completion processing that Log Master performs. For more information about row completion, see IMAGESOURCE.
Heuristic completion imposes a small amount of overhead during the initial log scan to decrease the possibility of more overhead after the initial log scan. (After the initial scan, Log Master performs more row completion processing, which can include reading table spaces, reading image copies, or reading more log files). Depending on your environment, disabling heuristic completion can increase or decrease the performance of Log Master. To determine the effects of heuristic completion in your environment, examine your job’s output for a series of messages that start with message BMC97396 and list the key store as FCUSE.
The following conditions influence the results:
BMC recommends that you consult BMC Software Customer Support before changing the default value.
Specifies the source that Log Master uses to perform row completion processing. If you do not enter a value for this keyword, Log Master uses the value of the IMAGESRC installation option. Valid values are as follows:
Log Master performs row completion processing to rebuild a complete image of a table row at a given point in time. Unless a table is defined with the Data Capture Changes (DCC) attribute, the log record of an update action usually contains only part of the table row (enough to include the changed data). Log Master uses the record ID (RID) value in the log record to obtain information about the row from other sources. For more information about row completion processing, see Row completion processing and your jobs .
See also IMAGESRC=ANY.
LOAD NOCOPYPEND (PTF BQU2603 applied)
Specifies how Log Master processes each LOAD RESUME LOG NO event when establishing compression ranges and assigning dictionary sources to each. The default of LOADNCP is NO, if the installation option is not specified or not changed to YES or if the LOAD NOCOPYPEND syntax is not specified. However, if LOAD NOCOPYPEND is specified in the OPTION statement without YES/NO that follows, the default is YES in that case, consistent with all other YES/NO options.
For more information, see LOADNCP=NO.
Directs Log Master to request that any recalled data sets be migrated to their original status. The default value is YES. The DASD DATASETS keyword places limits on the MIGRATE keyword. Log Master issues migration requests at the end of a job, or when a job requires a greater number of data sets than the DASD DATASETS value. If a job requires more data sets than the DASDDSNS value permits, Log Master migrates data sets even when this keyword is set to NO.
Log Master always attempts to migrate the data set back to its original migration level. The Log Master data set migration feature can migrate only data sets that are managed by the IBM DFSMShsm product. The related early recall feature works with most storage management software.
Before you enable migration of recalled data sets, evaluate the settings of the SMSTASKS, ERLYRCL, and DASDDSNS keywords to ensure that they are appropriate for your environment.
Specifies how Log Master determines the log scan end point when it runs in a data sharing environment. Specify YES to obtain the same end point across all members of the data sharing group.
If you do not enter a value for MINLOGPT, Log Master uses the value of the corresponding installation option. For more information (including a diagram), see the MINLOGPT=NO entry in Installation option descriptions.
Specifies the name of the old objects data set that Log Master uses. You can create an old objects data set to hold structure definitions of DB2 objects that are not currently defined in the DB2 catalog (old objects). The old objects data set should be used only when Log Master is operating in overtime mode. For more information about the syntax used within this data set, see Old objects data set syntax.
OLD OBJECTS is deprecated with PTF BQU2282.
PER MEMBER (for DASD DATASETS)
Specifies the scope of the DASD DATASETS value. This keyword applies only in a data sharing environment.
PER MEMBER (for SMSTASKS)
Specifies the scope of the SMSTASKS value. This keyword applies only in a data sharing environment.
|PROCESS COLD START URIDS|
Specifies that Log Master will process transactions that were in process (but were not terminated) when a DB2 subsystem was cold started. In this context, transactions are considered to be the same as URIDs. Use this keyword to obtain information about the unterminated transactions (for example, in a report). Specify a scan range that includes DB2 processing before and after the cold start.
By default, Log Master does not process a transaction until that transaction is either committed or aborted. Because of this behavior, Log Master does not include transactions that are interrupted by a cold start in generated output. Similarly, Log Master can retain unterminated transactions in the Repository, causing ongoing log scans to read more log files than necessary as they search for commit or abort actions.
However, when you include this keyword, Log Master uses conditional restart information contained in the bootstrap data set (BSDS) to complete the following actions:
Log Master can then process transactions, select them, include them in any generated output, and mark them as committed in the Repository.
Specifies that, as Log Master scans the log, it will include any log records that fall within the range of a Point-in-Time (PIT) recovery. By default, Log Master does not select log records within a PIT range, regardless of your WHERE clause or filter. In rare situations, you might need log records from within a PIT range.
A PIT recovery is a partial recovery (performed with a DB2 Recover utility) that restores a set of DB2 objects to their state at a previous point in time. After a PIT recovery is performed on a set of objects, the DB2 log contains a range of log records for those objects that are no longer valid (because the objects were recovered to a point before the log records were created). This range of invalid log records is called a PIT range. Information about PIT ranges is stored in the SYSIBM.SYSCOPY table of the DB2 catalog.
BMC Software does not recommend using log records from within a PIT range. Exercise caution as you select log records within a PIT range or use the information contained in those log records.
If you take actions or apply changes to your database based on the output of a log scan that combines PIT and normal log records, you can corrupt the data in your database.
To process from log records within a PIT range, process the PIT log records in a separate log scan that covers only the PIT range.
QUIESCE AGING n
Overrides the default QUIESCEAGING installation option. For more information, see QUIESCEAGING=-1.
REPOS (PTF BQU2282 applied)
Determines whether Log Master updates the Repository during the current job step.
Specifies the RESOURCE SELECTION option to specify the order in which Log Master uses image copy resources for both completion processing and compression dictionary access for data decompression.
(PTF BQU2282 applied)
Specifies the number of days that Log Master keeps ongoing and history records in the Repository tables for a specified work ID.
RETAIN Time overrides the default RETAINTIME installation option. For more information, see RETAINTIME.
Determines the maximum number of early recall subtasks that Log Master creates. Use this keyword to optimize performance when log processing requires large numbers of migrated files.
Enter a maximum number of subtasks. To allow Log Master to determine the number of subtasks, enter 0 (the default value). When you specify 0, Log Master sets the SMSTASKS value as follows:
|SUBSYSTEM RBA RESET DATE(date) TIME(time)|
Use this keyword to provide Log Master with information to help discern which log records are valid for the objects implicated by the log scans. Specify this keyword when the following conditions exist:
Specify a date and time that closely approximates the timestamp of that cold start.
Overrides the default URIDTHR installation option.
See also the URIDTHR=0 entry in Installation option descriptions.
|USE UTILITY DELETES|
Specifies whether Log Master should process and use the delete records logged by the DSNUTILB utility when invoked by the DB2 LOAD or REPAIR utilities or by the EXEC SQL statement.
These delete records are created when:
Determines whether Log Master uses the SYSIBM.SYSLGRNX table in the DB2 directory to determine the ranges for a log scan. Use this keyword only in a data sharing environment.
Log Master reads the SYSLGRNX table only when a WHERE clause or filter refers to specific DB2 objects (columns, tables, table spaces, or databases). Log Master uses this table to determine whether the DB2 log of a data sharing member contains information about the database structures that are defined in your log scan. With this information, Log Master can avoid reading log files of members that show no activity during the initial log scan (before row completion processing). This action can improve overall performance. If you do not enter a value for USELGRNG, Log Master uses the value of the corresponding installation option.
Specifying YES can improve Log Master performance. However, Log Master can experience degraded performance reading the SYSLGRNX table if that table is not maintained (with a DB2 Modify utility). Use the elapsed time value provided by message BMC097168 to determine the performance of Log Master SYSLGRNX processing. To improve performance in this situation, specify NO.
Determines whether Log Master terminates at the end of processing or waits for all data set migration requests to complete. If you do not specify this keyword, Log Master uses the value of the MIGRWAIT installation option (see the MIGRWAIT=NO entry in Installation option descriptions).
Controls whether Log Master attempts to use IBM System z Integrated Information Processors (zIIPs). Log Master can use enclave service request blocks (SRBs) to enable zIIP processing automatically while running jobs. Using zIIP processing can reduce the overall CPU time for Log Master jobs. To enable and use zIIP processing with Log Master, you must meet the following requirements:
For more information about the XBM component that enables the use of zIIPs, see the .
See also the ZIIP=ENABLED entry in Installation option descriptions.
In overtime mode, Log Master reads all of the log records that are related to selected objects, regardless of whether the objects exist in the DB2 catalog. In normal operation, (called current mode), Log Master reads the DB2 catalog to get information about the structure of selected objects. However, when an object is dropped, DB2 deletes all references to the object from the DB2 catalog. In overtime mode, Log Master must use other sources to obtain structure definitions.
Use overtime mode when the current time is after a drop action or a drop and re-create action, but you need to retrieve log records that were written before the action.
The following considerations apply to overtime mode:
Overtime mode should be used only when you need to retrieve log records for dropped objects. If you do not need to retrieve log records for dropped objects, BMC recommends running Log Master in current mode.
An overtime job typically uses more resources and experiences more processing overhead than a job that runs in current mode.
Log Master refers to dropped DB2 objects (or DB2 objects that have been dropped and re-created) as old objects. Overtime mode enables Log Master to process log records that are related to old objects.
In overtime mode, Log Master uses other sources to obtain structure definitions of old objects. You must perform at least one of the following types of extra processing to update these sources:
Run periodic jobs that update the Log Master Repository with structure definitions for your old objects (proactive method).
Run an extra log scan that updates the Repository immediately before you use overtime mode (reactive method).
- (Deprecated with PTF BQU2282) Perform manual research and data entry to create an old objects data set.
Log Master refers to the version of a DB2 object that exists between a create action and the following drop action as an instance of that object. Depending on the time frame of your log scan, and the times when an object is dropped and re-created, Log Master can encounter log records that are related to multiple instances of the same object.
By default, Log Master does not perform row completion processing when it runs in overtime mode. Optionally, you can specify the ATTEMPT COMPLETION keyword and the IMAGECOPY statement to direct Log Master to perform row completion processing using available image copy data sets.
Overtime mode is not the same as the Log Master automated drop recovery feature. Drop recovery restores dropped objects. Overtime mode enables you to retrieve data from the DB2 log that is associated with old objects, and to generate output that is based on the data. Overtime mode does not restore the old objects.
If you use the proactive method to update the Repository, schedule the update jobs to run before the following processing:
Regular production processing. For example, if you run a set of jobs every week, you should run a job to update the repository before you run the weekly processing jobs.
DB2 Load or Reorg actions that update compression dictionaries, or that might assign table rows to different record ID (RID) values.
If you update the Repository regularly, BMC Software recommends that you also run regular jobs to delete old or unusable data (particularly any compression dictionaries) from the Old Objects Table. Alternately, you can delete (or display) information from this table by using an option on the Main Menu of the Log Master online interface.
If you store compression dictionaries in the repository, and then stop updating the repository, delete any residual compression dictionaries. Using an outdated compression dictionary from the repository can cause Log Master to fail with a S0C7 abend in member LZCOMPRS, which Log Master uses for decompressing data.
(Deprecated with PTF BQU2282) The old object structures and the user-provided resources for completion processing must be accurate and complete in order to process the old object log records correctly and avoid errors.
For system-time temporal tables, the Log Master Repository does not maintain the versioning relationship between the system-maintained table and its associated history table. Therefore, for overtime processing, your filter must include both the base table and the history table.
For more information about overtime mode, see Processing objects over time.