Skip to main content

Hi All.

I have a DDB on a Linux Media Agent running in Azure. The “CommServe Job Records to be Deleted” is very high and reporting as Critical in the Command Center Health Report.

I have confirmed that the Storage Policies associated to this DDB is enabled for Data Aging. Physial pruning is also enabled on the DDB.

When running Data Aging to this specific DDB/Copy there is no entry in the MediaManagerPrune log on the CommServe for this DDB ID. All the other DDBs are listed.

There is also no SIDBPhysicalDeletes log file on the MA.

I have checked the jobs and no jobs are retained past the retention period.

Any idea what would cause the records to remain on this DDB?

Let me know if you require any additional information that could assist.

Thank you.

Ignes

 

Thanks for the thread, @Iggy !

You’ve already checked what I was going to ask for, though I’d also like to see the SIDBPrune.log and the SIDBengine.log file as well.

Are there any other Media Agents that have access to prune these records from the DDB?  According to the chart, there are jobs to be deleted, but no blocks.

Either:

  • Data Aging is not running
  • No Media Agent is available to decrement from the DDB to see which blocks can be cleared

The Physical deletion only starts once there are prunable blocks in the DDB’s Zero Reference table, which only happens when a Media Agent deducts references for all pruned blocks from the jobs aged off via Data Aging:

  1. Data Aging runs
  2. X number of jobs age off
  3. The blocks that those jobs referenced are sent to the Media Agent connected to the DDB
  4. All references are decremented one time for each reference in the aged jobs (i.e. if 5 aged jobs referenced block ABC, then the number of references would go down 5)
  5. The list of Zero Ref blocks (blocks that now have 0 references to them) are sent off to the pruning Media Agent
  6. Deletions start showing in SIDBPhysicaldeltes.log
  7. Space clears up on the drives

With that in mind, something before step 4 is not happening.

Let’s confirm the logical Data Aging job has run, and confirm if any other Media Agents are connecting to the DDB for record pruning.

 


Hi Mike.

Thank you for all the information.

I have run through the points you list.

This DDB is only hosted on single MA. Below are the DDB info and the MA Data Paths.

 

I manually run a Data Aging job as below:

I do notice that the logs states that no data qualify to be aged.

 

Pruning is enabled on the DDB and at the Storage Policy level.

 

One thing that I note on this DDB is that the Deduplication saving is 0% which is very strange.

 

There is no update in the MediaManager log file on the CS. The SIDBPrune log on the MA is also not being updated.

 

Any ideas will be appreciated.

Thanks.

Ignes

 


Hmmmmm, definitely an interesting case!

Can you run the Data Retention Forecast and Compliance Report on this library and see why jobs are not pruning?

Also, look at the bottom for the DDB and see if there are any warnings.


Hi Mike.

There is a couple of jobs retained by extended retention but not the bulk of it and not to the size that is mentioned in the DDB.

I do however see the below in the report:

 

 

I unchecked the option below as this is a cloud library and all MAs do have access to the library.

 

The DDB is still reporting that there is Application Data to be freed.

 

I think it might be worth opening a Support case for this as I do not have more ideas here.

 

Thanks for your time.

Ignes

 


The problem is in the “Delay Reason for Physical space cleanup” column: "Cloud Mount Path has a dedicated pruner Media Agent set but the Mount Path data is not accessible from the Media Agent"

It looks like the Media Agent set to prune off the space has no access to the path.

I can see that we have seen this issue and resolved it before using a script called operation execscript -sn SetDeviceControllerProps (link below), though if you aren’t comfortable running this, open a support case:

https://documentation.commvault.com/2022e/expert/SetDeviceControllerProps.html

If you open a support case, let me know and I’ll reach out to the incident owner once you reply.


Hi Mike,

Thanks for the guidance.

This is a cloud configuration where all Media Agents have access to the Mount Path within the Cloud Library. Not sure why this MA would not be able to prune data.

But I did uncheck the below option which look to have worked.

I can see the number of Pending Prunable records has dropped.

For my information, is there a parameter in the script you provided that allows me to check the current status?

 

Thanks.

Ignes

 


The script allows you to set a number of parameters to device controllers, though not anything regarding the DDB pruning status.

You should see activity (“and counts) in SIDBPrune.log and SIDBPhysicalDeletes.log, though I would suggest checking the logs on ANY Media Agent with access to the library since it might be a different one doing the pruning than you expect.


Reply