Re: SAP Hana deduplication savings in directory stgpool

[Martin Janosik]

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@VM.MARIST.EDU> wrote on 09/12/2016
01:51:36 PM:

> From: Arni Snorri Eggertsson <ar...@gormur.com>
> To: ADSM-L@VM.MARIST.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@VM.MARIST.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 shi

Re: SAP Hana deduplication savings in directory stgpool

[Arni Snorri Eggertsson]

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   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 
  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: 
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>  | ar...@gormur.com  | http://gormur.com
| Skype: arnieggertsson


On Wed, Sep 7, 2016 at 10:20 AM, Martin Janosik 
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
>

Re: SAP Hana deduplication savings in directory stgpool

[Efim]

Hi,
Very often SAP HANA admins use the data compression to save memory. 
if so deduplication efficiency should fall.
Efim


> 7 сент. 2016 г., в 11:20, Martin Janosik  
> написал(а):
> 
> 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

SAP Hana deduplication savings in directory stgpool

[Martin Janosik]

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