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 <arnie AT gormur DOT
com>
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*
> arnie AT gormur DOT com
>
>
> On Fri, Apr 1, 2016 at 9:01 AM, Loon, EJ van (ITOPT3) - KLM <
> Eric-van.Loon AT klm DOT com> 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:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf Of
> > Stefan Folkerts
> > Sent: donderdag 31 maart 2016 17:55
> > To: ADSM-L AT VM.MARIST DOT EDU
> > 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 <
> arnie AT gormur DOT com>
> > 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*
> > > arnie AT gormur DOT com
> > >
> > ********************************************************
> > 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
> > ********************************************************
> >
> >
>
|
