Hi Anri,
since TSM server 7.1 it seems that server splits large objects into smaller
chunks (default=yes)
> help update node
...
SPLITLARGEObjects
Specifies whether large objects that are stored by this node are
automatically split into smaller pieces, by the server, to optimize
server processing. Specifying Yes causes the server to split large
objects (over 10 GB) into smaller pieces when stored by a client
node. Specifying No bypasses this process. Specify No only if your
primary concern is maximizing throughput of backups directly to tape.
The default value is Yes.
On TSM 7.1.6 I'm observing following savings during full backup:
09/12/2016 01:33:03 ANR0951I Session 424697 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 319,384,083,580. Inline data deduplication
reduced the data by 15,943,331,431 bytes and inline compression reduced the
data by 126,899,071,930 bytes. (SESSION: 424697)
09/12/2016 01:33:06 ANR0951I Session 424704 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 319,393,258,760. Inline data deduplication
reduced the data by 15,541,967,567 bytes and inline compression reduced the
data by 124,230,367,566 bytes. (SESSION: 424704)
09/12/2016 01:33:54 ANR0951I Session 424706 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 319,348,693,600. Inline data deduplication
reduced the data by 15,800,496,590 bytes and inline compression reduced the
data by 126,268,578,855 bytes. (SESSION: 424706)
09/12/2016 01:34:12 ANR0951I Session 424701 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 319,402,433,940. Inline data deduplication
reduced the data by 15,290,376,532 bytes and inline compression reduced the
data by 126,178,977,588 bytes. (SESSION: 424701)
09/12/2016 01:35:57 ANR0951I Session 424700 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 319,389,326,540. Inline data deduplication
reduced the data by 16,444,469,647 bytes and inline compression reduced the
data by 125,242,586,296 bytes. (SESSION: 424700)
Original data 5*310GB
Deduplicated by 5*15GB
Compressed by 5*125GB
Dedup+compression savings ~45% -> this seems got better recently, but far
from SAPORA / ORA / MSSQL / TSM4VE savings
Log files have also pretty decent savings:
09/12/2016 02:08:19 ANR0951I Session 427521 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 78,644,400. Inline data deduplication reduced
the data by 77,979,824 bytes and inline compression reduced the data by
487,099 bytes. (SESSION: 427521)
09/12/2016 02:17:15 ANR0951I Session 427621 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 3,932,220. Inline data deduplication reduced
the data by 3,782,214 bytes and inline compression reduced the data by
141,029 bytes. (SESSION: 427621)
09/12/2016 03:21:19 ANR0951I Session 428230 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 78,644,400. Inline data deduplication reduced
the data by 74,887,548 bytes and inline compression reduced the data by
2,984,879 bytes. (SESSION: 428230)
09/12/2016 03:23:16 ANR0951I Session 428235 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 319,820,560. Inline data deduplication reduced
the data by 12,583,338 bytes and inline compression reduced the data by
199,794,984 bytes. (SESSION: 428235)
09/12/2016 03:23:35 ANR0951I Session 428239 for node SAP_PEP processed
1 files by using inline data deduplication or compression, or both. The
number of original bytes was 78,644,400. Inline data deduplication reduced
the data by 74,066,550 bytes and inline compression reduced the data by
3,596,699 bytes. (SESSION: 428239)
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 09/12/2016
01:51:36 PM:
> From: Arni Snorri Eggertsson <arnie AT GORMUR DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 09/12/2016 01:54 PM
> Subject: Re: [ADSM-L] SAP Hana deduplication savings in directory stgpool
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Hi Martin,
>
> From what I have gathered, it looks like the HANA database is backed up
in
> such big objects that deduplication fails to deduplicate, I have seen
the
> deduplication does something for the transaction logs but not for the
full
> backups,
>
> Snippet from actlog when transaction logs are shipped to TSM:
>
> ANR0951I Session 708064 for node xxxxxxxx processed 1 files by using
> inline data deduplication or compression, or both. The number of original
> bytes was 18,483,972.
> Inline data deduplication reduced the data by 126,899 bytes and inline
> compression reduced the data by 0 bytes.
>
>
> 09/12/2016 00:20:25 ANR0951I Session 695360 for node xxxxxxxx
> processed 1 files by using inline data
> deduplication or compression, or both. The number of original bytes was
> 797,085,373,292. Inline data deduplication reduced the
> data by 0 bytes and inline compression reduced
> the data by 0 bytes. (SESSION: 695360)
>
> And even if compression was enabled in the HANA database itself I would
> assume to see some compression in the dedup process (small but not zero)
>
>
> Dedup stats for said node
> Date/Time: 09/09/2016 14:07:06
> Storage Pool Name: TSP3
> Node Name: xxxxxxxx
> Filespace Name: /tdpmux
> FSID: 2
> Type: Arch
> Total Data Protected (MB): 3,490,805
> Total Space Used (MB): 3,405,573
> Total Space Saved (MB): 85,232
> Total Saving Percentage: 2.44
> Deduplication Savings: 89,372,414,238
> Deduplication Percentage: 2.44
> Non-Deduplicated Extent Count: 4,651
> Non-Deduplicated Extent Space Used: 1,832,923
> Unique Extent Count: 5,460,237
> Unique Extent Space Used: 3,551,809,145,807
> Shared Extent Count: 205,396
> Shared Extent Data Protected: 108,563,366,200
> Shared Extent Space Used: 18,488,232,525
> Compression Savings: 0
> Compression Percentage: 0.00
> Compressed Extent Count: 0
> Uncompressed Extent count: 5,670,284
>
>
>
> I am yet to try to enable compression on the stgpool since we just
upgraded
> to 7.1.6.
>
>
>
>
> *Arni Snorri Eggertsson*
> +45 40 80 70 31 <+45+40+80+70+31> | arnie AT gormur DOT com |
http://gormur.com
> | Skype: arnieggertsson
> <http://dk.linkedin.com/in/arnieggertsson>
>
> On Wed, Sep 7, 2016 at 10:20 AM, Martin Janosik
<martin.janosik AT cz.ibm DOT com>
> wrote:
>
> > Hello all,
> >
> > is anyone storing SAP HANA backups (using Data Protection for ERP) in
> > directory storage pools?
> > What are deduplication savings in your environment?
> >
> > In our environment we see only 40% savings (35%-50%), comparing to
> > predicted dedup savings 1:9 (this ratio is currently valid for backups
of
> > TDP4ERP Oracle, MS SQL, Oracle, ...).
> > This completely messes up the initial capacity planning :(
> >
> > tsm: PRYTSM1>q dedupstats DEDUPPOOL_REPL SAP_PEP f=d
> >
> > Date/Time: 09/02/2016 21:01:00
> > Storage Pool Name: DEDUPPOOL_REPL
> > Node Name: SAP_PEP
> > Filespace Name: /tdpmux
> > FSID: 2
> > Type: Arch
> > Total Data Protected (MB): 27,045,165
> > Total Space Used (MB): 16,228,576
> > Total Space Saved (MB): 10,816,588
> > Total Saving Percentage: 39.99
> > Deduplication Savings: 1,699,912,761,679
> > Deduplication Percentage: 5.99
> > Non-Deduplicated Extent Count: 8,414
> > Non-Deduplicated Extent Space Used: 3,329,503
> > Unique Extent Count: 15,846,440
> > Unique Extent Space Used: 26,082,116,838,846
> > Shared Extent Count: 7,340,821
> > Shared Extent Data Protected: 2,276,790,425,670
> > Shared Extent Space Used: 574,756,400,378
> > Compression Savings: 9,642,102,240,318
> > Compression Percentage: 36.17
> > Compressed Extent Count: 21,757,839
> > Uncompressed Extent count: 1,437,836
> >
> > Thank you in advance.
> >
> > Kind regards
> > Martin Janosik
> >
>
|
