DB2 logging parameters: active logs, checkpoints, and archives

Where logging parameters fit

Think of the logging system as a pipeline. An updating thread creates a log record. DB2 places it in an in-memory output buffer, writes it to the current active log, and later offloads a completed active log to an archive data set. Checkpoints place restart landmarks in that stream. The BSDS records active and archive data set names, their RBA or LRSN ranges, and checkpoint information.

This page does not repeat the full architecture of active logs, archive logs, and the BSDS. Instead, it asks the system programmer's question: which installation fields shape that architecture? OUTBUFF and WRTHRSH affect the front of the pipeline. NUMBER, active-log sizing, and TWOACTV determine its online capacity and resilience. Checkpoint parameters limit restart distance. DSNTIPA fields control where completed logs are archived and how long they can support recovery.

DSNTIPL active-log parameters

DSNTIPL is the active-log data set parameters panel used during installation or migration tailoring. Its values help generate definitions and subsystem parameters. Editing a panel member is not itself an online change: the generated ZPARM module, allocation jobs, and BSDS inventory must all agree with the intended configuration.

OUTBUFF: output log buffer size

OUTBUFF specifies, in KB, how much storage DB2 uses for the log output buffer. Applications first place log records in this buffer. DB2 externalizes them to the active log when required by events such as commit and as buffer-writing logic demands. A larger buffer gives a bursty workload more room while log I/O catches up. It can reduce waits caused by having no output buffer available.

Bigger is not automatically free. The log output buffer is backed by permanently fixed real storage, so a very large value consumes memory that cannot serve another purpose. Use DB2 statistics, especially evidence of log-buffer-full waits, to justify a change. IBM raised defaults in recent releases as memory capacities and logging rates grew, but a copied value from another subsystem is not a sizing study. OUTBUFF is not a SET LOG checkpoint option; changing the ZPARM commonly requires subsystem-parameter activation under the supported release procedure or a DB2 recycle.

WRTHRSH: starting log output early

WRTHRSH is the log-write threshold. It helps determine when DB2 starts writing accumulated output rather than waiting for all buffering to be consumed. Read it together with OUTBUFF and storage response time. OUTBUFF answers “how much room is available?” while WRTHRSH helps answer “when should output begin?” The best setting keeps writes moving without creating unnecessary write activity.

If log devices are slow, threshold tuning cannot manufacture bandwidth. Investigate active-log device latency, paths, coupling-facility effects in data sharing, and synchronous commit waits. Parameter tuning should follow evidence that the buffer or write-start behavior is the limiting point.

TWOACTV, NUMBER, and active-log sizes

TWOACTV selects dual active logging. With it enabled, DB2 writes a COPY1 and COPY2 version of each active-log range. The copies should not share the same single point of failure. Dual active logging protects the current records; it is separate from TWOARCH, which controls archive copies, and from dual BSDS, which protects the log inventory.

The NUMBER field and related generated definitions determine how many active data sets exist in each copy's ring. More active logs do not reduce log volume. They provide elapsed time for offload to finish before DB2 needs to reuse a slot. A workload that generates 200 GB per hour needs enough aggregate active capacity to survive realistic archive delays, not merely enough data set names to satisfy a default.

DSNTIPL also drives the size of active log data sets. Small data sets cause frequent switches and archive allocations. Larger ones reduce switch frequency but make each offload larger, consume more disk, and require archive allocations that can hold the entire active range. Keep active data set sizes consistent within the ring, preformat newly allocated logs with the IBM-provided process, and measure peak bytes logged per minute before deciding both NUMBER and size.

Checkpoint frequency parameters

A checkpoint records enough system state to give restart a recent landmark. It does not replace COMMIT, an image copy, or an archive log. Very infrequent checkpoints can make restart scan and process a longer log range. Extremely frequent checkpoints add CPU and I/O overhead. Modern DB2 guidance favors a short, predictable interval, often no more than a few minutes, adjusted for measured subsystem behavior.

With CHKTYPE=SINGLE, CHKFREQ represents one selected trigger: a number of minutes or a number of log records. With CHKTYPE=BOTH, CHKFREQ is not the active rule; CHKLOGR and CHKMINS supply the two limits. The first limit reached starts a checkpoint and resets both counters. BOTH is useful because a time limit prevents a quiet subsystem from going too long without a checkpoint, while a record limit responds to a sudden logging surge.

Administrators often encounter the term LOGLOAD in commands and displays. LOGLOAD is the SET LOG representation of the number of log records between checkpoint starts. CHKTIME is the command's time-oriented partner. Do not assume that the command vocabulary maps one-for-one to every installation-panel field. DISPLAY LOG shows the effective checkpoint behavior that DB2 is currently using.

DISPLAY LOG and SET LOG

Before changing anything, issue DISPLAY LOG. It reports the current logging position and active-log status and provides checkpoint-related information. Compare the effective display with your approved ZPARM source. A command issued during an incident can make the running value differ from what a future restart will load.

1
2
3
4
5
6
7
8
9
10
-DISPLAY LOG
 
/* Request a checkpoint without replacing the current record threshold */
-SET LOG LOGLOAD(0)
 
/* Use both a record and a time threshold */
-SET LOG BOTH,LOGLOAD(500000),CHKTIME(3)
 
/* Return to one time-based checkpoint rule */
-SET LOG SINGLE,CHKTIME(3)

SET LOG is an operational interface, not a replacement for ZPARM governance. It can modify checkpoint mode and thresholds online. A zero LOGLOAD or CHKTIME requests an immediate checkpoint without storing zero as the new interval. SET LOG can also manage selected active-log inventory operations, such as NEWLOG and REMOVELOG on supported releases, but it cannot dynamically resize an existing VSAM log or change every archive naming field.

For an offline or permanent change, retain the installation CLIST input as the source of truth, generate and review the subsystem parameter module, and follow the release-specific activation instructions. Some parameters can be loaded with SET SYSPARM; others take effect only at restart. Changes to actual log data sets can also require allocation, preformatting, BSDS updates, and carefully sequenced commands. Never run an offline BSDS utility against an active subsystem.

DSNTIPA archive-log parameters

The DSNTIPA panel controls the defaults used when DB2 creates archive log data sets. Archiving is offload: DB2 copies a completed active-log range to sequential archive storage so the active slot can eventually be reused. These fields therefore affect both operational continuity and the length of the recoverable history.

Prefixes, units, retention, and cataloging

The ARC prefix becomes part of each generated archive data set name. In a dual-archive configuration, separate prefixes let COPY1 and COPY2 follow different storage-management rules. Names must be unique by subsystem and usable during disaster recovery. A copied production catalog or restored BSDS is much easier to use when the recovery site understands the same naming plan.

UNIT and UNIT2 identify the device types or esoteric unit names for the two archive copies. They may route allocations to disk, tape, or virtual-tape services according to site standards. A syntactically valid unit does not guarantee an available drive. Monitor mount queues and use SET ARCHIVE only for the supported tape-allocation controls; it does not fix a broken SMS policy or an exhausted disk pool.

ARCRETN supplies a retention period for new archive data sets, and theCATALOG choice determines whether DB2 catalogs them. These are data-set management aids, not proof of recoverability. If storage automation scratches a tape while an old image copy still depends on its RBA range, the stated recovery window is false. Likewise, a catalog entry for a volume that cannot be mounted does not make the log usable.

TWOARCH and compression

TWOARCH creates two archive copies. Its value should match a business requirement: COPY2 should protect against a failure that could also destroy or delay COPY1. Putting two names on the same vulnerable storage pool gives less protection than the word “dual” suggests. Verify that both archive inventories are recorded correctly and that recovery procedures can select the surviving copy.

Archive compaction or compression can reduce media consumption and may reduce transferred bytes. DB2's COMPACT-related option and DFSMS compression are not interchangeable in every environment, and support varies by release, media type, and storage class. Compression also consumes processing and can change recovery throughput. Test archive creation, recall, and RECOVER at the disaster-recovery site before enabling it broadly.

MAXARCH, the BSDS, and the recovery window

The BSDS is the map that connects an RBA or LRSN range to an active or archive data set.MAXARCH limits how many archive data set entries DB2 records in that map. If your subsystem produces hundreds of archives each day, a MAXARCH value that holds only a few days of entries cannot support a thirty-day recovery promise, even if older tapes still exist in a vault.

Calculate the inventory horizon from observed archive generations per day, include peak periods, and leave operational margin. Then align MAXARCH with ARCRETN, physical storage retention, image-copy frequency, MODIFY RECOVERY policy, and DR replication. The usable recovery window ends at the earliest missing dependency. Keeping one piece longer does not compensate for deleting another.

When archive offload cannot allocate

Archive allocation can fail because a disk pool is full, the catalog is unavailable, a tape unit cannot be mounted, an SMS rule rejects the allocation, a prefix is wrong, or the requested space cannot be obtained. DB2 reports the problem and can continue using remaining active-log capacity. That grace period is exactly what NUMBER and active-log sizing buy.

The grace period is finite. Completed active logs cannot safely be reused until required offload processing succeeds. If the ring fills, update workloads can wait or stall because DB2 has nowhere safe to place new recovery records. The correct response is to repair allocation and confirm offload progress, not to disable logging. DISPLAY LOG reveals active-log status; DISPLAY ARCHIVE and system messages provide archive detail.

1
2
3
4
5
6
7
8
9
-DISPLAY LOG
-DISPLAY ARCHIVE
 
/* Example operational investigation */
1. Identify the active log currently being written.
2. Identify completed logs waiting for offload.
3. Check allocation, SMS, disk-space, and tape-mount messages.
4. Correct the cause and verify that offload resumes.
5. Confirm reusable active-log capacity has recovered.

A practical tuning workflow

• Measure peak log bytes per minute, active-log switch frequency, offload duration, and archive allocation delay.
• Use DB2 statistics to look for output-buffer shortages before changing OUTBUFF or WRTHRSH.
• Confirm TWOACTV, TWOARCH, and dual BSDS placement protect against independent failure scenarios.
• Set checkpoint limits from restart objectives and observed log volume, then verify effective values with DISPLAY LOG.
• Calculate how many hours of peak logging the active ring can hold if offload is delayed.
• Align MAXARCH, ARCRETN, cataloging, image copies, and physical media retention with the documented recovery window.
• Record whether each change is online, dynamically activated, or restart-required for the exact DB2 release.

Explain It Like I'm Five

Imagine DB2 is drawing important pictures. OUTBUFF is the tray beside the desk where fresh pages wait before going into a notebook. WRTHRSH tells the helper not to wait until the tray is completely jammed before moving pages. Active logs are the notebooks on the desk, and NUMBER says how many notebooks are ready. TWOACTV means writing two matching notebooks in case one gets wet.

When a notebook is full, the helper carries a copy to the archive cupboard. TWOARCH means using two cupboards. The archive prefix is the label on each box, UNIT says which cupboard to use, and retention says how long the box should be kept. The BSDS is the cupboard index. MAXARCH says how many box labels fit in that index. Checkpoints are bookmarks, so after the lights go out DB2 does not reread every picture from the very beginning.

Exercises

1. Run DISPLAY LOG in a test subsystem. Record the current log, checkpoint mode, record threshold, time threshold, and the status of each active-log copy.
2. Given a peak rate of 40 GB per hour, six 20 GB active logs per copy, and a requirement to tolerate two hours of archive outage, decide whether the ring has enough capacity. Explain the safety margin you would require.
3. Compare TWOACTV, TWOARCH, and dual BSDS. For each one, describe the different failure it is intended to survive.
4. Design a checkpoint policy for a workload that is quiet overnight but produces large logging bursts during the day. Explain why SINGLE or BOTH is the better choice.
5. Audit an imaginary thirty-day recovery policy. List the image copies, archive data sets, BSDS MAXARCH capacity, catalog entries, retention rules, and DR tests needed to make the promise credible.