Hello PatricG,

The DDB Conversion workflow will give you the option to select the DDB Store(s) that will be converted.  As per our Online Documentation regarding “Performing the Conversion of a Deduplication Database from Version 4 to Version 5”, this can be seen in Step 9.  I can place a link to this below.

In regards to stopping production, “The DDB partitions that require compaction will be offline during conversion.”  As such, no Jobs will able to run to the DDB Store(s) that are being converted while the operation is taking place.  This can be seen in our Online Documentation regarding “Planning the Conversion of a Deduplication Database from Version 4 to Version 5”

Performing the Conversion of a Deduplication Database from Version 4 to Version 5:

https://documentation.commvault.com/2023e/expert/performing_conversion_of_deduplication_database_from_version_4_to_version_5.html

Planning the Conversion of a Deduplication Database from Version 4 to Version 5:

https://documentation.commvault.com/2023e/expert/planning_conversion_of_deduplication_database_from_version_4_to_version_5.html

@PatricG 

You can typically expect a degree of performance improvement with the new DDB structure after converting.
Improvement in the Query Insert performance as well as pruning of the DDB.

Part of the new DDB table Structure is as follows:

In the Primary Table (where Unique/Baseline blocks are Tracked)  there are now fewer fields.
This means that during backups/Aux Copies we no longer need to update these Counter fields.  This will reduce the I/O  on the DDB's Disk.
This also helps in pruning as these counter fields no longer need to be updated during the pruning process.

As for Secondary Tables (Where duplicate blocks are noted) we will reference less job data per secondary File.
Before the conversion Secondary Table files would reference 16 Job Archive Files.  After the Conversion only 1 ArchiveFile will be referenced.
This will result in More Secondary Files, but they will be smaller.

More importantly is there is no longer any bloat in these secondary Files.
Prior to the Conversion the Secondary Record Table Files would have references for up to 16 different Backup Jobs.
Often you would then have scenario where many of those jobs aged. 
So for Example there might only be 1 or 2 Archive Files still in retention, but since the Secondary Table File is still consuming the space on disk as when it was holding 16 valid Archive files.
-- Now since each Secondary file only holds a single Archive, it will only be tied to a single backup job.  Once that job meets retention the entire DDB secondary file can also be pruned.

In General all this means:
- improved performance and efficiency on writing AND Pruning of data from the DDB. 
- less I/O impact on the DDB's Host disks
- smaller footprint of the DDB when there are mixed/different job retentions 
- improved Scalability of the DDB
- Allows improved DDB Reconstruction Logic and performance
 

Z-man