COPY a DB2 tablespace

What COPY a tablespace means

COPY writes a sequential (or FlashCopy-based) backup of the pages that make up a Db2 table space. A full image copy (FULL YES) copies every used page and is the recovery base shops rely on. An incremental copy (FULL NO) copies only pages that changed since the previous image copy. Indexes require COPY YES on the index definition before you can copy them; this tutorial focuses on TABLESPACE.

Every successful registered copy inserts one or more rows into SYSIBM.SYSCOPY. RECOVER later reads those rows to find the correct data set name, ICTYPE, DSNUM, and starting RBA/LRSN. If the copy is not registered, or the data set is deleted from the catalog without MODIFY RECOVERY cleanup, recovery planning breaks even when the tape still exists.

COPY is also how you clear COPY-pending (COPY) status after LOAD LOG NO, REORG LOG NO without an inline copy, or other operations that leave the object unrecoverable until a full image copy exists. Clearing that pending state is often as important as the backup bytes themselves.

• FULL YES: full image copy; resets COPY-pending for the copied object or partition.
• FULL NO: incremental; not valid for indexes; needs a prior full copy and no COPY-pending.
• COPYDDN: local primary (and optional backup) image-copy DD or TEMPLATE.
• RECOVERYDDN: optional recovery-site primary/backup pair for disaster-recovery copies.
• SHRLEVEL REFERENCE: read-only concurrent access (default-style consistent copy).
• SHRLEVEL CHANGE: allows updates during the copy; recovery to that copy alone is not a transaction-consistent point without log apply.

Prerequisites

Confirm the exact database and table space names (dbname.tsname). Use DISPLAY DATABASE or catalog queries so you do not copy the wrong object in a shared subsystem. Note partition numbers if you intend DSNUM rather than DSNUM ALL.

Authority typically includes IMAGECOPY, or higher database privileges such as DBADM/DBCTRL depending on your shop standards. The utility job must be able to allocate the output data sets and have RACF access to the Db2 subsystem and the STOGROUP volumes.

Decide SHRLEVEL before you schedule the window. REFERENCE drains writers so the image is a clean recovery point; CHANGE keeps the application up but the copy reflects pages as of different moments unless you recover with log apply to a consistent RBA/LRSN. For a first-time learning job, use SHRLEVEL REFERENCE on a non-production table space.

Prepare TEMPLATE or DD statements for COPYDDN. Size the data set for the table space (compressed pages stay compressed; COPY does not expand them). If your shop uses LISTDEF/TEMPLATE standards, follow them so RECOVER and REPORT RECOVERY see predictable data set names.

• Object is started and available unless your procedure requires STOP or RO.
• No conflicting utility already claiming the space (DISPLAY UTILITY).
• For FULL NO: a prior full copy exists, COPY-pending is off, and the last copy was not CONCURRENT-only in a way that blocks incrementals.
• Output HLQ, unit, and retention match site backup standards.

Steps

Build a DSNUTILB (or DSNUPROC) job with a SYSIN control statement that names the table space, FULL YES, SHRLEVEL, and COPYDDN. Start with one object so the job output is easy to read. Use TEMPLATE for portable naming, or a traditional DD if your shop still codes explicit DSN= lines.

Submit the job and watch return codes. Condition code 0 is the usual success. Some CHANGELIMIT scenarios return other codes when no copy was needed; for a forced full copy you should see a registered copy and CC 0. If the utility abends or ends with CC 8, do not assume SYSIBM.SYSCOPY was updated.

Optional but useful: after the first successful full copy, schedule incremental jobs with FULL NO or CHANGELIMIT so nightly backups stay short when few pages change. IBM recommends basing full-versus-incremental decisions on the percentage of changed pages, not the number of updated rows. CHANGELIMIT(REPORTONLY) can report the percentage without writing a copy.

1
2
3
4
5
6
7
8
9
10
11
//COPYTS  EXEC DSNUPROC,UID='TRAIN.COPY1',UTPROC='',SYSTEM=DB2A
//COPYDDN  DD  DSN=BACKUP.TRAIN.TS01.D&LYYMMDD..T&LHHMMSS,
//             DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=(CYL,(50,20),RLSE)
//*
//SYSIN    DD  *
  COPY TABLESPACE TRAINDB.TRAINTS1
       COPYDDN(COPYDDN)
       FULL YES
       SHRLEVEL REFERENCE
/*

Template and list pattern

Production shops rarely hard-code one DD per object. TEMPLATE builds data set names from variables such as &DB, &TS, &DATE, and &TIME. LISTDEF groups many table spaces so one COPY LIST statement processes them, optionally with PARALLEL for throughput. When you COPY a list with SHRLEVEL REFERENCE, Db2 can establish a shared recovery point across that list.

Keep local and recovery-site copies distinct with COPYDDN and RECOVERYDDN when your disaster-recovery plan requires offsite image copies. Document which pair RECOVER should prefer at the recovery site.

1
2
3
4
5
6
//SYSIN DD *
  TEMPLATE ICPRIME DSN &HLQ..&DB..&TS..D&DATE..T&TIME
    UNIT SYSDA SPACE(CYL,50,20) DISP(NEW,CATLG,DELETE)
  LISTDEF APPTS INCLUDE TABLESPACE TRAINDB.TRAINTS*
  COPY LIST APPTS COPYDDN(ICPRIME) FULL YES SHRLEVEL REFERENCE
/*

Verify results

Check the utility SYSPRINT for messages that name the table space, the image-copy data set, and successful completion. Then query SYSIBM.SYSCOPY for the new ICTYPE row (usually F for full, I for incremental) with the expected DBNAME, TSNAME, DSNUM, and TIMESTAMP.

Confirm COPY-pending is gone if that was a goal: -DISPLAY DATABASE(TRAINDB) SPACENAM(TRAINTS1) shows status without COPY. Catalog the output data set and verify it is cataloged and retainable under your tape or disk management system.

For a stronger test in a sandbox, run REPORT RECOVERY on the table space and confirm the new copy appears in the recovery chain. A drill that actually RECOVER TOCOPY on a clone object is the gold standard before you trust the same JCL in production.

1
2
3
4
5
6
7
SELECT DBNAME, TSNAME, DSNUM, ICTYPE, ICDATE, ICTIME,
       DSNAME, START_RBA, FILESEQNO
  FROM SYSIBM.SYSCOPY
 WHERE DBNAME = 'TRAINDB'
   AND TSNAME = 'TRAINTS1'
 ORDER BY TIMESTAMP DESC
 FETCH FIRST 5 ROWS ONLY;

Operational tips for beginners

Treat COPY as part of a recovery design, not a lonely nightly job. Decide how many full copies you keep, how long archives are retained, and whether RECOVERYDDN offsite copies are required for disaster recovery. A perfect local copy that expires before the logs do—or the reverse—still fails when you need RECOVER.

After REORG, LOAD REPLACE, or other major maintenance, take a full image copy even if an incremental schedule exists. Incremental chains that start from a pre-reorg base can confuse operators and lengthen restore time. Many shops force FULL YES on the first backup after reorg as a standard.

When learning, keep a lab checklist: DISPLAY before and after, SYSCOPY query, REPORT RECOVERY snippet, and the output data set name pasted into your notes. That habit transfers directly to production incident work where auditors ask how you know the backup is usable.

FlashCopy and DFSMSdss concurrent copy options exist for large shops that need speed. They have extra restrictions (page size versus CI size, SHRLEVEL rules). Master classic sequential FULL YES first; then graduate to concurrent techniques with your storage team.

Common errors

COPY-pending already on, or missing full copy: FULL NO fails until you take FULL YES. After LOAD LOG NO, take a full copy before you rely on incrementals.

Authority or allocation failures: IMAGECOPY privilege missing, RACF denial on the output HLQ, or insufficient space on the UNIT. Fix the DD/TEMPLATE and resubmit; a failed job usually leaves no new SYSCOPY row.

Wrong SHRLEVEL for the window: REFERENCE with long-running writers causes contention; CHANGE during a recovery-critical nightly window produces a copy that is harder to reason about for TOCOPY-only restores. Match SHRLEVEL to the recovery procedure you actually rehearse.

Incremental after CONCURRENT or other restricted previous copy: IBM documents cases where FULL NO is not allowed. Take a new full copy and resume the incremental schedule.

Deleting image-copy data sets without MODIFY RECOVERY: SYSCOPY still points at ghost data sets and RECOVER fails later. Always age recovery history with MODIFY RECOVERY according to site policy, not with ad-hoc DELETE alone.

Copying the wrong DSNUM or the wrong table space in a LISTDEF wildcard is a silent operational risk: the job succeeds, SYSCOPY looks healthy, and you still cannot recover the object you thought you protected. Always spot-check object names in SYSPRINT against the change ticket.

• Utility timeout or drain failure: resolve blockers, increase timeout standards, or choose a quieter window.
• DSNUM mismatch: copying one partition while applications expect DSNUM ALL recovery points.
• Index copies forgotten: table space recovered but COPY YES indexes not in the recovery set.
• TEMPLATE syntax errors that allocate tiny SPACE and cause B37 abends mid-copy.