Starting a table space or index space that has restrictions
Db2 can make an object unavailable for a variety of reasons. Typically, in those cases, the data is unreliable, and the object needs some attention before it can be started.
About this task
An example of such a restriction is when the table space is placed in COPY-pending status. That status makes a table space or partition unavailable until an image copy of the object is taken.
However, in certain circumstances, it might be reasonable to force availability. For example, a table might contain test data whose consistency is not critical.
Procedure
To start an object that has restrictions:
This command releases most restrictions for the named objects. These objects must be explicitly named in a list following the SPACENAM option.
Example
For example:
-START DATABASE (DSN8D13A) SPACENAM (DSN8S13E) ACCESS(FORCE)
Db2 cannot process the START DATABASE ACCESS(FORCE) request if postponed-abort or indoubt units of recovery exist. The RESTP (restart-pending) status and the AREST (advisory restart-pending) status remain in effect until either automatic backout processing completes or you perform one of the following actions:
- Issue the RECOVER POSTPONED command to complete backout activity.
- Issue the RECOVER POSTPONED CANCEL command to cancel all of the postponed-abort units of recovery.
- Conditionally restart or cold start Db2.
- UTRO (utility restrictive state, read-only access allowed)
- UTRW (utility restrictive state, read and write access allowed)
- UTUT (utility restrictive state, utility exclusive control)
To reset these restrictive states, you must start the release of Db2 that originally ran the utility and terminate the utility from that release.