I85PREP
⌘ K
IBM Db2 13 z/OS DBA Professional study materials
IBM Db2 13 z/OS DBA Professional study resources

IBM Db2 13 z/OS DBA Professional: Availability and Recovery: Copies, Logs, and Point-in-Time Recovery

IBM Db2 13 z/OS DBA Professional · Work through your exam, one topic at a time.

All guide sections

Availability and Recovery: Copies, Logs, and Point-in-Time Recovery

What this domain tests

This domain tests recovery planning for Db2 13 for z/OS: image copies, log archives, point-in-time recovery, data sharing recovery, and the utilities that keep recovery objects current. Questions often describe damage and ask for the correct recovery scope and sequence.

Core rules and concepts

  • SYSCOPY records image copies and their RBA/LRSN ranges. Recovery depends on a valid copy plus the archive and active logs needed to roll forward.
  • COPY can run at table space, partition, or data-set level. SHRLEVEL CHANGE keeps the object available but requires log apply and careful coordination with concurrent updates.
  • RECOVER restores a copy and applies log records to a point in time. TORBA and TOLOGPOINT choose the stop point; RESTOREBEFORE handles conditional restart scenarios.
  • BACKUP SYSTEM and RESTORE SYSTEM use z/OS facilities and are not substitutes for image copies. They restore a system-level point and still depend on log consistency.
  • In data sharing, page recovery must account for group buffer pool copies. A recovered page set can have stale pages in the GBP, so recovery and GBP rebuild steps must be coordinated.

Worked example

At 10:15 a batch job deletes from a table space by mistake. The last image copy was at 02:00, and archive logs cover 02:00 to now. Stop the job, identify a log point just before 10:15 using the log map, restore with RECOVER TABLESPACE ... TORBA, then verify data and restart applications. Reasoning: a full recovery to current would replay the delete; the point-in-time stop excludes it. The image copy supplies the base, and logs supply the intervening changes.

Traps that cost marks

Recovering to current after logical damage; assuming COPY SHRLEVEL CHANGE is immediately recoverable without log apply; forgetting that catalog and directory objects need recovery too; and ignoring GBP state in data sharing.

Key points

  • SYSCOPY plus logs is the recovery chain.
  • TORBA stops before logical damage.
  • SHRLEVEL CHANGE copies require log apply.
  • BACKUP SYSTEM is not an image copy replacement.
  • Data sharing recovery includes GBP coordination.