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.folke...@gmail.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 <sfuen...@umd.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 >>