Skip to main content
commvault.com commvault.com
Solved

plan rules are not working for database agents

M
Byte
Forum|alt.badge.img+7

Hi together,

due to the necessary transition from Storage-Policy/Schedule-Policy to Plans, we are looking for a method to do bulk changes to the configuration (400x HANA, 500x Oracle, 100x Postgres ...).

When we are using plan rules this seems to work, but in fact it does not. The plan rule is changing only the assignment for the subclient and not for the database instance.

Example: Plan rule for Postgres should assign a derived plan

The subclient is changed to the Derived Plan, the instance is not (completely) changed; here you find the Base-Plan that is “mentioned (sorry for this term, but configured would not be appropriate)” and the instance is listed as “not ready”.

Qcommands (and therefore workflow) seem to have no interface to assign plans. 

So my question: How can I do a bulk change for database agents and assign a derived plan to the Subclient and the database instance?

Thank you.

Michael

Best answer by Sunil

Hi ​@Michael Seickert 

Thanks for your time over the call. As we observed, the plan rules when the default subclient is involved, are updating the instance level plan.

 

In addition, below is the plan update XML payload you can use to update plan of multiple subclients at once using CLI. Replace the subclientIDs in your request with correct ids.

 

qoperation execute -af </path/to/request.xml>

> cat request.xml

<App_UpdateSubClientPropertiesRequest>
<subClientProperties>
<planEntity planId="1211"/>
</subClientProperties>
<association>
<entity _type_="7" subclientId="1433"/>
</association>
<association>
<entity _type_="7" subclientId="1435"/>
</association>
<association>
<entity _type_="7" subclientId="1453"/>
</association>

 

Thanks,

Sunil & Arvind

 

​@Arvind Lakra 

View original
Did this answer your question?

21 replies

Meera
Vaulter
Forum|alt.badge.img+7
  • MeeraVaulter
  • Vaulter
  • 70 replies
  • February 4, 2025

Hi Michael,

There is an app for converting storage policies to plans. Please visit 

Converting CommCell Console Storage Policies to Command Center Server Plans or Laptop Plans for more details.

 

Regards,

Meera

Meera
M
Byte
Forum|alt.badge.img+7
Meera wrote:

Hi Michael,

There is an app for converting storage policies to plans. Please visit 

Converting CommCell Console Storage Policies to Command Center Server Plans or Laptop Plans for more details.

 

Regards,

Meera

Hi Meera,

Thank you for your suggestion but I think, this won’t help. The App is creating the Plans … but we already have plans. (The new plans differ from the old storage polices due to governance reasons).

We need a solution to assign (new) plans to existing database workloads.

Regards.

Michael

 

Sunil
Vaulter
Forum|alt.badge.img+13
  • SunilVaulter
  • Vaulter
  • 300 replies
  • February 4, 2025

Hi ​@Michael Seickert ,

Looks like the plan rule is not setting the plan association at the instance level. Ideally the subclients should work as expected per associated plan, However, if we need to see the associated plan at the instance level, only option right now is to assign at the instance level by qoperation execute with UpdateInstance XML specifying the new plan.

 

Thanks,

Sunil-

 

 

M
Byte
Forum|alt.badge.img+7
Sunil wrote:

Hi Sunil,

yes, you are right; we need an associated plan at instance level. Can you provide an UpdateInstance XML?

Thanks,

Michael

 

 

 

Onno van den Berg
Commvault Certified Expert
Forum|alt.badge.img+19

Hi ​@Sunil,

Sounds like an oversight to me that was missed during the development of this capability. I do hope this will be addressed in the very near future. I also thought plan rules only work once meaning when you change the rule definition that it will not re-attach the affected instances to the new plan. Is this correct and if so are there plans to adjust this so plan rules become more dynamic? I also think it should have a capability that shows you the outcome of the plan rule and preferably also a capability that allows you to identify clients who are connected to the defined plan.

 

M
Byte
Forum|alt.badge.img+7

Hi Onno,

I agree. This feature is missing in the plan rule … and a plan rule history (which subcleint has been re-assigned) would be good too.

Yes, plan rules work only once. Fire and forget :-) … If you change the rule it is starting at zero and will not reattach those subclients that are already re-assigned.

It would be very good to have the capability to go to the plan → assign instance/subclient and to select the objects that should be re-assigned (comprae with schedule policy → assign).

Can you forward these kind of requests to the development?

Regards.

Michael

 

 

Onno van den Berg
Commvault Certified Expert
Forum|alt.badge.img+19

I might have created the required CMRs for them already, so I will check it out. 

Sunil
Vaulter
Forum|alt.badge.img+13
  • SunilVaulter
  • Vaulter
  • 300 replies
  • February 6, 2025
Onno van den Berg wrote:

Hi ​@Sunil,

Sounds like an oversight to me that was missed during the development of this capability. I do hope this will be addressed in the very near future. I also thought plan rules only work once meaning when you change the rule definition that it will not re-attach the affected instances to the new plan. Is this correct and if so are there plans to adjust this so plan rules become more dynamic? I also think it should have a capability that shows you the outcome of the plan rule and preferably also a capability that allows you to identify clients who are connected to the defined plan.

 

Hi ​@Onno van den Berg ,

We checked internally and verified that the instance level plan gets updated when default subclient is updated. If the plan rule includes all subclients under that instance, which supposedly include default subclient as wel, we should see the plan association getting updated at instance level also.

 

Hi ​@Michael Seickert ,

Please let me know if this is not the case with you.

 

Thanks,

Sunil-

Meera
1 person likes this
  • Meera
    Meera
M
Byte
Forum|alt.badge.img+7

Hi Onno,

thank you for your feedback.

we will check this on Monday.

Regards.

Michael

M
Byte
Forum|alt.badge.img+7

Hi Onno,

I checked this for Postgres with 11.34.41.

I can confirm that the default subclient is visible twice in the waiting room for a DERIVED PLAN after the storage-policy had been disassociated.

I can confirm that the DERIVED PLAN is set for the default subclient by the plan rule.

I can confirm that the BASE PLAN is assigned to the postgres instance by the plan rule. This is done in a way that suggests that a storage-policy has been assigned (it is no link to the plan in the Command Center). The instance is not configured properly. When I change the configuration of the instance manually to the DERVICED PLAN this is shown as a link to the plan in Command Center.

Regards.

Michael

Sunil
Vaulter
Forum|alt.badge.img+13
  • SunilVaulter
  • Vaulter
  • 300 replies
  • February 7, 2025
Michael Seickert wrote:

Hi Onno,

I checked this for Postgres with 11.34.41.

I can confirm that the default subclient is visible twice in the waiting room for a DERIVED PLAN after the storage-policy had been disassociated.

I can confirm that the DERIVED PLAN is set for the default subclient by the plan rule.

I can confirm that the BASE PLAN is assigned to the postgres instance by the plan rule. This is done in a way that suggests that a storage-policy has been assigned (it is no link to the plan in the Command Center). The instance is not configured properly. When I change the configuration of the instance manually to the DERVICED PLAN this is shown as a link to the plan in Command Center.

Regards.

Michael

​@Michael Seickert 

We would like to better understand the scenario here. Please let us know if you are available for a call to go through it with you.

 

Thanks,

Sunil

M
Byte
Forum|alt.badge.img+7
Sunil wrote:
Michael Seickert wrote:

Hi Onno,

I checked this for Postgres with 11.34.41.

I can confirm that the default subclient is visible twice in the waiting room for a DERIVED PLAN after the storage-policy had been disassociated.

I can confirm that the DERIVED PLAN is set for the default subclient by the plan rule.

I can confirm that the BASE PLAN is assigned to the postgres instance by the plan rule. This is done in a way that suggests that a storage-policy has been assigned (it is no link to the plan in the Command Center). The instance is not configured properly. When I change the configuration of the instance manually to the DERVICED PLAN this is shown as a link to the plan in Command Center.

Regards.

Michael

​@Michael Seickert 

We would like to better understand the scenario here. Please let us know if you are available for a call to go through it with you.

 

Thanks,

Sunil

Hi Sunil,

 

thank you for this opportunity. I would be available next Wednesday 19.2. (13:00-16:00 German Time) or Monday 24.2. (9:00 - 16:00 German time). Would this fit to you time table?

 

Regards.

Michael

M
Byte
Forum|alt.badge.img+7
Michael Seickert wrote:

Hi Onno,

I checked this for Postgres with 11.34.41.

I can confirm that the default subclient is visible twice in the waiting room for a DERIVED PLAN after the storage-policy had been disassociated.

I can confirm that the DERIVED PLAN is set for the default subclient by the plan rule.

I can confirm that the BASE PLAN is assigned to the postgres instance by the plan rule. This is done in a way that suggests that a storage-policy has been assigned (it is no link to the plan in the Command Center). The instance is not configured properly. When I change the configuration of the instance manually to the DERVICED PLAN this is shown as a link to the plan in Command Center.

Regards.

Michael

Hi Onno,

I checked this with an Oracle Database. In the waiting room I can see the default subclient, but the Plan is not assigned to the instance.

Regards.

Michael

Onno van den Berg
Commvault Certified Expert
Forum|alt.badge.img+19
  • Onno van den BergCommvault Certified Expert
  • Commvault Certified Expert
  • 1227 replies
  • February 10, 2025

Hi ​@Michael Seickert I do not work for Commvault. I'm just a consumer, just like you ;-) I think you should target ​@Sunil.

 

Sunil
M
2 people like this
  • Sunil
    Sunil
  • M
    Michael Seickert
M
Byte
Forum|alt.badge.img+7
Onno van den Berg wrote:

Hi ​@Michael Seickert I do not work for Commvault. I'm just a consumer, just like you ;-) I think you should target ​@Sunil.

 

I asked Sunil, but I used some “words” that are banned by the Community-Interface. Not sure if me message will reach Sunil.

 

Regards.

 

Michael

M
Byte
Forum|alt.badge.img+7
Sunil wrote:
Michael Seickert wrote:

Hi Onno,

I checked this for Postgres with 11.34.41.

I can confirm that the default subclient is visible twice in the waiting room for a DERIVED PLAN after the storage-policy had been disassociated.

I can confirm that the DERIVED PLAN is set for the default subclient by the plan rule.

I can confirm that the BASE PLAN is assigned to the postgres instance by the plan rule. This is done in a way that suggests that a storage-policy has been assigned (it is no link to the plan in the Command Center). The instance is not configured properly. When I change the configuration of the instance manually to the DERVICED PLAN this is shown as a link to the plan in Command Center.

Regards.

Michael

​@Michael Seickert 

We would like to better understand the scenario here. Please let us know if you are available for a call to go through it with you.

 

Thanks,

Sunil

Hi Sunil, yes we can make a call. Thank you.

Regards. Michael

Sunil
Vaulter
Forum|alt.badge.img+13
  • SunilVaulter
  • Vaulter
  • 300 replies
  • February 10, 2025
Michael Seickert wrote:
Sunil wrote:
Michael Seickert wrote:

Hi Onno,

I checked this for Postgres with 11.34.41.

I can confirm that the default subclient is visible twice in the waiting room for a DERIVED PLAN after the storage-policy had been disassociated.

I can confirm that the DERIVED PLAN is set for the default subclient by the plan rule.

I can confirm that the BASE PLAN is assigned to the postgres instance by the plan rule. This is done in a way that suggests that a storage-policy has been assigned (it is no link to the plan in the Command Center). The instance is not configured properly. When I change the configuration of the instance manually to the DERVICED PLAN this is shown as a link to the plan in Command Center.

Regards.

Michael

​@Michael Seickert 

We would like to better understand the scenario here. Please let us know if you are available for a call to go through it with you.

 

Thanks,

Sunil

Hi Sunil, yes we can make a call. Thank you.

Regards. Michael

​@Michael Seickert ,

Please let me know of a convenient time for you. I and my colleague from Plans team will connect.

 

Thanks,

Sunil-

M
Byte
Forum|alt.badge.img+7

HI Sunil,

 

sorry for answering late. I am available for a call next week on Tuesday afternoon (25.2.) or Wednesday afternoon (26.2.) … German Timezone (MET).

 

Regards. Michael 

Sunil
Vaulter
Forum|alt.badge.img+13
  • SunilVaulter
  • Vaulter
  • 300 replies
  • February 21, 2025
Michael Seickert wrote:

HI Sunil,

 

sorry for answering late. I am available for a call next week on Tuesday afternoon (25.2.) or Wednesday afternoon (26.2.) … German Timezone (MET).

 

Regards. Michael 

Hi Michael, Please check your DM and let me know.

Sunil
Vaulter
Forum|alt.badge.img+13
  • SunilVaulter
  • Vaulter
  • 300 replies
  • Answer
  • February 25, 2025

Hi ​@Michael Seickert 

Thanks for your time over the call. As we observed, the plan rules when the default subclient is involved, are updating the instance level plan.

 

In addition, below is the plan update XML payload you can use to update plan of multiple subclients at once using CLI. Replace the subclientIDs in your request with correct ids.

 

qoperation execute -af </path/to/request.xml>

> cat request.xml

<App_UpdateSubClientPropertiesRequest>
<subClientProperties>
<planEntity planId="1211"/>
</subClientProperties>
<association>
<entity _type_="7" subclientId="1433"/>
</association>
<association>
<entity _type_="7" subclientId="1435"/>
</association>
<association>
<entity _type_="7" subclientId="1453"/>
</association>

 

Thanks,

Sunil & Arvind

 

​@Arvind Lakra 

Damian Andre
Meera
M
3 people like this
  • Damian Andre
    Damian Andre
  • Meera
    Meera
  • M
    Michael Seickert
M
Byte
Forum|alt.badge.img+7

Hi Arvind,

thank you for the conf-call yesterday.

My summary:

  • Postgres: Assign the plan to the dump-based backupset and the FSbasedBackupset
  • Oracle: Assigning the plan via plan rules is working properly. I have to refresh the command center output via the refresh button.

Thank you for your help.

Regards.

Michael

 

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings