Skip to main content
commvault.com commvault.com
Solved

Enable Physical Pruning equivalent in v10?

J
Forum|alt.badge.img+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

 

 

Best answer by Mike Struening RETIRED

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
Did this answer your question?

3 replies

Mike Struening
Vaulter
Forum|alt.badge.img+23

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!

https://www.linkedin.com/in/michael-struening
MichaelCapon
1 person likes this
  • MichaelCapon
    MichaelCapon
J
Forum|alt.badge.img+1
  • JamieK
  • Author
  • 3 replies
  • June 18, 2021

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

 

Thanks,

JamieK

Mike Struening
1 person likes this
  • Mike Struening
    Mike Struening
Mike Struening
Vaulter
Forum|alt.badge.img+23

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

https://www.linkedin.com/in/michael-struening

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings