Re: [ADSM-L] full actlog filesystem and IBM support

2015-08-31 14:41:03
Subject: Re: [ADSM-L] full actlog filesystem and IBM support
From: Paul-André Chassé <paul-andre.chasse AT USHERBROOKE DOT CA>
Date: Mon, 31 Aug 2015 14:39:12 -0400

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
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?


<Prev in Thread] Current Thread [Next in Thread>