Skip to main content
Question

Commvault APIs are inconsistent when moving database across subclients

Hi there, not sure if anyone has seen the same issue before. Here is what we do:

We need to suspend backup for one Sybase database because the database needs to execute its own house keeping like re-index etc. We are trying to automate this using Commvault API:
 

  • We receive the request to suspend a database(db1) from instance(asset1).
  • Our program will loop through the asset1 and see where db1 is and found it is in subclient “sub1”.
  • We will then create a “dynamic1” subclient
  • Delete the “db1” from “sub1” subclient.
  • Add “db1” to “dynamic1” subclient

Now the house keeping is done and we need to resume the backup of db1:

  • We received the resume request
  • Loop through Commvault server where db1 is through API
  • We found db1 is in default subclient alreay

Now the adhoc Full backUp is called immediately because the house keeping has change the database structure and we don’t have a base-line

  • Adhoc backup request is received
  • Loop through asset1 and see where db1 is and found it is in subclient “default”
  • Create a “dynamic2” subclient
  • Delete “db1” from “default” subclient
  • Add “db1” to “dynamic2” <--------------Fails here because Commvault think “db1” is still in “dynamic1” subclient

My question is why do we get a failure here because we sent API calls to ask Commvault server and got response the db1 database is in “default” subclient? And we have successfully delete the database from “default” subclient.

6 replies

Damian Andre
Rank
Userlevel 7
Badge +23

I’m curious at this step

Delete the “db1” from “sub1” subclient.
Add “db1” to “dynamic1” subclient


After this step can you confirm using the UI that it is gone from sub1, not in default and appears in dynamic1?

The default subclient behaves differently from all other subclients. I am not familiar with sybase, but in general, the default is a ‘catch all’ and by default includes all content not defined in other subclients. I see for sybase you can also disable this. If you are not using the default subclient, maybe try disable this option and see if it helps?

https://documentation.commvault.com/2022e/expert/22679_enabling_and_disabling_automatic_discovery_of_databases_to_default_subclient.html

More on default subclients for sybase:

https://documentation.commvault.com/2022e/expert/22674_managing_subclients.html

 

If that does not work I’d recommending opening up a case - its probably less about the Rest API logic and more about how content works with Sybase.

chrisknows
Rank
Userlevel 3
Badge +10

This doesn’t sound like if would work simply by virtue of the fact that it happens after the discovery phase. 
not familiar with the sybase agent but I suspect that reorganizing db layout mid backup would not be supported additionally im surprised it allows you to make any subclient changes at all while the backup is running. This method seems to be making assumptions about the way commvault works that simply isnt true.

 

it might be productive to take this up with your Tam or Personalization services.

shooting from the hip though this seems like an unnecessarily complex method of addressing whatever  your constraints are.

The poster formerly known as @christopherlecky
chrisknows
Rank
Userlevel 3
Badge +10

To elaborate on what on what @Damian Andre said the default subclient is what maintains coherency within the backup.

 

again I think are making assumptions about the way the product works.

The poster formerly known as @christopherlecky
C
Rank
Badge +1

I’m curious at this step

Delete the “db1” from “sub1” subclient.
Add “db1” to “dynamic1” subclient


After this step can you confirm using the UI that it is gone from sub1, not in default and appears in dynamic1?

The default subclient behaves differently from all other subclients. I am not familiar with sybase, but in general, the default is a ‘catch all’ and by default includes all content not defined in other subclients. I see for sybase you can also disable this. If you are not using the default subclient, maybe try disable this option and see if it helps?

https://documentation.commvault.com/2022e/expert/22679_enabling_and_disabling_automatic_discovery_of_databases_to_default_subclient.html

More on default subclients for sybase:

https://documentation.commvault.com/2022e/expert/22674_managing_subclients.html

 

If that does not work I’d recommending opening up a case - its probably less about the Rest API logic and more about how content works with Sybase.

Hi Damian, thanks for the response. It is hard to reproduce this issue manually. I am not able to use the concole to confirm this as it occasionally happens in the mid-night. Most of the time, it works as expected and consistent during development. However, when we deploy our software to production and start to use it, the error happens like above. We figured out this from our log file and found the in-consistency response from Commvault. Just curious why it is so we can change our code accordingly to make it working as expected.

 

If it is confirmed the issue is caused by auto-discovery, we will disable the auto-discovery of the instance for X minutes and keep resetting the timer until no other database housekeeping requests are received. 

 

C
Rank
Badge +1

This doesn’t sound like if would work simply by virtue of the fact that it happens after the discovery phase. 
not familiar with the sybase agent but I suspect that reorganizing db layout mid backup would not be supported additionally im surprised it allows you to make any subclient changes at all while the backup is running. This method seems to be making assumptions about the way commvault works that simply isnt true.

 

it might be productive to take this up with your Tam or Personalization services.

shooting from the hip though this seems like an unnecessarily complex method of addressing whatever  your constraints are.

Hi chris, thanks for the comments. We won’t execute housekeeping mid of the backup. We will wait till the backup finished and kick off the housekeeping. By “disable” backup, we disable the future scheduled jobs, rather than killing the current running backup job. I can see Commvault is not a simple software. The only thing we assume here is that it should be consistent with the API call responses.

christopherlecky
Rank
Userlevel 5
Badge +16

This doesn’t sound like if would work simply by virtue of the fact that it happens after the discovery phase. 
not familiar with the sybase agent but I suspect that reorganizing db layout mid backup would not be supported additionally im surprised it allows you to make any subclient changes at all while the backup is running. This method seems to be making assumptions about the way commvault works that simply isnt true.

 

it might be productive to take this up with your Tam or Personalization services.

shooting from the hip though this seems like an unnecessarily complex method of addressing whatever  your constraints are.

Hi chris, thanks for the comments. We won’t execute housekeeping mid of the backup. We will wait till the backup finished and kick off the housekeeping. By “disable” backup, we disable the future scheduled jobs, rather than killing the current running backup job. I can see Commvault is not a simple software. The only thing we assume here is that it should be consistent with the API call responses.

I think I misunderstood your earlier post, so I was wrong and right in a sense, as @Damian Andre pointed out the Default subclient does not work the way that you might imagine.

The default subclient exists to maintain coherency within the backupset.

That is by default the “default subclient” will “capture” the contents of the backupset not defined anywhere else.  Which means that whenever you define a subclient, the other databases will automatically be added to the default subclient.

The only way I can think of to get around this is to define exclusions as part of updating the sub clients.

That is have your add any DB on the server that you are not currently doing an operation on added to the “Do not backup” subclient, this is a hidden subclient that acts as an exclusion to the backupset.

Once again I think this is not the best way to go about this as commvault assumes certain things about the organization of the backupset and subclient. It may be prudent to talk to your tam about getting some advice from development as I am concerned that doing this would have an adverse effect on restorability. 

As a potential alternative solution ...

For the file-system agent they used to have something called dynamic subclient content that allowed to define subclient via a text tile on the client. I can’t find it on the documentation site, but it's there somewhere. 

It might sense for you to use the FS agent, in conjunction with this feature rather than making these changes. 

 

I don’t really have enough details to speak definitively but I think this kind of request requires an escalation to put you on the right track

 

I blame auto-correct for all misspellings, grammatical errors, and half-baked opinions.

Reply


Terms & ConditionsCookie settings