Drilling holes is more of a hardware vendor supported feature. Essentially it means that as small pieces of a chunk file can be pruned, we drill holes into the big block (freeing up some small space).
If your hardware does not support drilling holes/sparse files, then you can run a Space Reclamation to get that back:
https://documentation.commvault.com/11.24/expert/127689_performing_space_reclamation_operation_on_deduplicated_data.html
Rereading what you originally posted, I may have conflated micro pruning and drilling holes (which are not the same, though they are similar in concept….just not where they apply) so we can ignore my comments regarding that feature, though I’ll leave them there for informational purpose 
So if we’re talking strictly about micro pruning of the dedupe store (before we even worry about the physical deletions). If this is the case, then you need to ensure that ALL jobs in a store age off logically before you reclaim any space.
Looking at the report, you have a lot of older jobs sitting around waiting to be copied, and a few others I recall for deconfigured subclients.
I covered the best way to find the jobs in another thread here:
Here’s the instructions:
If you have access to the SQL studio manager on the CS, below queries can be run to confirm if there are any jobs stuck in the DB for the DDB store.
use Commserv
select * from idxsidbstore
[this will list all stores, identify and make note of the store id for the one you are concerned with].
Next run the following query to list jobs associated to this DDB.
use Commserv
select * from archjobsonstoreinfo where storeid = n
[n = store id for the DDB in question]
If this query outputs any jobs, You will have to run qoperation per instructions in BoL link for qoperation agedata
https://documentation.commvault.com/commvault/v11_sp20/article?p=45239.htm
Now if that turns up empty, then we need to look at the SIDBPrune and SIDBPhysicalDelete log files on the Media Agents to see why data is not being removed.
