The DB2 RECOVER utility restores a table space to the current state or to an earlier point in time by applying image copies and, when needed, log records. This how-to covers a practical RECOVER TABLESPACE path: prerequisites, choosing current versus point-in-time recovery, verifying the object after the job, and the mistakes that turn a restore into a longer outage.
RECOVER rebuilds the pages of a table space (or partition, page range, or related index when included) from recovery assets. The classic path restores a full image copy, merges any needed incrementals, then applies Db2 log records forward to the recovery target. You can also recover to a specific image copy (TOCOPY), to an RBA or LRSN (TORBA / TOLOGPOINT), or use LOGONLY when the VSAM data sets were restored outside Db2 and only log apply is required.
Phases you will see on DISPLAY UTILITY typically include UTILINIT, RESTORE (and RESTORER/RESTOREW when parallel), then log-related phases such as LOGAPPLY. Point-in-time recoveries that must undo in-flight work can run LOGCSR and LOGUNDO. Understanding the phase names helps you restart correctly after a failure mid-job.
RECOVER is object-scoped: the largest common unit is the table space or index; the smallest can be a single page. Always recover related objects together when referential integrity, LOB/XML companions, or clone relationships require a consistent set. REPORT RECOVERY and QUIESCE points are your friends before you pick a TORBA.
Identify the exact table space and whether you need DSNUM ALL or a partition. Confirm the outage window: RECOVER typically makes the object unavailable for normal SQL while it runs. Coordinate with applications, CICS regions, and batch schedules.
Authority usually includes RECOVERDB or database-level DBADM/DBCTRL. You also need the image-copy data sets cataloged and readable, plus archive/active logs covering the log range you intend to apply. If a required archive is missing, RECOVER stops even when the full copy exists.
Run REPORT RECOVERY TABLESPACE dbname.tsname (or site equivalent) and review SYSIBM.SYSCOPY. Know which full and incremental copies form the chain, and whether a QUIESCE RBA/LRSN exists for a clean point-in-time target. For RI sets, recover the whole set to the same point.
Stop or restrict writers as your runbook requires. Ensure no conflicting utility owns the space. If you are rehearsing, use a sandbox object cloned from production patterns rather than the live customer table space.
The simplest production recovery after media loss is RECOVER TABLESPACE to current: Db2 picks the latest usable full copy, applies incrementals as needed, then applies logs forward. Code the statement with the correct database and table space names. Use LIST when recovering multiple objects that must stay consistent.
Submit via DSNUTILB/DSNUPROC. Monitor DISPLAY UTILITY for phase progress. Do not cancel casually during RESTORE or LOGAPPLY; follow IBM restart guidance for the phase you interrupted.
12345//RECOVTS EXEC DSNUPROC,UID='TRAIN.RECOV1',UTPROC='',SYSTEM=DB2A //SYSIN DD * RECOVER TABLESPACE TRAINDB.TRAINTS1 DSNUM ALL /*
Point-in-time recovery undoes later committed work. Prefer a QUIESCE point so related table spaces share a consistent RBA/LRSN. TORBA (non-data-sharing) or TOLOGPOINT (data sharing / LRSN) names that point. After PIT recovery, indexes and dependent objects may need rebuild or matching recovery; check restrictive states.
TOCOPY names a specific image-copy data set (or TOLASTCOPY / TOLASTFULLCOPY). Use TOCOPY when you intentionally want the object as of that copy. Remember that a SHRLEVEL CHANGE copy alone is not a transaction-consistent application point unless you apply logs to a consistent log point.
123456789//SYSIN DD * /* Example: recover to a known quiesce LRSN/RBA (format per your release) */ RECOVER TABLESPACE TRAINDB.TRAINTS1 TOLOGPOINT X'000000001234567890AB' /* Example: recover exactly to a registered image copy data set */ RECOVER TABLESPACE TRAINDB.TRAINTS1 TOCOPY BACKUP.TRAIN.TS01.D250815.T120000 /*
LOGONLY skips the RESTORE phase. Use it when storage snapshots, Safeguarded Copy, or DSN1COPY already restored the VSAM linear data sets and you only need Db2 to apply logs to a target. Do not combine LOGONLY with TOCOPY in the contradictory way your vendor docs forbid; pick the pattern that matches how the bytes arrived on disk.
ERROR RANGE and page-level recoveries fix localized damage when the rest of the space is sound. PARALLEL can speed multi-object lists. Always read IBM restrictions for LOB, XML, clone, and catalog/directory objects before improvising.
Utility return code 0 and successful completion messages are necessary but not sufficient. DISPLAY DATABASE should show the table space RW (or the intended start status) without RECP, RESTP, or unexpected advisory states—unless your PIT procedure intentionally leaves rebuild-pending on indexes.
Run checksum-style application validation: row counts versus a known good report, critical key queries, and RI child/parent spot checks. Compare to the business time you intended to restore to. If indexes were rebuilt, confirm INDEX UNIQUE and sample lookups.
Update the incident record with the SYSCOPY rows used, the TORBA/TOLOGPOINT value, and the final DISPLAY output. Schedule a fresh full COPY after major recoveries when site policy requires a new recovery base.
12-DISPLAY DATABASE(TRAINDB) SPACENAM(TRAINTS1) LIMIT(*) -DISPLAY UTILITY(*)
The first time you run RECOVER should not be during a real outage. Clone a training table space, take a known FULL YES copy, make a few updates, then recover TOCOPY and separately to current. Compare row counts and key columns to what you expect. That rehearsal teaches SYSPRINT messages better than any slide deck.
Write the runbook while you rehearse: who approves the recovery point, which LIST of objects belongs together, whether indexes are RECOVER or REBUILD, how you notify application owners, and what COPY you take afterward. Include the exact DISPLAY and SQL validation queries so night-shift staff are not inventing checks under pressure.
Point-in-time recovery has business meaning: you may discard legitimate later transactions. Confirm with the business owner that losing those updates is acceptable, or whether a forward-fix / selective reload is required instead of a blunt TORBA. Technical success with the wrong recovery point is still an incident failure.
Data sharing environments use LRSNs; non-data-sharing often speaks in RBAs. Use the forms your subsystem expects and copy hex values carefully from REPORT RECOVERY or QUIESCE output—one transposed digit sends you to the wrong moment in history.
Missing image copy or deleted data set still named in SYSCOPY: RECOVER fails in RESTORE. Restore the copy from tape management or choose an older SYSCOPY entry that still exists, then age history with MODIFY RECOVERY properly going forward.
Log range gap: archive logs scratched too early. Recovery cannot invent missing log. Prevent with retention that matches your recovery SLA.
Inconsistent PIT across an RI set: parent recovered to Tuesday, child to Monday. Always recover the set to one QUIESCE point.
Wrong DSNUM: recovered one partition while the application failure spanned others. Confirm partition mapping before the job.
Indexes left in rebuild-pending after table space PIT recovery: applications fail until REBUILD INDEX completes. Include index steps in the runbook.
Canceling mid-LOGUNDO or mid-RESTORE without following restart rules: can leave restrictive states. Use DISPLAY UTILITY and IBM restart documentation.
Recovering to a SHRLEVEL CHANGE copy with TOCOPY and expecting application-consistent data without further log apply: you may see torn logical states across related rows. Prefer QUIESCE-based PIT or recover to current when consistency matters.
Think of a diary and a stack of photocopies of your notebook. RECOVER finds the right photocopy (image copy), puts those pages back into the notebook, then replays the diary entries that came after the photocopy (the log) until you reach “now” or a page you circled earlier (the recovery point). If someone else already put the photocopied pages on the desk, LOGONLY just reads the diary.
1. What does RECOVER typically do after restoring an image copy?
2. Why prefer QUIESCE points for TORBA/TOLOGPOINT?
3. What is LOGONLY for?
4. Where do you look up available image copies before RECOVER?
5. After PIT recovery, indexes might be: