Re: [ADSM-L] full actlog filesystem and IBM support
In your email, you have not mentioned the size of the 'archive log'.
Depending of the size of the data deduplicated you may need to setup a
very large 'archive log'.
IBM give some guidelines about the size of the 'actlog' and 'archlog'
when using deduplication. Here is the link.
Hope this will help.
*Paul-André Chassé*, B. Sc.
Analyste de l'informatique - Centre de calcul scientifique (John-S.-Bourque)
Service des technologies de l'information
Université de Sherbrooke
Tél. : 819 821-8000, poste 62582
Courriel : Paul-Andre.Chasse AT USherbrooke DOT ca
Le 2015-08-28 11:50, Sergio O. Fuentes a écrit :
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 220.127.116.11
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?