I've been working with IBM support on a particular issue that is difficult to recreate and so everytime it happens I have to reopen a new ticket where Level 1 support tells me that it's working by design and then there's no further follow-up. Then I have to argue with them that this needs to be escalated to level 2 and then I still get an update that it's working by design and there's no escalation. So I'm reaching out to this group to see if anyone has experienced this following scenario. Further, I'm hoping IBM developers that monitor this listserv might be able to have my PMR escalated to level 2 and have a closer look taken at it:
TSM server 7.1.1.100 Deduplication turned Average about 5-7 TB of nightly backup Replication turned on replicates about 4 TB's of data Issue that I can anecdotally say triggers the behavior: Millions of objects in the dedupdel threads. Anything over 50 million. dsmserv.opt has actlog size to be 128GB actlog filesystem is 256GB TSM should only allocate 128GB of actlog space in the filesystem. After an expiration triggers this dedupdel queue to blow up I see the actlog filesystem filling up to 100%. However q log f=d reports only a small amount of actlog space used. The TSM server is responsive for hours after the filesystem fills up but my OS guys hate me cause they're getting filesystem full alerts. Hours later the dsmserv application will die but db2 remains up. To resolve the issue none of the technotes that exist on IBM's websites help. There's no need to increase the actlog space, but rather what I do is start db2 on its own, let it keep trying to flush the logs for a little while. Then after about 2 hours, I bring up TSM which operates fine since it thinks it's only using a small amount of actlog and we proceed to go back to operations. No problems. But the actlog remains full for several hours or even days later. This happens for us on a monthly basis as we have to purge a lot of dedup data monthly. Any similar issues from anyone? Thanks! Sergio