ONDBSPACEDOWN and its effect on checkpoints
The ONDBSPACEDOWN configuration parameter specifies the
response that the database server makes when an I/O error indicates
that a dbspace is down. By default, the database server identifies
any dbspace that contains no critical data as down and
continues processing. Critical data includes the root dbspace, the
logical log, or the physical log.
To restore access to that database, you must back up all logical logs and then perform a warm restore on the down dbspace.
The database server halts operation whenever a disabling I/O error occurs on a nonmirrored dbspace that contains critical data, regardless of the setting for ONDBSPACEDOWN. In such an event, you must perform a cold restore of the database server to resume normal database operations.
The value of ONDBSPACEDOWN has no affect on temporary dbspaces. For temporary dbspaces, the database server continues processing regardless of the ONDBSPACEDOWN setting. If a temporary dbspace requires fixing, you can drop and recreate it.
2, the database server
continues processing to the next checkpoint and then suspends processing
of all update requests. The database server repeatedly retries the
I/O request that produced the error until the dbspace is repaired
and the request completes or the database server administrator intervenes.
The administrator can use onmode -O to mark the dbspace down and
continue processing while the dbspace remains unavailable or use onmode
-k to halt the database server. 1, the database
server treats all dbspaces as though they were critical. Any nonmirrored
dbspace that becomes disabled halts normal processing and requires
a cold restore. The performance impact of halting and performing a
cold restore when any dbspace goes down can be severe.