IT20687: OC FLAGS DIRECTORY CONTAINER STORAGE POOL AS CRITICAL DUE TO RECOVERED EXTENT ENTRY IN SD_DEDUP_AUDIT TABLE

8.1.2.000-IBM-SPSRV-AIX
8.1.2.000-IBM-SPSRV-Linuxppc64le
8.1.2.000-IBM-SPCMS-Linuxx86_64
8.1.2.000-IBM-SPCMS-WindowsI32
8.1.2.000-IBM-SPSRV-Linuxs390x
8.1.2.000-IBM-SPCMS-WindowsX64
8.1.2.000-IBM-SPSRV-Linuxx86_64
8.1.2.000-IBM-SPSRV-WindowsX64
8.1.2.000-IBM-SPOC-AIX
8.1.2.000-IBM-SPOC-LinuxPPC64le
8.1.2.000-IBM-SPOC-Linuxs390x
8.1.2.000-IBM-SPOC-Linuxx86_64
8.1.2.000-IBM-SPOC-WindowsX64
IBM Spectrum Protect Operations Center V8.1.2 Download
IBM Spectrum Protect Server V8.1 Fix Pack 2 (V8.1.2) Downloads
IBM Spectrum Protect Server V7.1 Fix Pack 8 (7.1.8.000) Downloads

APAR status

• Closed as program error.

Error description

• The Operations Center flags a directory container storage pool
  as having a status of critical.
  Common reasons for a directory storage pool appearing as
  critical in the OC are:
  1) Damaged extents exist in the storage pool. Query damaged
  output rom an Admin command line shows damaged extents in the
  storage pool.
  2) Storage pool directories and/or their containers within a
  storage pool are flagged as critical. Drilling down in the OC
  storage pool panels will show what stgpooldir and/or containers
  are critical.
  Following the above details should lead to a fixing action with
  is usually an audit container at some level.
  The flagging of the storage pool as critical being addressed by
  this APAR is neither of the above two cases.
  A DB2 select against the sd_dedup_audit table results in an
  entry (or entries) that show a RECOVERYSTATUS of 3:
  db2 "select * from SD_Dedup_Audit"
  POOLID     4
  TYPE        1
  ID           126348669
  SOURCE      2
  DATEFOUND   2017-03-14-18.57.54.000000
  AUDITDATE   2017-03-14-18.57.54.000000
  RECOVERYMODE     0
  RECOVERYSTATUS   3
  RECOVERYID       126348669
  Since this extent has been recovered it should not be triggering
  a status of critical for the pool in which is resides. This APAR
  will address the OC flagging of the storage pool as critical in
  this situation where it should not be.
  Tivoli Storage Manager Versions Affected: All platforms 7.1.3
  and above.
  Initial Impact: Low
  Additional Keywords: SDDA TSM IBM Spectrum Protect
  

Local fix

• Using the POOLID from the entry(s) in the sd_dedup_audit table
  run the following DB2 select after first ensuring a current full
  server database backup exists:
  db2 "delete from sd_dedup_audit sdda where sdda.poolid=<ssda
  pool id> and (sdda.id not in (select sdac.chunkid from
  sd_all_chunks sdac where sdac.poolid=<ssda pool id>) OR
  sdda.recoverystatus=3)"
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All Tivoli Storage Manager server and IBM Spectrum Protect   *
  * server users.                                                *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See error description.                                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply fixing level when available. This problem is currently *
  * projected to be fixed in levels 7.1.8 and 8.1.2. Note that   *
  * this is subject to change at the discretion of IBM.          *
  ****************************************************************
  

Problem conclusion

• This problem was fixed.
  Platforms fixed:  AIX, Solaris, Linux, and Windows.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  TSM SERVER

• Fixed component ID

  5698ISMSV

Applicable component levels