I would recommend looking to see if there is one or two clients causing you a lot of issues and dragging the % down. For example in the past i have seen a SQL DBA performing native SQL dumps to a VM disk every day with encryption enabled on those dumps. Every day a new one was written and the old one was deleted. This caused 1-2TB a data change and due to the encryption we got 0% dedup on it.
This is one example of a large amount of data getting 0% dedup that can make an entire DDB look unhealthy. If you got to your Storage policy and view the jobs on the primary copy you can add the column “savings” and see if there is one with a really low number.
Kind regards
Albert Williams
Hi,
Problem is while checking individual job it showing above 70% , however on DDB SAVING its is showing around 10%
Hello @Rahul18081
The saving is both Dedup and compressions so the numbers are not expected to line up.
If i was on a session with you i would use the job list or graphs inside of the DDB details to go over what client is writing the most of focus on it to see why its dedup is so low.
I recommend opening a support ticket as this is a “find the problem” kind of issue and that is always easier on a remote session.
Kind regards
Albert Williams
Hello William ,
we have open the case but still not get the resolution, lastest is vendor asked to make to change some value in Media Server configuration and asked us to wait for next 72 hrs . As vendor review the logs and he said as per the logs we could see issues with the Volume update on the Library. But not sure how it will impact on the environment. And we are worried as now only 11% space left on storage.