The deduplication databases (DDB) are arguably the most important component in an efficient and fast CommVault environment.
If you’ve ever had a Media Agent fail unexpectedly before the DDB’s were able to gracefully shutdown, you’d be well aware the the restore and rebuild times can be very long.
In Version 11, there have been improvements made to the DDB architecture, allowing some advanced options to be implemented.
FIrstly, you can upgrade your existing V10 and V11 DDB’s to be Transactional. This means that in the event of a crash, the DDB can be recovered in seconds and the requirement to wait hours for restores and reconstructions to complete is a thing of the past.
The process to convert does take some time, and during this time, the DDB partitions will be put into Maintenance Mode preventing jobs (with Deduplication enabled) from running.
In this case, I had a 294GB DDB, that took around 1 hour and 35 minutes. As you can see, the drives get a good workout.
The syntax is; (sidb2 utility is located in the Base folder where the software is installed, typically c:\Program Files\CommVault\Simpana\Base
sidb2 -convert memdb -in <instance_number> -cn <client> -i <engine_id> -split<split#>
Details required are -in instance number, -cn (client name or MA hostname), Engine ID and Split #
To find the Split #, run this PowerShell snippet from the root of the drive hosting your ddb;
|
1 |
ls *SPLIT* -Recurse -Directory |
Note the number under the Name header.
The instance and DDB Engine ID can be noted from the DDB properties in the console under Storage Resources.
In my case, the Instance was “Instance01” the Split was “00” and the Engine ID was “86“.
Once you’ve got them all, let it rip.
The process recreates the db components, and as a benefit can remove whitespace, potentially freeing up space. Here’s the space utilization before & then after. It’s always nice to reclaim some space on expensive SSD’s.
Ciao.