You may see this warning after restoring a DB2 database, particularly when refreshing a development environment from a larger production system:
SQL2563W The restore process completed successfully. However, one or more
table spaces from the backup image were not restored.The restore utility reached its end, but the database is not necessarily ready to use. One or more table spaces can remain unavailable or in restore-pending state, so identify the affected spaces before starting Maximo.
Running out of storage is one possible cause, but SQL2563W is not a disk-space diagnosis by itself. DB2 can also return it when:
- A table-space container cannot be accessed.
- A redirected container is too small for the data in the backup.
- A storage-group path is invalid or unavailable on the target server.
- The restore command intentionally selected only part of the backup's table spaces.
- A temporary table space cannot be recreated on the target storage type.
Find the affected table spaces
Start with the restore output and the DB2 diagnostic log. The diagnostic entry contains the underlying storage or container error that explains why the table space was skipped.
If the database accepts a connection, inspect every table space in detail:
db2 connect to TARGETDB
db2 list tablespaces show detailYou can also inspect table-space state through db2pd:
db2pd -db TARGETDB -tablespacesRecord the table-space name, ID, state, storage group and container paths. Do not treat the database as a successful refresh until every required permanent table space is available and its data has been restored.
Check the target storage
For each affected container or storage-group path, check:
- The filesystem or volume exists and is mounted.
- The DB2 instance owner can access it.
- It has enough free space for the restored data and subsequent growth.
- The path matches the target server rather than a source-only production path.
- Any file or device container has the required size and type.
If capacity is the confirmed cause, expand the target storage before starting the restore again. Matching the source allocation can be a useful starting point for a like-for-like refresh, but base the final size on the used data, restore workspace, logs and expected target growth rather than copying a production disk size blindly.
Rerun or redirect the restore
Once the failed restore has been investigated, return the target to the clean state required by your recovery plan and rerun the complete restore. Do not build a development environment on top of a partially restored database.
When the source paths do not exist on the target, use a redirected restore. DB2 can generate a script from the backup image:
db2 restore db SOURCE_DB \
from /backups \
taken at BACKUP_TIMESTAMP \
into TARGETDB \
redirect generate script restore_targetdb.clpReview and edit the generated SET STOGROUP PATHS or SET TABLESPACE CONTAINERS statements for the target server, then run the script:
db2 -tvf restore_targetdb.clpKeep the generated backup selection, storage layout and recovery options consistent with the approved restore procedure. Automatic-storage table spaces and non-automatic DMS or SMS containers have different redirection rules, so do not substitute one form of SET statement for another.
Validate the restored database
After the rerun:
- Confirm that the restore command no longer returns
SQL2563Wunexpectedly. - Review
db2diag.logfor container, storage-group and table-space errors. - Run
LIST TABLESPACES SHOW DETAILagain and confirm every required table space is in a usable state. - Complete any required rollforward recovery and verify that the database leaves rollforward-pending state.
- Connect as the Maximo schema owner and query representative application tables.
- Start Maximo only after the database and table-space checks pass.
If the restore deliberately excluded table spaces, document which ones and why. The warning can be expected in a controlled partial restore, but it must not be dismissed without matching it to the planned scope.