Hey @JamieK ! Dedupe pruning in v10 was a bit of a different animal and (as I’m sure you know by your emoticon) not as efficient as v11.
I would start with the big items that are the most likely to cause you slow/no pruning in v10:
- Do they have a corrupt store? run a SELECT * from idxsidbstore and see if any have a status of 1. v11 reports and deals with these much better
use Commserv
select * from idxsidbstore
/this will list all stores, identify and make note of with a status of 1].
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 corrupt store]
Described in this thread as well:
- If you don’t have corrupt stores, see if pruning is impacted by running jobs. We often gave precedence to running backups so if jobs are never NOT running, pruning would never run.
- What does sidbprune.log show? Is it at least trying to address pruning? do we see any errors?
Starting with the above 3 items should almost certainly find the problem, though if not, let me know!
Top man @Mike Struening ! I’ll give these a go and report back any findings.
Thanks,
JamieK
Great! I’m confident you’ll get to the bottom of the mystery with the above tests, but if not, we’re here!!
...their call) and last year new additional storage was configured in their CommCell (2 sites). A new library and mount paths were created in each of the sites and new Primary and DASH copies created with data paths to the new storage in the respective sites.