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> | ar...@gormur.com | http://gormur.com
| Skype: arnieggertsson
<http://dk.linkedin.com/in/arnieggertsson>
On Wed, Sep 7, 2016 at 10:20 AM, Martin Janosik <martin.jano...@cz.ibm.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
>
