BPC 10.0 Light optimization failing intermittently

[Former Member]

Hi Experts,

Need your help/guidance on this issue. We are using BPC 10.0 NW

We have scheduled light optimization every night. It is failing Intermittently at "Plan Mode On" step after Collapse step. PFA attached screen shot.

As it is failing intermittently, we are not able to find out the root cause of it. Interestingly there is no logs in ST22.

We found SAP note “1632608 - Lite Optimize in BPC NW fails on the 'Plan Mode On' variant step. However which did not help us.

Would be really good if someone share some insight. Thanks.

[Former Member]

Hi Leila and Vadim,

Thank you for your replies.

Vadim : Yes, as you suggested we are thinking to reschedule the Light Optimization with more time difference among schedules.

Leila : We got the issue today as well with one schedule. There are not dumps in ST22. However I could see logs in SM37. But not sure what to look after seeing these errors. PFA screen shot of the error and logs.

Currently rdisp/max_wprun_time values is set to 600. But not sure if it really need to be increased. It should create any other issues.

If you could get any insight after seeing screen shots would be really helpful. Thanks.

[Former Member]

Compression or Light Optimization of one Model does not affect any other Models.

This error message says that you have a "yellow" request in the cube. Can you please check if that is true? If you have such request then most probably somebody posted some records in that cube after LO started. You can try to find who that was by looking at records in that yellow request.

If you don't have a yellow request in the cube when LO fails than it's a bug and you have to open an OSS Incident.

[Former Member]

Hi Gresh,

Thank you for your reply.

"Compression or Light Optimization of one Model does not affect any other Models"

Do you mean this, One LO for one Model does not affect another LO of another model and we could schedule those irrespective of time difference?

Yes, we found Yellow request when it fails. What we do in that situation, we manually change the request from Yellow to Green and then change the loading behavior of the Cube manually.

Could you please provide details, how could we check in Yellow request about entered records and who entered that?

Thanks.

[Former Member]

Yes, I meant that all LOs can start at same time. I only saw issues with that when BIA was used, but I hope nobody has them any longer. And this was due to BIA throughput, not dependency.

You can see what records are in the yellow request if you go to Manage of the cube or t/a LISTCUBE.

You have to select request number from the Manage screen and put in Selection conditions. There are 2 representations of that request number: long - APO_... and short - numeric.

You can see how many records are in that request if you go to the F... table and put numeric request number as a selection. You can see all records in that request in Cube content or LISTCUBE.

[damovand]

Hello,

I recommend checking what else is running in BPC.  As you noted this is difficult to troubleshoot.  You might have to figure out a specific schedule for running optimization when no one else is in the system.

Best Regards,

Leila

[Former Member]

Hi Leila,

Thank you.

We have scheduled 3 light optimization for 3 different models at different time i.e. 2.00 am, 2.10 am and 3.00 am in the nights.

What we analyzed is that, one of the steps in the process chain i.e. ‘Planning Mode On’ variant is in Red. It is happening because request  doesn’t go from Yellow to Green and eventually loading behavior doesn’t change. In process chain logs it is showing  ‘Planning Mode On’ variant as Red. And no dumps in ST22.

I have gone through some blogs and found that many mentioned about "rdisp/max_wprun_time" settings in RZ 10/11. I checked that setting on Server and it is set to 600.

Is it something we need ask Basis to increase? Would it really help?

Thanks

[damovand]

Hello,

If you suspect that the optimization process needs more time than allocated then I recommend increasing the value of that parameter. That will of course depend on the exact error that you are getting.  Since there is no ST22 you might want to check SM21 or SM37 for more detailed errors.

On further consideration, if increasing the value of max_wprun_time  does not adversely affect the processes running during business hours then you should increase it and evaluate if that resolves the issue.

Best Regards,

Leila

[former_member186338]

Don't you think the times can overlap? "different time i.e. 2.00 am, 2.10 am and 3.00 am"

Vadim