To suppress logging, you can specify the NOT LOGGED option
when you create or alter a table space. However, because logs are
generally used in recovery, planning for recovery of table spaces
for which changes are not logged requires some additional planning.
About this task
Although you can plan for recovery, you still need to
take some corrective actions after any system failures to recover
the data and fix any affected table spaces. For example, if a table
space that is not logged was open for update at the time that Db2 terminates, the subsequent restart
places that table space in LPL and marks it with RECOVER-pending status.
You need to take corrective action to clear the RECOVER-pending status.
Procedure
To plan for recovery of table spaces that are not logged:
- Ensure that you can recover lost data by performing one
of the following actions:
- Ensure that you have a data recovery source that does not rely
on a log record to re-create any lost data.
- Limit modifications that are not logged to easily repeatable changes
that can be quickly repeated.
- Avoid placing a table space that is not logged in a RECOVER-pending
status.
The following actions place a table space in
RECOVER-pending status:
- Issuing a ROLLBACK statement or ROLLBACK TO SAVEPOINT statement
after modifying a table in a table space that is not logged.
- Causing duplicate keys or referential integrity violations when
you modify a table space that is not logged.
If the table space is placed in RECOVER-pending status, it is
unavailable until you manually fix it.
- For table spaces that are not logged and have
associated LOB or XML table spaces, take image copies as a recovery
set.
This action ensures that the base table space and
all the associated LOB or XML table spaces are copied at the same
point in time. A subsequent RECOVER TO LASTCOPY operation for the
entire set results in consistent data across the base table space
and all of the associated LOB and XML table spaces.