What type of storage are you using for the TSM database?
I've seen client-side dedup running fast for databases with SSD's for TSM
database and activelog but not so much with traditional harddrives, even if
it was bunch of 15K disks, it just doesn't deliver like 4 SSD's.

>From what I have seen you pretty much require SSD's for the TSM database if
you want any serieus performance on client-side deduped structured data
backups that want to stream a lot of data. Also for client-side dedup of
VM's when you are backing up a lot of them at the same time.

File-level incrementals have a different impact because there is filesystem
scanning going on to somewhat relieve the TSM DB disk iop/s wise, start a
few databases with client-side dedup and see the wait i/o increase
significantly if you don't use SSD's.

This is just my experience from a few customer sites.



On Tue, Jan 20, 2015 at 10:07 PM, Sergio O. Fuentes <sfuentes AT umd DOT edu>
wrote:

> Hello folks,
>
> I've been using source-side deduplication pretty successfully for most of
> my clients (Unix and Windows and TDP for MSSQL)  for at least two years
> now.  The backup window for the source-side is significantly shorter for
> Unix clients, minimally shorter for Windows and somewhat longer for MSSQL
> nodes on average.  The pain I've been having is with Oracle RMAN and TDP.
> I'm unsure if our older Oracle servers are just really undersized or if
> it's a function of TSM dedup overhead while doing source-side dedupe that
> is expanding the backup window way too long.  I have tested several
> versions of TSM against several versions of Oracle (10 and 11) on several
> different hardware Oracle Solaris tiers.  I wanted to see if anyone in the
> group has had any significant achievements with source-side dedup and
> Oracle DB's.  Am I being overly optimistic with TSM or TDP and its ability
> to process over 100GB of DB data for one node for a level 0?  Our databases
> are not that large, with the largest being about 400GB (and doing level 0's
> on that thing is a nightmare).
>
> Here's some info on the environment settings that I'm currently testing
>
> Deduplication ON in TSM and Client
> Compression ON in TSM
> Filesperset 1 in Oracle for Data files
> Filesperset 10 in Oracle for Archive logs
> Archive and Data files are both processed for dedup (I don't like the
> complexity of managing a non-dedup storage tier just for logs, so I'll try
> to eat the overhead on that)
> TSM API at 7.1.1.0
> TDP Version at 6.3.0
> RMAN version ?
> Oracle version 10, moving to 11 but having same performance issues
> TSM catalog is on an auto-tiering SAN array with flash.
>
> Right now, my failback is to do post-process deduplication and that's
> worked out fine, but I really want to see what kind of ingestion rates we
> should be able to see with Oracle RMAN and TSM source-side deduplication.
>
> Also, I'm not shelling out money for a VTL right now.  The decision was to
> stick with TSM Dedup and aside from nagging clients like Orace RMAN and
> TDP, I've had no issues with TSM dedup.  (Running a TSM server on Solaris
> was awful, however).
>
> Thanks!
> Sergio
>