Db2 Directory Guide: SPT01, SCT02, DBD01, SYSLGRNX, and SYSUTILX



Db2 manages the directory internally.

A Db2 package can be present in the catalog and still fail at execution time if the internal execution structures are damaged, unavailable, or out of sync. When recovery, bind, or utility processing is involved, Db2 uses directory objects that normal application SQL does not query.

The Db2 directory stores internal control information used by Db2 for operation, package and plan execution, database descriptors, log range tracking, and utility restart. Unlike the catalog, the directory is not a normal SQL reporting source. Db2 and supported utilities maintain it.

What the Db2 directory does

The directory supports Db2 execution and recovery work that must be fast and controlled. It stores internal forms of packages and plans, database descriptors, log ranges used for recovery, and utility status needed for restart. Developers usually learn about it when a bind, run, utility, or recovery problem points below normal catalog metadata.

Directory versus catalog

Area	Purpose	Normal access
Db2 catalog	Stores queryable metadata about objects, privileges, packages, plans, routines, and statistics.	Read with SQL when authorized.
Db2 directory	Stores internal control data used by Db2 for execution, recovery, utility restart, and package or plan processing.	Managed by Db2 and supported utilities, not normal application SQL.

Important Db2 directory objects

Directory object	What it supports	Why it matters
SPT01	Skeleton package table, often called SKPT.	Contains internal package information and access-path data created by BIND PACKAGE and removed by FREE PACKAGE.
SCT02	Skeleton cursor table, often called SKCT.	Contains internal plan information and access-path data created by BIND PLAN and removed by FREE PLAN.
DBD01	Database descriptors.	Stores internal database descriptor information for table spaces, indexes, tables, constraints, and related structures.
SYSLGRNX	Log range tracking.	Helps Db2 locate log ranges needed for recovery of updated table spaces or partitions.
SYSUTILX	Utility execution and restart state.	Stores utility status so Db2 can restart, recover, or terminate utility work correctly.

How directory objects show up in support work

Package or plan execution

When a static SQL program runs, Db2 uses package or plan structures created at bind time. Catalog rows help you identify the package, collection, and validity, but execution also depends on internal structures in the directory. If a bind or free operation fails, support teams often check both catalog state and Db2 messages tied to directory processing.

Recovery and log ranges

SYSLGRNX helps Db2 find the log ranges needed for recovery. If an object has been updated, Db2 can use recorded ranges instead of searching all log data blindly. This matters during RECOVER, restart, and problem diagnosis after an outage.

Utility restart

SYSUTILX is involved when utilities such as REORG, LOAD, COPY, or RECOVER need restart or cleanup handling. If a utility stops, do not delete anything by hand. Use supported commands such as -DISPLAY UTILITY, restart procedures, or -TERM UTILITY only when site rules allow it.

-DISPLAY UTILITY(*)
-TERM UTILITY(utility-id)

Safe handling rules

• Do not update or delete Db2 directory data manually.
• Use supported Db2 commands, bind actions, utilities, and recovery procedures.
• Check the catalog first when the question is about object names, package names, privileges, or statistics.
• Check Db2 messages, utility output, and recovery documentation when the problem points to directory-managed state.
• Escalate directory damage, utility restart confusion, or recovery inconsistencies to the DBA or systems programmer team.

Common mistakes

Treating the directory like catalog tables

The catalog is meant to be queried for metadata. The directory is internal. Treating both as ordinary application data is a support risk.

Terminating utilities without restart context

A utility entry can represent recoverable work. Capture the utility ID, phase, object name, and messages before taking action.

Looking only at package catalog rows

Package catalog rows help identify the package, but a runtime issue may also involve bind output, plan references, load libraries, directory-managed structures, or subsystem messages.

Related Db2 topics

Use this guide with Db2 Catalog, Db2 Packages, Db2 Utilities, Db2 Commands Quick Reference, and Db2 Binding and Rebinding.

FAQ

What is the Db2 directory?

The Db2 directory stores internal control information used by Db2 for package and plan execution, database descriptors, log range tracking, utility restart, and recovery processing.

Can I query the Db2 directory with SQL?

No for normal application or support work. The catalog is the SQL-queryable metadata source. The directory is maintained by Db2 and supported utilities.

What is SYSUTILX used for?

SYSUTILX stores Db2 utility execution and restart information. It helps Db2 restart or clean up utility work after interruption.

Db2 Utilities Guide: COPY, RUNSTATS, REORG, LOAD, UNLOAD, and RECOVER



Use the right utility for the table space state.

A Db2 table space can be perfectly designed and still cause trouble if utilities are skipped. A missing image copy can block recovery, old statistics can lead to bad access paths, and a badly timed REORG can collide with batch work that needs the same object.

Db2 utilities are the operational tools used to load data, collect statistics, reorganize objects, create recovery copies, check consistency, and recover damaged or lost data. On z/OS, these jobs are usually controlled through JCL and utility control statements.

Common Db2 utilities and when to use them

Utility	Main purpose	Typical trigger
COPY	Create an image copy for recovery	Before risky change, after load, or on a backup schedule
RUNSTATS	Update catalog statistics for the optimizer	After large data change, new index, load, or REORG
REORG	Reorganize data or indexes and reclaim space	Poor clustering, high disorganization, or space issues
LOAD	Load high-volume input data into a table	Initial load, refresh, conversion, or warehouse feed
UNLOAD	Extract table data into a sequential data set	Archive, migration, test data, or reload process
RECOVER	Restore an object using image copies and logs	Object damage, application error, or point-in-time recovery plan
CHECK DATA	Check referential and table check constraints	After load, repair, or data movement where integrity needs proof
REBUILD INDEX	Rebuild index structures	Damaged index, recovery action, or index rebuild requirement

COPY is for recovery images

The Db2 COPY utility creates image copies of table spaces or index spaces. It is not the same thing as copying rows from one table to another with SQL. A recovery plan depends on these image copies and the logs that follow them.

//COPYTS  EXEC DSNUPROC,SYSTEM=DSN1,UID='MF.COPY'
//SYSIN   DD *
  COPY TABLESPACE APPDB.TSORD
       FULL YES
       SHRLEVEL CHANGE
/*

Schedule image copies around business risk. For example, take a copy after a successful high-volume load so recovery does not have to replay a large amount of log activity from an older copy.

RUNSTATS supports access path choices

RUNSTATS updates catalog statistics that the Db2 optimizer uses for access path selection. A COBOL program with static SQL normally needs bind or rebind activity before changed statistics can affect the package access path.

//RSTAT   EXEC DSNUPROC,SYSTEM=DSN1,UID='MF.RUNSTATS'
//SYSIN   DD *
  RUNSTATS TABLESPACE APPDB.TSORD
       TABLE(ALL)
       INDEX(ALL)
       SHRLEVEL CHANGE
/*

Run it after major data shifts, new indexes, table reorganizations, and bulk loads. Do not treat it as decoration at the end of a job stream; stale statistics can send the optimizer toward a costly path.

REORG cleans up physical layout

REORG can restore clustering order, reclaim space, and rebuild object layout. It is often paired with RUNSTATS and sometimes followed by package rebind when access paths should be reviewed.

//REORG   EXEC DSNUPROC,SYSTEM=DSN1,UID='MF.REORG'
//SYSIN   DD *
  REORG TABLESPACE APPDB.TSORD
       SHRLEVEL CHANGE
/*

Plan REORG around availability and logging impact. A small reference table and a multi-billion-row transaction table do not have the same utility window.

LOAD and UNLOAD move data at scale

LOAD is used when a large input data set has to be inserted into Db2 faster than ordinary row-by-row application processing. UNLOAD extracts data to a sequential data set for archive, migration, testing, or reload processing.

//LOADTS  EXEC DSNUPROC,SYSTEM=DSN1,UID='MF.LOAD'
//SYSREC  DD DSN=APP.INPUT.ORDERS,DISP=SHR
//SYSIN   DD *
  LOAD DATA INDDN SYSREC
       INTO TABLE APP.ORDERS
/*

After a LOAD, check whether the object needs COPY, RUNSTATS, constraint checks, and package rebind. The right answer depends on the options used and local recovery rules.

RECOVER is the restore path

RECOVER uses image copies and logs to restore Db2 objects. It should be rehearsed before the outage, not first learned during one. Keep utility JCL, copy availability, log retention, and recovery point rules visible in the runbook.

//RECOV   EXEC DSNUPROC,SYSTEM=DSN1,UID='MF.RECOVER'
//SYSIN   DD *
  RECOVER TABLESPACE APPDB.TSORD
/*

For point-in-time work, coordinate application owners, dependent objects, RI relationships, and downstream files. Recovering one object can be technically correct and still break a business process if related data is out of sync.

Utility checklist before production

• Confirm object name, database, table space, and subsystem before submitting utility JCL.
• Check whether the utility needs outage time or can run with SHRLEVEL CHANGE.
• Review image copy requirements before and after high-risk utilities.
• Run or schedule RUNSTATS when data distribution or indexes changed.
• Check whether static SQL packages need rebind after statistics or index changes.
• Keep utility output with the change record so failures and warnings are not lost.

Related DB2 topics

Utilities connect directly to Db2 Table Spaces, Db2 Indexing, Db2 Optimizer, Db2 Binding and Rebinding, and Db2 Commands Quick Reference.

FAQ

Is Db2 COPY used to copy rows between tables?

No. In the Db2 utility context, COPY creates image copies used for recovery. Row movement between tables is handled by SQL, LOAD/UNLOAD processes, or application logic.

Should RUNSTATS be run after every LOAD?

Often yes, especially when row counts or data distribution changed. The exact schedule depends on local standards, LOAD options, and whether related static packages will be rebound.

Does REORG always improve SQL performance?

No. REORG can help when physical layout, clustering, or space use is hurting access paths, but the value depends on the object and workload. Review utility reports and EXPLAIN evidence.

For utility work, the safest habit is simple: know the object state before the job, read the utility output after the job, and record what changed.