Skip to main content

Hi Team,

 

We are about to embark on the V4 to V5 DDB conversion process, but I thought I would ask here and see how it went for those that have completed this.

 

We have a few partitioned DDB’s with a reasonable amount of size, and I am trying to gauge how long our backup-outage might be, as we have to guesstimate on behalf of our customer.

 

I can see that the pre-upgrade report does give estimates, so I’m wondering how ball-park they might be.

 

One more thing … is there a way if identifying what version of DDB we have>

 

Thanks

Hey @MountainGoat,

The process is pretty straight forward and generally goes well. The estimates are ballpark but I’d say they are conservative and you should see that timeframe as worst case scenario.

The performance benefits and scale improvements are definitely worth the time taken to convert, especially if your DDBs are on the larger side.

Even so, it would be good to see how others have experienced the upgrade!


Conversion works as expected 🙂

Time needed can be checked by running the conversion workflow and select the option: Planning, this will send you a report via mail with the results.

Workflow: https://cloud.commvault.com/webconsole/softwarestore/#!/136/672/15280 


The service pack / feature release you are on can make a difference. I did this on SP16 and noticed it was considerably faster on later SP’s / FR’s

After you do this there are other procedures to enable garbage collection.


OK - I had an obvious question which I forgot to ask.

 

Within the Upgrade Report (as obtained from the workflow-planning section), I have a number of DDB’s which do not require compaction.

 

So in that case, what happens?

I ask that because the report states that those requiring compaction go offline. But what about those that don’t?  Do they actually stay online during the upgrade process?  That sounds too good to be true, but I don’t have a test environment to prove this.

 

So for anyone checking in with this thread - if you had a DDB which was flagged as not needing compaction, what exactly happened?

 

Thanks

 


It was a while ago so I can't remember exactly, but as the DDB is upgraded I believe it needs to reinitiate the engine for this DDB and thus go offline. But my experience is that DDB not in need of compacting are processed quickly and downtime is low. But the report will give the best indication regarding duration of the upgrade.

The only action happening I believe is restructuring the tables in order to realign the pointers per table allowing faster pruning afterwards.


What if the DDBs are Transactional DDBs?


Reply