Thanks for the feedback. If you've successfully done source-side dedup
with an SSD-backed TSM DB with Oracle TDP, can you provide any indication
of the transfer rates that you can see? Like, would you be able to
successfully backup a 100GB DB in say less than an hour. That would be
about 27 MB/sec? I'm currently seeing rates of 3MB/sec. Pretty pitiful.
Our DB is on an auto-tiering VMAX (FAST VP) backed by about 1TB of Flash.
FAST VP transfers the hotspots to Flash normally dictated by some
secret-sauce formula of read-rates and cache misses or something to that
effect. I have very little I/O wait coming from the TSM server DB's
during the TDP backup. I'll have to check on the client to see if there's
a bottleneck there.
Thanks again!
Sergio
On 1/21/15, 4:16 AM, "Stefan Folkerts" <stefan.folkerts AT GMAIL DOT COM> wrote:
>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
>>
|
