+2
Hi, I’ve an old sealed DDB with no more jobs associated to it, it only shows some number of unique blocks left ( for a size of 1,18TB ) , secondary blocks is 0 , application size is already at 0. How can I then do what you proposed to do: “then remove ALL of the blocks for that store in one big macro prune.”?
Cause I’d like to get totally rid of that sealed DDB ?
Best answer by Lionel D
View original
+23
Wow, good catch on Support’s side!
Appreciate the sharing!
+2
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
+23
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 
)
+2
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.
+23
Hey
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
[this 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
[n = 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.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
