This guide covers the Linux SQL → DB2 agent workflow. Database and db2_tablespace destinations are assessed separately. A TABLE SPACE option or Table Name label does not guarantee granular single-table recovery. Validate online/offline, logs/rollforward, HADR, pureScale/DPF and encryption scope separately for the installed release.
Screenshots were captured from the actual lab interface on 16 October 2026. The interface is in English; explanations follow your selected language. Resource names, dates and settings are examples; use values for your own environment.
Real-screen limit: the Backup List image from the earlier authorized lab inspection is reused unchanged; it shows db3 / DB2 and a historical Last Backup date. This entry does not prove current agent access, image integrity or successful restore. No new DB2 policy/Clients/target screen was captured; no backup, restore, rollforward or activation was executed.
Engine, agent/master releases and instance identity
Database scope, method and access privileges
Full base, log chain and repository access
Isolated destination, collisions and application acceptance
01
1. Verify the DB2 catalog entry and method
Match the DB2 job in Backup List with source host, instance/database, date and method. The db3 example is an earlier real catalog entry; Last Backup does not establish that the image is still readable. Separate database backup from db2_tablespace scope; a Not Yet Backup entry is not a usable point.
Earlier real Backup List image: db3 / DB2, Active and a 29 September 2026 Last Backup entry. Other engines appear in the same list. This is historical catalog evidence only, not a new DB2 backup/restore or current connection acceptance. Enlarge ↗
Expected result
DB2 scope and relevant acceptance evidence are recorded.
02
2. Match the image and log chain
In Action → Restore inspect the correct database/tablespace and Full point. With the DBA, check required image pieces, incremental bases and archive-log access. A date selection alone does not provide point-in-time recovery; validate rollforward method and log range. No image opening or log replay was performed in this inspection.
Expected result
DB2 scope and relevant acceptance evidence are recorded.
03
3. Separate database and tablespace target forms
The inspected DB2 and db2_tablespace paths offer Original Location/Different Location. The database Different Location form includes Database Name, Instance and Target Path. The tablespace alternate-target field is labeled Table Name; validate its actual semantics against the installed backend rather than treating it as single-table restore support. Do not assume a separate Restore Agent or different-host selector.
Expected result
DB2 scope and relevant acceptance evidence are recorded.
04
4. Check isolated target paths and collisions
With the DBA compare target DB2 release/fix pack, instance owner, database alias, storage/container paths and capacity. Do not test against the source database or paths. Required encryption keys/keystores and logs must be accessible. A generic target form does not establish redirected restore, automatic container remapping, HADR or pureScale reconstruction.
Expected result
DB2 scope and relevant acceptance evidence are recorded.
05
5. Decide on RollForward and Database Activation
Compare the database form’s RollForward and Database Activation options with the DBA plan. Do not select them without understanding log range, recovery-pending state and the opening objective. Do not assume the tablespace form provides identical finalization behavior. In Summary verify the source point, destination instance/database/path and these choices; no Restore was submitted in this inspection.
Expected result
DB2 scope and relevant acceptance evidence are recorded.
06
6. Verify engine state and tablespace access
After an approved test compare task results with DB2 diagnostic logs, database/rollforward state and tablespace access. Activation or a success notification does not prove every log was applied correctly. Assess partial-failure state with the DBA before writing to the same target again; this guide does not execute a generic rollforward stop/complete command.
Expected result
DB2 scope and relevant acceptance evidence are recorded.
07
7. Document data and application acceptance
With the data owner, compare test queries, schema, sample rows, consistency and application connections. Record actual recovery time and data loss, releases, backup chain and destination identity. Separate standalone-database acceptance from cluster/HA failover acceptance. No production connection or DNS cutover was performed while preparing this guide.
Expected result
The selection and relevant acceptance evidence are recorded.
COMMON QUESTIONS
Does a successful task mean the application is ready?
Not by itself. Engine integrity, required log chains, data queries and application access need separate validation; HA/topology acceptance is assessed separately.