If I understand correctly the large object size will place it in the highest dedup tier and that will make Spectrum Protect create less chunks of a larger size than if the object would be smaller. But even then I would still expect to see some dedup results, even if it would be just a few percent. Especially if you create a second full backup.
On Fri, Apr 1, 2016 at 11:00 PM, Arni Snorri Eggertsson <[email protected]> wrote: > Hi Guys, > > Thanks for the feedback, My feeling is that it must be that the HANA api > does not split the objects into smaller chunks, I am actually seeing the > same issue when doing Sybase ACE backups, again large objects, but still > under 50GB > > I see good deduplication on MSSQL and Domino backups, in directory > container pools, > > Eric, HANA is SAP's own in-memory database, no oracle. > > I have client compression turned off, and even if database compression > would be turned on I would expect som deduplication, 0 is a pretty > definitive no dedup. > > *Arni Snorri Eggertsson* > [email protected] > > > On Fri, Apr 1, 2016 at 9:01 AM, Loon, EJ van (ITOPT3) - KLM < > [email protected]> wrote: > > > Hi Arni! > > Just a thought: could it be that Oracle compression is turned on? > > Kind regards, > > Eric van Loon > > Air France/KLM Storage Engineering > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > > Stefan Folkerts > > Sent: donderdag 31 maart 2016 17:55 > > To: [email protected] > > Subject: Re: Deduplication and database backups > > > > I've seen plenty of databases go to container pools and get fair to good > > deduplications results even on the first backup. > > It should not matter that it is one large object, it will make the chunks > > larger but normally you should still get some deduplication as long as > it's > > not encrypted. > > It would seem like something strange that might just be HANA specific? > > > > On Wed, Mar 30, 2016 at 3:34 PM, Arni Snorri Eggertsson < > [email protected]> > > wrote: > > > > > Hi all, > > > > > > I want to hear what others are doing in regards of deduplication and > > > large files / database backups, > > > > > > on a recent setup we are taking backups of a SAP Hana system to a > > > direcotry container, I see great dedup stats when the system is doing > > > log backups, but I get no deduplication effects when we are doing full > > > backups, the database is roughly 250 GB in size, and it looks like > > > TSM sees the object as one file. > > > > > > ANR0951I Session 550996 for node xxxxx processed 1 files using inline > > > deduplication. 251,754,067,764 bytes were reduced by 0 bytes. > (SESSION: > > > 550996) > > > > > > > > > I am not 100% sure how to handle this, .... are others using > directory > > > containers at all? are you using them for TDP Database backups ? any > > > thoughts ? > > > > > > > > > > > > > > > *Arni Snorri Eggertsson* > > > [email protected] > > > > > ******************************************************** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee only. If > > you are not the addressee, you are notified that no part of the e-mail or > > any attachment may be disclosed, copied or distributed, and that any > other > > action related to this e-mail or attachment is strictly prohibited, and > may > > be unlawful. If you have received this e-mail by error, please notify the > > sender immediately by return e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > > employees shall not be liable for the incorrect or incomplete > transmission > > of this e-mail or any attachments, nor responsible for any delay in > receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > > Airlines) is registered in Amstelveen, The Netherlands, with registered > > number 33014286 > > ******************************************************** > > > > >
