HI Givvi,
I think that table is used to keep Library information, but not the archive file delete records.

As those records are part of deduplication, I would imagine that information is kept within the DDB for the Deduplication Engine and not on the CSDB

Hi Javier, 

thanks for your reply, probably the Deduplication Engine table used to maintain this records (archive file delets) is archAgingRule but i’m not sure about that.

Deduplication is managed at a block level - blocks are tied to jobs, and when jobs aged, the deduplication database can lookup blocks associated with that job, and depending on if you use garbage collection or not, it will determine if those blocks are still used or not. If the blocks are not being used, there is a process to physically delete them.

So the Commvault database does not store any block information. All the levels of metadata are independent of each other - the index / catalog stores information about the files in a job, the deduplication database stores block information about the job, and the CommServe understands the job itself.

Hi Damian, thank you for your feedback.
What you write sounds good to me but i’m wrestling with a very specific question: 

Which of the following CommServe database SQL tables are used to maintain archive file delete records? The only answer options I have are: archAgingRule; ZeroReference; MMDeletedAF; or MMLibraryHistory.

Hi ​@givvi By referring to archive file delete records, do you mean the records which are to be pruned for a dedup job? If so, that information is internal to the Deduplication Database. The tables that you mentioned above mostly either holds config info or Library space consumption history.

Can you please provide more info on the purpose of this information?