Interestingly enough there are 2 conflicting theories regarding SQL and ORA transaction log deduplication and pruning question.
There is one from CV support engineer:
“We discussed high Q&I times and any way to reduce the load on the DDB.
We both acknowledged that SQL Transaction Logs are not deduplicated, however you were curious if the T-Log backups communicated in anyway to the DDB which may impose any, albeit minimal, load or processing on the DDB.
I was able to confirm that SQL Transaction Log backups do not communicate with the Deduplication process and therefore will not have any effect on Q&I times:
But but but, other CV engineer says if the storage policy used for trans logs is deduplicated, CV is not smart enough and will try to deduplicate anyway. It will also involve pruning at the end of the cycle. And when I look at the jobs from deduplication engine level, I see my transaction log job there. If it is there, obviously it would require pruning, will it not? And another interesting indicator, while running the trans log job, average throughput line shows DDB look up eats up 95%+ of time. Given these few issues, I am thinking second engineer is more likely right.
Which engineer is right? I have V11.20
I have terrible DDB performance due to slow SSD drives, and I am hunting for any even minimal DDB performance improvements venues, without sacrificing too much storage.
Do we have someone very familiar with DDB details?
The theory is that later, up to date Commvault versions can handle transaction logs backups in the deduplicated storage policy without ANY sacrifice of precious DDB resources. Thus putting trans logs into dedicated non deduplicated storage policy is a waste of administrative time if retention is the same. Which theory is correct?
Best answer by Matt MedvedeffView original