Solved

Enable Physical Pruning equivalent in v10?

  • 17 June 2021
  • 3 replies
  • 14 views

Badge +1

Hi all,

I have a client still running v10 (yes, I know :rolling_eyes: ...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.

I’m finding that the storage for the Primary copy in their main site is filling up and there is nothing obvious in the forecast report. Is there such a setting in v10 which corresponds with the Enable Physical Pruning in v11? 

Thanks in advance.

JamieK

 

 

icon

Best answer by Mike Struening 17 June 2021, 16:07

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:

  1. 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: 

  1. 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.
  1. 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!

View original

3 replies

Userlevel 7
Badge +17

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:

  1. 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: 

  1. 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.
  1. 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!

Badge +1

Top man @Mike Struening ! I’ll give these a go and report back any findings.

 

Thanks,

JamieK

Userlevel 7
Badge +17

Great!  I’m confident you’ll get to the bottom of the mystery with the above tests, but if not, we’re here!!

Reply