Skip to main content

Hello,

I'm not sure if compression/dedupe savings for this DB is fine. Actually, it seems poor… any ideas on what it could be? It's not a special DB…

The online fulls are below 30% in savings. Incrementals and archive logs are above 50% in general..

Regards,

Pedro Rocha

Hi @PedroRocha ,

 

Good day! 

 

If you have an Oracle database that uses Transparent Data Encryption (TDE), then take the following parameters into consideration to help determine the compression savings:

  • RMAN compression

  • The BFS value

  • The Commvault compression option

Use the following settings when you have an Oracle database that uses Transparent Data Encryption (TDE):

  • Deduplication is enabled

  • RMAN compression is disabled on the client

  • Commvault compression is enabled

  • Set the Data Files (BFS) value to 1

Commvault Parameters

Use client side deduplication with compression on the client (ON).

Use 128K for the deduplication block size, but if the data rate changes, you can increase the size to 512K.

If your dedpulication performance is lower than you expect, set the Data Files (BFS) value to 1, and then use more than 1 stream when you perform the backup.

Refer to the below article. 

https://documentation.commvault.com/2023e/expert/20285_oracle_performance_tuning.html

 

Kindly let me know if you have any queries. 

 


Hello! thanks for the answer.

So, considering we are not using TDE… Recommendations would be the following?

1) Use client side deduplication with compression on the client (ON).

Ok, already using.

2) Use 128K for the deduplication block size, but if the data rate changes, you can increase the size to 512K.

 

3) If your deduplication performance is lower than you expect, set the Data Files (BFS) value to 1, and then use more than 1 stream when you perform the backup.

 

We have BFS defaulted to 8. Changing it to 1 would possibly increase savings?

Regards,

Pedro


Reply