How to Verify Aged Data are prune or not?

Hi ​@CyberBot,

To confirm whether the pruning is occurring, please follow the steps outlined below:

1) **Check Phase 1 Pruning**: Execute the following query to monitor the **MMdeletedAF** table:
   `Select * from MMdeletedAF`
   - If the count is high and showing an increasing trend, please review the SIDBPrune log for any errors.

2) **Mark and Sweep Operation**: Review the SIDBEngine log for the Mark and Sweep operation and assess its functionality.
     "Mark and Sweep" should run on daily basis.

Sample log cut:
Here DDB store ID:123, DDB substore ID:456.

****538549 837b5 07/29 10:37:46 ###123-1-456-1 MSOpen          10312  Mark And Sweep.Last Run [Mon Jul 28 19:35:10 2025]***

Note: As of 7/29 log, we see that the "Mark And Sweep" ran on 07/28, this ensure that the operation was successfully executed just one day prior to July 29.

3)**Pending Deletes Record**:  Analyze the SIDBEngine log for the count of Pending Deletes. If high, check the SIDBPrune log for any issues.

Sample log cut:
Here DDB store ID:123, DDB substore ID:456,

****538549 837b5 07/29 10:37:46 ### 123-1-456-1 LogCtrs          5224  Primary [1737187]-[553816557423]-[0]-[0]-[0]-[0], Secondary [11236658]-[2954867253122]-[0]-[0]-[0]-[0],Pending Deletes [0]-[0]-[0]-[0]-[0]-[0], Lonely [0]-[0]-[0]-[0]-[0]-[0], Uncommitted [0]-[0]-[0]-[0]-[0]-[0], Bad [0]-[0]-[0]-[0]-[0]-[0]****

Note: The "Pending delete" is "0", which is expected value.

4) **DDB Space Reclamation**: If there are no issues with pruning and the "Total Data Size On disk" exceeds the "Total Estimated Media Size" by more than 30% with conditions regarding sparse files and MICRO pruning, we may need to run DDB space reclamation.  For guidance, refer to the following document:
https://documentation.commvault.com/11.40/expert/performing_space_reclamation_operation_on_deduplicated_data.html

5) **Library Space Expansion**: If the "Total Data Size On disk" does not exceed the "Total Estimated Media Size" by more than 30% and the "Deduplication saving percentage" is good, please proceed with expanding the library space.

Regards,

Wasim

Hi ​@CyberBot , My friend Wasim summed it up pretty well here. Although, just to ensure things look easier, 

First, check if your backup jobs are deduped or non-deduped. This makes a big difference in how pruning works.

Next, run this query on the CommServe database:
select * from MMDeletedAF
If you see thousands of records here, it indicates data waiting to be cleaned up. You would see a column named “FailureErrCode”, see if you have any codes like 530312 etc..if yes, post it here. It basically means CS sent the request to MA, but MA could not delete it and sent a response back to CS with a code. If you see a code, there is a definite issue with pruning here. 

For deduped jobs, check the SIDBStoreId value in those records. If it’s non-zero, it’s deduped. For non-deduped jobs, the SIDBStoreId will be 0.

If your jobs are non-deduped, check the CVMA.log on the MediaAgent responsible for that library to see if there are any issues.

For deduped jobs, you need to check the sidbprune.log to confirm if pruning is working. To do that:

1. Find the Mount Path by running:
   select * from MMLibrary to get your LibraryId

2. Then run:
   select * from MMMountpath where LibraryId = <your_library_id>

3. Use the Mount Path ID to filter the sidbprune.log on the MediaAgent and check for pruning activity or errors.

If pruning is running fine, the issue could be aging settings—jobs might be kept longer than expected.

As for your disk full issue, this is often related to pruning delays. Once you confirm pruning is working, space should free up as data is cleaned.