Flashes (Alerts)
Abstract
When multiple repair operations are run in parallel to different container storage pools, data extents can be assigned to the wrong container storage pool.
Content
WHO IS AFFECTED:
IBM Spectrum Protect servers that have only a single container storage pool are not affected. The problem affects only environments that use multiple container storage pools.
PROBLEM SUMMARY:
When multiple repair operations are run in parallel to different container storage pools, the IBM Spectrum Protect server can incorrectly update an extent's pool ID in the server database. A repair operation is usually associated with the REPAIR STGPOOL command; however, a repair operation could occur if an extent is damaged and the same extent is provided during data ingestion from a client operation or the target of a replication operation. The ANR1748I message indicates that extents have been processed by a repair operation, for example:
ANR1758I Repaired XX damaged extents in directory container pools.
A repair operation can create a situation in which the extent's pool ID does not match the pool ID of the extent's container. As a result of this inconsistency, the MOVE CONTAINER command marks the extent as damaged and the MOVE operation fails. The server's container defragmentation processing uses the move container functionality and can also generate the following messages:
ANR0205W MOVE CONTAINER skipped data extent ID XXXXXXXX because it is marked damaged.
ANR0985I Process XX for Move Container running in the BACKGROUND completed with
completion state FAILURE.
However, any subsequent AUDIT command on the container does not find the inconsistent extent marked as damaged and the extent is left unresolved.
Similarly, this situation can cause a DELETE STGPOOLDIRECTORY command to fail:
ANR3646E DELETE STGPOOLDIRECTORY: Storage pool directory XXXXXXXX has an access
mode of DESTROYED and has active data.
Important: Data can still be successfully restored from any object that uses an inconsistent extent as described.
RECOMMENDATION:
If your system environment includes an IBM Spectrum Protect server with multiple container storage pools, avoid using the REPAIR STGPOOL command until the fix for IT17718 is applied. In this way, you can minimize the risk that is associated with inconsistent extents in the server database.
PROBLEM RESOLUTION:
This problem will be resolved in IBM Spectrum Protect server versions 7.1.7.100, 7.1.8.000, and 8.1.1.000, with APAR IT17718. This is subject to change at the sole discretion of IBM. The APAR fix is designed to prevent the problem, but the fix will not resolve existing extent inconsistencies.
To determine whether inconsistent extents exist in your server environment, issue the following DB2 select statement:
- db2 "select sdcl.poolid as sdcl_poolid, sdcn.poolid as sdcn_poolid, sdcl.cntrid as cntrid, sdcl.refcount as refcount, sdcl.flags as flags, count as count from sd_chunk_locations sdcl inner join sd_containers sdcn on (sdcn.cntrid=sdcl.cntrid) where sdcl.poolid!=sdcn.poolid group by sdcl.poolid, sdcn.poolid, sdcn.cntrid, sdcl.cntrid, sdcl.refcount, sdcl.flags for read only with ur"
If the select output shows no results, you are not affected by this situation. If the select output shows extent inconsistencies, contact IBM Software Support to resolve the issue.
Was this topic helpful?
Document Information
Modified date:
25 September 2022
UID
swg21997476