Recovering from different Db2 for z/OS problems

You can troubleshoot and recover from many Db2 problems on your own by using the provided recovery procedures.

Recovering from IRLM failure
You can recover from an IRLM failure, regardless of whether the failure results in a wait, loop, or abend.
Recovering from z/OS or power failure
You can recover from a situation in which z/OS or your processor power fails.
Recovering from disk failure
When a disk hardware failure occurs and an entire unit is lost, you can recover from this situation.
Recovering from application errors
You can recover from a problem in which an application program placed a logically incorrect value in a table.
Recovering from IMS-related failures
When you work in a Db2-IMS environment and problems occur, you can recover from those problems.
Recovering from CICS-related failure
When you work in a Db2-CICS® environment and problems occur, you can recover from those problems.
Recovering from a QMF query failure
Receipt of a -805 SQL code in a Db2 for z/OS environment that includes Db2 Query Management Facility (QMF) might occur after you start QMF or issue a QMF command. If the Db2 subsystem was recently migrated to a new release, you might need to rerun certain QMF installation jobs.
Recovering from subsystem termination
You can recover Db2 after Db2 or an operator-issued cancel causes the subsystem to terminate.
Recovering from temporary resource failure
Db2 sometimes experiences a temporary problem when it accesses log data sets. In this case, you need to recover from the situation so that processing can continue as normal.
Recovering from active log failures
A variety of active log failures might occur, but you can recover from them.
Recovering from archive log failures
You can recover from situations in which archive logging fails.
Recovering from BSDS failures
When the bootstrap data set (BSDS) is damaged, you need to recover that BSDS, regardless of whether you are running Db2 in dual-BSDS or single-BSDS mode.
Recovering from BSDS or log failures during restart
When the bootstrap data set (BSDS) or part of the recovery log for Db2 is damaged or lost and that damage prevents restart, you need to recover from that situation. What you do to recover varies based on the particular circumstances.
Recovering from Db2 database failure
If a Db2 failure occurs because of an allocation or open problem, you can recover from this situation.
Recovering a Db2 subsystem to a prior point in time
You can recover a Db2 subsystem and data sharing group to a prior point in time by using the BACKUP SYSTEM and RESTORE SYSTEM utilities.
Recovering the catalog and directory to a point in time before a CATMAINT or a function level upgrade in a data sharing environment
If you are in a data sharing environment, and you need to recover the catalog and directory to a point in time before CATMAINT was run or a function level upgrade was performed, you need to follow a special procedure.
Recovering the catalog and directory to a point in time before a CATMAINT or a function level upgrade in a non-data sharing environment
If you are in a non-data sharing environment, and you need to recover the catalog and directory to a point in time before CATMAINT was run or a function level upgrade was performed, you need to follow a special procedure.
Recovering from a down-level page set problem
When using a stand-alone utility or a non-Db2 utility, you might inadvertently replace a Db2 page set with an incorrect or outdated copy. This type of copy is called down-level. Using a down-level page set can cause complex problems; therefore, you need to recover from this situation.
Recovering from a problem with invalid LOBs
If a LOB table space is defined with LOG NO and you need to recover that table space, you can recover the LOB data to the point at which you made your last image copy of the table space.
Recovering from table space I/O errors
You can recover a table space after I/O errors have occurred and caused the table space to fail.
Recovering from Db2 catalog or directory I/O errors
When the Db2 catalog or directory fails because of I/O errors, you need to recover from this situation so that processing can return to normal.
Recovering from integrated catalog facility failure
Sometimes VSAM volume data sets might be out of space or destroyed. Also, you might experience problems with other VSAM data sets being out of space or unable to be extended any further.
Recovering from referential constraint violation
When a referential constraint is violated, the table space is available for some actions, but you cannot run certain utilities or use SQL to update the data in the table space until you recover from this situation.
Recovering from distributed data facility failure
You can recover from various problems that occur for the distributed data facility (DDF).
Performing remote-site disaster recovery
When your local system experiences damage or disruption that prevents recovery from that site, you can recover by using a remote site that you have set up for this purpose.
Scenarios for resolving problems with indoubt threads
Indoubt threads can cause a variety of problems, but you can recover from these problems.
Troubleshooting Db2 stored procedure problems
If you encounter problems setting up, calling, or running stored procedures, several troubleshooting techniques and tools are available in Db2 and z/OS.
Identifying Db2 data inconsistency problems
Data inconsistency problems occur for various reasons, including internal Db2 problems, I/O errors, or system problems.

Parent topic: Troubleshooting problems in Db2