Direct links to fixes
7.1.6.000-TIV-TSMSRV-Linuxs390x
7.1.6.000-TIV-TSMSRV-Linuxppc64
7.1.6.000-TIV-TSMSRV-WIN
7.1.6.000-TIV-TSMSRV-SolarisSPARC
7.1.6.000-TIV-TSMSRV-Linuxx86_64
7.1.6.000-TIV-TSMSRV-HP-UX
7.1.6.000-TIV-TSMSRV-AIX
7.1.5.100-TIV-TSMSRV-SolarisSPARC
7.1.5.100-TIV-TSMSRV-WIN
7.1.5.100-TIV-TSMSRV-Linuxx86_64
7.1.5.100-TIV-TSMSRV-Linuxs390x
7.1.5.100-TIV-TSMSRV-Linuxppc64
7.1.5.100-TIV-TSMSRV-HP-UX
7.1.5.100-TIV-TSMSRV-AIX
IBM Spectrum Protect Server V7.1.5.X interim fix downloads
IBM Spectrum Protect Server V7.1 Fix Pack 6 (7.1.6.000) Downloads
APAR status
Closed as program error.
Error description
When a PROTECT STGPOOL process fails or gets cancelled for any reason, there will be orphaned chunks created on the target container storage pool. This will cause the target storage pool to grow overtime. The fix for this APAR will prevent new orphaned chunks. The existing orphaned chunks will need to be deleted. See the Local Fix section for more detail. IBM Spectrum Protect Versions Affected: Server version 7.1.3 and later Customer/L2 Diagnostics 1. Use QUERY STGPOOL command to check the storage pool usage on the source and the target server. The target server will use more space than that of the source server. 2. Check the server activity log for any cancelled or failed PROTECT STGPOOL processes. 3. Use the following DB2 command to obtain the number of replicated chunks on each server: db2 "select count from tsmdb1.sd_replicated_chunks for read only with ur" The count on the target server will be greater than the count on the source server. Initial Impact: High Additional Keywords: TSM IBM Spectrum protect replicate node 115522
Local fix
These steps will delete all the existing orphaned chunks on the target server. Note #1: If the target storage pool has a REUSEDELAY value greater than 0 and the storage space is becoming critical, change the REUSEDELAY to 0 so the deletion can occur sooner. It can be updated back to the original value after all orphaned chunks have been deleted. From the source server: 1. Run PROTECT STGPOOL with FORCERECONCILE=YES 2. Run PROTECT STGPOOL with PURGEDATA=ALL 3. Run PROTECT STGPOOL with FORCERECONCILE=YES 4. Wait for #3 to finish successfully. From the target server: 1. Monitor extent delete with: Q EXTENTUPDATES <Container Pool name> 2. Wait for no remaining extent updates. 3. Change the REUSEDELAY back to the original value if it was updated in the beginning. Note #2: The PROTECT STGPOOL PURGEDATA=ALL can potentially affect the target server performance. If you experience a noticeable performance degradation while running it, consider running it during the time when the server is mostly quiesced. Cancel it during the heavy workload hours and continue when the server is quiesced again.
Problem summary
**************************************************************** * USERS AFFECTED: * * All Tivoli Storage Manager server users. * **************************************************************** * PROBLEM DESCRIPTION: * * See ERROR DESCRIPTION. * **************************************************************** * RECOMMENDATION: * * Apply fixing level when available. This problem is * * currently project to be fixed in levels 7.1.5.100 and 7.1.6. * * Note that this is subject to change at the discretion of * * IBM. * ****************************************************************
Problem conclusion
This problem was fixed. Affected platforms: AIX, Solaris, Linux, and Windows.
Temporary fix
Comments
APAR Information
APAR number
IT14233
Reported component name
TSM SERVER
Reported component ID
5698ISMSV
Reported release
71W
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-03-18
Closed date
2016-03-29
Last modified date
2016-03-29
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
R71A PSY
UP
R71L PSY
UP
R71S PSY
UP
R71W PSY
UP
Document Information
Modified date:
26 September 2021