Hey @Lionel D , hope all is well! I moved your reply to its own thread to better track a solution (and I suspect your issue differs slightly).
It sounds like you may have some jobs in the database that are still referencing the DDB that need to be pruned by command line.
If you have access to the SQL studio manager on the CS, below queries can be run to confirm if there are any jobs stuck in the DB for the DDB store.
use Commserv
select * from idxsidbstore
pthis will list all stores, identify and make note of the store id for the one you are concerned with].
Next run the following query to list jobs associated to this DDB.
use Commserv
select * from archjobsonstoreinfo where storeid = n
pn = store id for the DDB in question]
If this query outputs any jobs, You will have to run qoperation per instructions in BoL link for qoperation agedata
https://documentation.commvault.com/commvault/v11_sp20/article?p=45239.htm
Now if that turns up empty, then we need to look at the SIDBPrune and SIDBPhysicalDelete log files on the Media Agents to see why data is not being removed.
Hi Mike,
I did the first steps as you proposed but instead of using the command qoperationagedata I deleted the jobs mentioned through the commserve console for the sealed DB, it then removed all the jobs but I think the problem comes from the fact we have 2 different sites and we use a secondary copy, so I’ve now the secondary blocks which is now at 0 but the unique primary blocks are still there cause they comes from the secondary copy of the other site ( Hope I’m saying right ), so I went now to the other site and deleted there the jobs which where copied to my sealed DB ( before it was sealed ). It should I hope decrease the unique primary blocks to 0, I’m waiting now for the dataaging process to start ( I think it’s automatic once in the morning ) and I’ll see what the outcome is.
Keep me posted. If the secondary copy is using the same DDB as the Primary, then the jobs would all be holding onto the ddb.
To confirm, you DID see jobs using the SQL query and post pruning, the list is now empty?
If so, you should be in a good place once pruning begins. What I like to do is open the SIDBPhysical Delete.log files in gxtail and watch as the deletes start (the lines fly by, so you know it’s working )
Hi Mike, as the sealed DDB was still there, I opened a support ticket “Incident 210907-293”. The support found there was still some problems with some folders in the /ws/glus/folder_xxx/CV_MAGNETIC/V_...
“was able to track down 2 Volume folders that still reside on the library xxx on MountPath Folder_xxx for the sealed store ID n. I was able then to see that these two Volume folders are physically having issues deleting from the storage itself”
Renaming those 2 folders and afterwards launching a data aging process removed the sealed ddb
Wow, good catch on Support’s side!
Appreciate the sharing!