Unplanned outages happen. High availability on DB2 for z/OS is not “never fail” — it is “come back consistent, fast, and with the rest of the group still serving work.” This page covers Db2 restart, the restart recovery process that uses checkpoints and logs, member restart versus group restart in data sharing, and quiesce as a planned stop.
You start and stop Db2 with the operator commands -START DB2 and -STOP DB2. Before a normal stop, the system takes a shutdown checkpoint. That checkpoint plus the recovery log (inventoried in the BSDS) give Db2 what it needs to restart. After an IPL, START DB2 is issued from a z/OS console or SDSF — DB2I cannot start a subsystem that is not up.
12345-START DB2 -START DB2 ACCESS(MAINT) -START DB2 PARM(DSNZPACC) -STOP DB2 MODE(QUIESCE) -STOP DB2 MODE(FORCE)
IRLM must be started first or START DB2 fails. Automatic restart (ARM / automation) is IBM’s recommendation for failed data-sharing members so humans are not the recovery clock.
If a system failure occurs, a restart of Db2 restores data integrity. A Db2 subsystem or an attached subsystem (CICS, IMS) might fail. In either case Db2 automatically restarts, backs out uncommitted changes, and completes processing of committed changes that had not yet been externalized to disk. That is restart recovery — not the RECOVER utility, and not disaster recovery to another site.
| Phase | What Db2 does |
|---|---|
| Log initialization | Open BSDS and logs; find the last checkpoint RBA/LRSN |
| Current status rebuild (CSR) | Identify in-flight URs, page sets with pending writes, exception states |
| Forward-log recovery | Redo: reapply log from checkpoint to end of log for committed work still in buffers |
| Backward-log recovery | Undo: back out uncommitted units of recovery |
| End restart | Subsystem becomes available (ACCESS RW or MAINT); remaining work such as postponed abort may continue |
Watch the DSNR-prefixed messages. DSNR002I / DSNR006I are expected progress. DSNR004I points at trouble in forward-log recovery; DSNR005I in backward-log recovery; DSNJ001I during log initialization or CSR. If a portion of the log is unreadable, you may need conditional restart (DSNJU003 CRESTART) — a last-resort procedure that can skip work and must be planned with IBM documentation, not improvised.
Dual BSDS and dual logs let you restore dual operation while Db2 continues to run if one copy is lost. Restart recovery assumes those logs exist. If you lose too much log, you are in system recovery (image copies, RESTORE SYSTEM), not a simple START DB2.
From the last checkpoint, forward recovery redoes logged changes so disk matches committed work that was still sitting in virtual buffers. Backward recovery undoes in-flight units of recovery (URs) so a half-updated row is not visible. Indoubt URs (two-phase commit with CICS, IMS, RRS, or remote Db2) are handled with heuristic or coordinator-driven resolution after restart — they are not silently committed.
Long URs can make backward recovery slow. Some shops allow postponed abort: Db2 comes up and finishes backing out huge URs in the background so the subsystem is available sooner. That is a ZPARM / restart option trade-off, not a way to skip recovery.
In a data sharing group you can stop and start an individual member while the other members continue to run. Startup for each member is similar to a non-data-sharing subsystem: BSDS, logs, checkpoint, redo, undo. The difference is retained locks and the coupling facility:
IBM recommends an automated procedure to restart failed members. Leaving a member down holds retained locks and can look like “the database is hung” when it is really one dead member’s locks.
123-DIS GROUP -START DB2 -START DB2 LIGHT(YES)
DISPLAY GROUP shows which members are ACTIVE, FAILED, or QUIESCED. A FAILED member needs restart. LIGHT(YES) is for “get the retained locks released on another LPAR,” not for serving the day’s CICS workload on that member.
Group restart is the rare event that critical resources in a coupling facility are lost and cannot be rebuilt. The SCA (shared communications area) and the lock structure (LOCK1) are required for the group to function. If they disappear and z/OS cannot rebuild them on an alternate CF, all members terminate abnormally. Group restart rebuilds the lost information from individual member logs.
Unlike data recovery, this information can be applied in any order — there is no need to merge log records in LRSN sequence the way RECOVER does — so Db2 can run many restart phases for individual members in parallel. Elapsed time is dominated by the member with the longest CSR, and if the lock structure was lost, the member with the longest forward-log recovery.
If you do not START DB2 for every member, the started members perform group restart on behalf of the non-starting members by reading those members’ logs (peer CSR / peer forward recovery). You should still restart all non-quiesced members together: retained locks are held for members that stay down, which hurts data availability.
The real HA design is to avoid group restart: failure-isolated CFs, structure rebuild onto an alternate CF, and duplexing. Group restart is the safety net when those designs were not in place or both CFs were lost.
Beginners meet three different “quiesce” ideas. This page cares about the first two:
| Option | Meaning |
|---|---|
| MODE(QUIESCE) | Wait for threads; shutdown checkpoint; clean stop |
| MODE(FORCE) | Roll back inflight work more aggressively; faster stop, more restart work |
| CASTOUT(YES|NO) | Whether to cast out GBP-dependent pages as part of stop (data sharing) |
MODE(QUIESCE) is the planned stop: let threads finish, take a shutdown checkpoint, leave a clean restart. In data sharing, IBM also uses quiesce for a member you stop and leave dormant — for example extra capacity you only need in December. That member still appears in DISPLAY GROUP with status QUIESCED until you start it again. A quiesced member can remain dormant indefinitely. Permanently deleting a member from the group is a separate procedure.
Do not confuse that with the QUIESCE utility, which writes a consistency point (RBA/LRSN) into SYSIBM.SYSCOPY for listed table spaces so RECOVER can use a timestamp. And do not confuse it with -STOP DATABASE or restricted ACCESS, which are object-level, not member-level.
BACKUP SYSTEM requires that no failed or abnormally quiesced members exist in the group, or the backup request fails. Planned QUIESCED members are the dormant kind; a crashed member left FAILED is what blocks a system-level backup.
Db2 keeps a diary (the log) and occasionally writes “I got this far” in the diary (a checkpoint). If the lights go out, restart reads the last “I got this far,” finishes homework that was already marked complete (redo), and erases homework that was only half done (undo). In a classroom with several Db2 teachers (members), one teacher can go home while the others keep teaching — that is member restart. If the shared whiteboard in the hallway (SCA or lock structure) is destroyed and cannot be replaced, every teacher has to stop and rebuild the whiteboard from their diaries — that is group restart. Quiesce is sending a teacher on planned leave so they are not in the building, but their name is still on the staff list.
1. What does restart recovery do after an abnormal termination?
2. When is group restart required?
3. What is a quiesced data sharing member?
4. Which command starts the subsystem after an IPL or after STOP DB2?
5. What is the difference between member restart and group restart?