While we don't do deduplication (tests show we gain less than 25% from it), we also split our DB2 instances across multiple, physically-separate volumes. The one thing to note is that you have to dump and restore the database to spread existing data across those directories if you add them post-installation.
On Fri, Dec 20, 2013 at 02:23:34PM -0500, Marouf, Nick wrote: > I can second that Sergio, > Backup stgpools to copy tapes is not pretty, and is an intensive process to > rehydrate all that data. > > The one extra thing I did was split the database across multiple folder for > parallel I/O to the Database. That has worked out very well, and I currently > have it setup to span across 8 folders, with an XIV backend that can take a > beating. > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Sergio O. Fuentes > Sent: Friday, December 20, 2013 12:04 PM > To: [email protected] > Subject: Re: [ADSM-L] Deduplication "number of chunks waiting in queue" > continues to rise? > > Client-side dedup and simultaneous-write to a copy pool are mutually > exclusive. You can't do both, which is the only theoretical way to enforce > deduprequiresbackup with client-side dedup. I suppose IBM could enhance TSM > to do a simultaneous-like operation with client-side dedup, but that's not > available now. So, I'm not sure how the TSM server enforces > deduprequiresbackup with client-side dedup. Ever since 6.1 I have always set > that to NO anyway. I have dealt with the repercussions of that as well. > Backup stgpool on dedup'd stgpools is not pretty. > > I have made some architectural changes to the underlying stgpools and the > 'backup stgpools' run pretty well, even with 1TB SATA drives. Two things I > think helped quite a bit: > > 1. Use big predefined volumes. My new volumes are 50GB. > 2. Use many filesystems for the devclass. I have 5 currently. I would use > more if I had the space. > > Thanks! > > Sergio > > > On 12/20/13 11:35 AM, "Prather, Wanda" <[email protected]> wrote: > > >Woo hoo! > >That's great news. > >Will open a ticket and escalate. > > > >Also looking at client-side dedup, but I have to do some architectural > >planning, as all the data is coming from one client, the TSM VE data > >mover, which is a vm. > > > >Re client-side dedup, do you know if there is any cooperation between > >the client-side dedup and deduprequiresbackup on the server end? > >I have assumed that the client-side dedup would not offer that protection. > > > >W > > > >-----Original Message----- > >From: Sergio O. Fuentes [mailto:[email protected]] > >Sent: Friday, December 20, 2013 10:39 AM > >To: ADSM: Dist Stor Manager > >Cc: Prather, Wanda > >Subject: Re: [ADSM-L] Deduplication "number of chunks waiting in queue" > >continues to rise? > > > >Wanda, > > > >In trying to troubleshoot an unrelated performance PMR, IBM provided me > >with an e-fix for the dedupdel bottleneck that it sounds like you're > >experiencing. They obviously will want to do their due-diligence on > >whether or not this efix will help solve your problems, but it has > >proved very useful in my environment. They even had to compile a > >solaris e-fix for me, cause it seems like I'm the only one running TSM > >on Solaris. The e-fix was very simple to install. > > > >What you don't want to do is go to 6.3.4.2, unless they tell you to > >because the e-fix is for that level (207). Don't run on 6.3.4.2 for > >even a minute. Only install it to get to the e-fix level. > > > >Dedupdel gets populated by anything that deletes data from the stgpool, > >I.e. move data, expire inv, delete filespace, move nodedata, etc. > > > >We run client-side dedupe (which works pretty well, except when you run > >into performance issues on the server) and so our identifies don't run > >very long, if at all. It might save you time to run client-side dedupe. > > > >BTW, when I finally got this efix and TSM was able to catch-up with the > >deletes and reclaims as it needed to, I got some serious space space > >back in my TDP Dedup pool. It went from 90% util to 60% util (with > >about 10TB of total capacity). What finally really got me before the > >fix was that I had to delete a bunch of old TDP MSSQL filespaces and it > >just took forever for TSM to catch up. I have a few deletes to do now, > >and I'm a bit wary because I don't want to hose my server again. > > > >I would escalate with IBM support and have them supply you the e-fix. > >6.3.4.3 I don't think is slated for release any time within the next > >few days, and you'll just be struggling to deal with the performance issue. > > > >HTH, > >Sergio > > > > > > > >On 12/19/13 11:35 PM, "Prather, Wanda" <[email protected]> wrote: > > > >>TSM 6.3.4.00 on Win2K8 > >>Perhaps some of you that have dealt with the dedup "chunking" problem > >>can enlighten me. > >>TSM/VE backs up to a dedup file pool, about 4 TB of changed blocks per > >>day > >> > >>I currently have more than 2 TB (yep, terabytes) of volumes in that > >>file pool that will not reclaim. > >>We were told by support that when you do: > >> > >>SHOW DEDUPDELETEINFO > >>That the "number of chunks waiting in queue" has to go to zero for > >>those volumes to reclaim. > >> > >>(I know that there is a fix at 6.3.4.200 to improve the chunking > >>process, but that has been APARed, and waiting on 6.3.4.300.) > >> > >>I have shut down IDENTIFY DUPLICATES and reclamation for this pool. > >>There are no clients writing into the pool, we have redirected backups > >>to a non-dedup pool for now to try and get this cleared up. > >>There is no client-side dedup here, only server side. > >>I've also set deduprequiresbackup to NO for now, although I hate doing > >>that, to make sure that doesn't' interfere with the reclaim process. > >> > >>But SHOW DEDUPDELETEINFO shows that the "number of chunks waiting in > >>queue" is *still* increasing. > >>So, WHAT is putting stuff on that dedup delete queue? > >>And how do I ever gain ground? > >> > >>W > >> > >> > >> > >>**Please note new office phone: > >>Wanda Prather | Senior Technical Specialist | > >>[email protected] > >>| www.icfi.com > >>ICF International | 443-718-4900 (o) > > > > -- -- Skylar Thompson ([email protected]) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
