DB2 image copy concepts

What an image copy records

When COPY (or an inline COPYDDN) succeeds, two things exist: the backup data set, and a row in SYSIBM.SYSCOPY. RECOVER does not guess file names from JCL. It reads SYSCOPY for DSNAME, ICTYPE (full, incremental, QUIESCE, and others), SHRLEVEL, DSNUM, START_RBA, PIT_RBA, TIMESTAMP, and local versus recovery-site backup indicators. If the data set is migrated, deleted, or the SYSCOPY row was removed by MODIFY RECOVERY too aggressively, recovery fails even though “we took backups.”

Image copies are object-level: one table space, one partition, or one COPY YES index space. That is different from a system-level backup, which copies the volumes that hold Db2 data and logs. Most application recovery uses object-level copies plus the log. Disaster restart of an entire subsystem often uses BACKUP SYSTEM / RESTORE SYSTEM as well.

Full image copies

A full image copy (FULL YES, the COPY default) copies all allocated pages of the object or partition. It is the base of every recovery chain. A successful full copy resets COPY-pending for that table space or partition. Take a full copy after CREATE/LOAD of a new object, after REORG or LOAD RESUME when you did not take an inline copy, and whenever COPY-pending is on.

Indexes default to COPY NO. ALTER INDEX … COPY YES (or CREATE with COPY YES) makes the index eligible for COPY and RECOVER instead of only REBUILD INDEX. You still take a full copy of the index; incrementals are not supported. Copy indexes when you copy the table space, and at least when the index is in informational COPY-pending (ICOPY).

1
2
3
4
COPY TABLESPACE HRDB.HRTS
     COPYDDN(SYSCOPY)
     FULL YES
     SHRLEVEL REFERENCE

Incremental image copies

An incremental image copy (FULL NO) copies pages that changed since the last full or incremental copy. Space maps (when TRACKMOD YES) let COPY skip unchanged pages, which is why incrementals are cheaper on large, lightly updated spaces. TRACKMOD NO still produces a smaller sequential file but may scan more like a full copy.

IBM prerequisites for FULL NO:

• A full image copy of the table space already exists
• COPY-pending is not on
• The last copy did not use the CONCURRENT option
• The previous copy was not a FlashCopy (even if sequential copies were made from that FlashCopy)

You can incremental-copy by partition when a full copy of the table space exists, or a full copy of that same DSNUM exists and COPY-pending is off for the space or partition. DSNDB01.DBD01, DSNDB01.SYSDBDXA, DSNDB01.SYSUTILX, and DSNDB06.SYSTSCPY always take a full copy; COPY ignores FULL NO for those catalog/directory objects.

1
2
3
COPY TABLESPACE DSN8D12A.DSN8S12E
     FULL NO
     SHRLEVEL CHANGE

SHRLEVEL NONE, REFERENCE, and CHANGE

SHRLEVEL answers: what may other programs do to this object while the utility runs? COPY itself documents two values. Other utilities add NONE. Beginners mix them up because the same word appears on COPY, REORG, LOAD, and RUNSTATS with different phases behind it.

SHRLEVEL NONE

NONE means exclusive access. Applications cannot read or write. REORG SHRLEVEL NONE unloads and reloads the same data sets; it does not use the online-REORG shadow/SWITCH model. LOAD often runs NONE-style exclusive access. COPY does not have a NONE keyword—if you need a frozen picture with COPY, use REFERENCE (or stop the space). NONE is listed here because inline copies taken during a NONE utility still land in SYSCOPY as full REFERENCE-style copies, and because availability planning for “take a copy” often starts with “can we drain writers?”

SHRLEVEL REFERENCE

REFERENCE drains writers so SELECT can run but UPDATE cannot. For COPY, IBM recommends REFERENCE when you want a clean TOCOPY / TOLASTCOPY recovery point. After COPY-pending, a REFERENCE full copy is the usual way to re-establish recoverability.

SHRLEVEL CHANGE

CHANGE claims the read class so inserts and updates continue. The COPY data set is fuzzy: a page might be captured before or after a later update. Do not treat it as a single instant. IBM recommends recovering CHANGE copies with TORBA / TOLOGPOINT using SYSCOPY. PIT_RBA (a point after the copy) rather than TOCOPY alone. COPY CHANGE of LOG NO objects is not allowed. FLASHCOPY CONSISTENT with CHANGE uses shadow processing to back out uncommitted work from the FlashCopy without an availability outage.

CONCURRENT (DFSMSdss concurrent copy) adds a page-size versus control-interval rule: if the page size does not match the CI, 8 KB / 16 KB / 32 KB table spaces must use REFERENCE, not CHANGE.

Inline copies

An inline copy is a full image copy written during LOAD, REORG TABLESPACE, REORG INDEX, or REBUILD INDEX when you specify COPYDDN and optionally RECOVERYDDN. The advantage: the object is not left COPY-pending even if you specified LOG NO. Availability is better because you skip a separate COPY job after LOAD REPLACE.

Inline copies are produced during the RELOAD (or equivalent) phase. The SYSCOPY record has ICTYPE=F and SHRLEVEL=R. For LOAD REPLACE, STYPE is R if LOG YES and S if LOG NO. The sequential data set is logically a full REFERENCE copy, but data pages may be out of order compared with a standalone COPY. RECOVER understands that layout. UNLOAD FROMCOPY of a FlashCopy inline copy usually needs COPYTOCOPY first to make a sequential file.

1
2
3
4
LOAD DATA REPLACE LOG NO
  COPYDDN(SYSCOPY)
  INTO TABLE HR.EMPLOYEE
  ...

FlashCopy image copies

FlashCopy (FLASHCOPY YES or CONSISTENT on COPY, and similar options on REORG/LOAD/REBUILD) uses DFSMS FlashCopy to copy at the VSAM data set level. Elapsed time drops because you establish a relationship instead of reading every page into a sequential file. Consequences:

• FlashCopy image copies are always full. If you specify FULL NO with FLASHCOPY YES or CONSISTENT, COPY issues an informational message and still creates a full FlashCopy
• Sequential copies requested in the same statement can be created from the FlashCopy
• RECOVER, COPYTOCOPY, DSN1COPY, DSN1COMP, and DSN1PRNT accept FlashCopy image copies
• You generally cannot UNLOAD directly from a FlashCopy image copy—use COPYTOCOPY to produce a sequential copy first
• FLASHCOPY CONSISTENT with SHRLEVEL CHANGE backs out in-flight work from the copy without draining applications

1
2
3
4
5
TEMPLATE FCCOPY DSN HR.FC.&DB..&SN..N&DSNUM..&UQ.
COPY TABLESPACE HRDB.HRTS
     FLASHCOPY YES
     FCCOPYDDN(FCCOPY)
     SHRLEVEL REFERENCE

System-level backups

The BACKUP SYSTEM utility invokes z/OS DFSMShsm to copy the volumes on which Db2 data and log information reside, using SMS copy pools you must define first. Output is a system-level backup (SLB) of a subsystem or data sharing group. Later, RESTORE SYSTEM recovers the subsystem. RECOVER can also use an SLB as a recovery base for objects when the backup includes the needed volumes.

Requirements include SMS-managed data sets. In data sharing, abnormally quiesced failed members cause BACKUP SYSTEM to fail. BACKUP SYSTEM does not reset COPY-pending—you still need an object-level image copy for that. SLBs complement image copies; they do not replace the SYSCOPY chain for table-space recoveries you run every week.

Image copy selection and incremental recovery

Recover to current restores the latest applicable full copy, merges later incrementals, then applies log until current. Point-in-time recovery (TORBA, TOLOGPOINT, TOCOPY, TOQUIESCE) picks the latest copy that is still before the target log point, merges incrementals up to that point, then applies log (or, for some FlashCopy-with-consistency bases, handles uncommitted work in dedicated phases).

Image copy selection is therefore: “which SYSCOPY rows are valid for this object, site (local vs recovery), DSNUM, and recovery point?” REPORT RECOVERY prints that plan before you run RECOVER. If incrementals live on many tapes, RECOVER must allocate all of them at once to merge pages. That is why shops merge incremental copies with MERGECOPY into a new full (NEWCOPY YES) or a single incremental (NEWCOPY NO). After a merge, RECOVER typically needs one full tape plus log instead of a dozen incrementals.

Incremental recovery is not a special RECOVER keyword. It is ordinary RECOVER consuming a full-plus-incremental chain. Keep local and recovery-site chains aligned: IBM documents RC 8 on incremental COPY when local and remote histories diverge. Take a fresh full for both sites after LOAD/REORG without an inline copy, and after COPY-pending.

Kinds of copies at a glance

Explain It Like I'm Five

An image copy is a photograph of a classroom. A full photo shows every desk. An incremental photo shows only desks that changed since the last picture. REFERENCE means “nobody move.” CHANGE means “keep playing; the photo might be blurry.” An inline photo is taken while the janitor (LOAD or REORG) is already rearranging the room, so you do not need a second photographer. FlashCopy is a magic photocopier that duplicates the whole classroom instantly but only as a complete copy, not a “changed desks only” copy. A system-level backup photographs the entire school building, not one classroom. RECOVER later uses the album plus the diary (the log) to rebuild the room.

Exercises

1. List IBM’s prerequisites for COPY FULL NO and explain why a FlashCopy last copy blocks incrementals.
2. Query SYSIBM.SYSCOPY for one table space and identify ICTYPE, SHRLEVEL, DSNAME, and PIT_RBA.
3. Explain when you would recover with TOCOPY versus TORBA/TOLOGPOINT after a SHRLEVEL CHANGE copy.
4. Draft COPY with FLASHCOPY YES and a sequential COPYDDN, then state whether UNLOAD can read the FlashCopy data set directly.
5. Contrast BACKUP SYSTEM with COPY TABLESPACE: what gets copied, what resets COPY-pending, and which restore utility you use.