Hi all
i need your help to understand table architecture for Deduplication database v4 gen2 table structure and there functioning. There is as such no information available on documentation explaining current ddb table structure. Please help with the information if possible.
+23
Hi
I’m curious why you would need that info? Wondering if we can help in some other way.
Keep in mind that it is not a user-accessible database (i.e it's not something like SQL that can be queried by a user). In either case, there is more detailed info in this video: https://commvaultondemand.atlassian.net/wiki/spaces/ODLL/pages/501350567/Tech+Talks#TechTalks-DeduplicationGeneration4Version2
+23
Thanks!
+10
Some info would be useful though, like how many bytes to each Primary & Secondary record to get an idea how much space the DDB would consume. From what I can see the numbers quoted from the Cv v9 era don't apply.
+2
Hi All thank you for your replies. Special thanks to
I started a very similar thread last week, not finding this previous thread. I was reading the documentation for Commvault V11.24, and found references to upgrading from DDB Version 4 to DDB Version 5, but no other references to what the differences between these two DDB types are. A “Vaulter” named Blaine replied to that thread that “DDB Version 5” is another name for “DDB Version 4 Gen 2”.
I was also curious how I can tell what version of a given DDB I am using currently?
(Since we started in Commvault 11.8.) It’s good to know how your product works!
I’m excited to give the video
DDB v5 is a Version4 DDB with Garbage Collection Enabled.
You can confirm that in the Console:> See Example from my Lab.
V5 makes the Secondary Table files much more efficient.
Instead of each secondary TableFile containing up to 16 jobs worth of information it will only have 1 Job. This will mean many more Secondary Files, but they will be smaller. And more importantly since each secondary Table file are only associated with a single job, then pruning of the DDB is much better. When the job meets retention the corresponding secondary Table files can be pruned as a whole.
The older method required pruning out sections of the Secondary file when it was associated with multiple jobs. This in turn meant bloat, especially with mixed retentions. The entire secondary file used to be retained even if for example 92% of it was just empty whitespace.
-Z
This is great information! So I have a mix, then. They’re all labeled as “Version 11” DDBs on each DDB’s property, but underneath the covers they’re either version 4 or version 5.
Thanks!
I have been reading about the V4 Gen2 as well. I was wondering what version my DDB’s are. I do see Garbage collection enabled, but it was also create over 4 years ago… 4/18/2017.
Is there any other log I can look at or command to run that can confirm my DDB version?
Thank you,
+23
I have been reading about the V4 Gen2 as well. I was wondering what version my DDB’s are. I do see Garbage collection enabled, but it was also create over 4 years ago… 4/18/2017.
Is there any other log I can look at or command to run that can confirm my DDB version?
Thank you,
If you have garbage collection enabled then you have the most up to date DDB version!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
