Skip to Content

This article explains the use of “Activate Livecache lock” in a custom SNP planning area.

Background


We faced below issue after APO upgrade from version 7.0 to version 7EHP2. A number of SNP copy  jobs  /SAPAPO/RTSCOPY  started failing . SAP informed that locking logic has been improved for SNP (note  1318667 – Incorrect lock entry for SNP aggregate 9AMALO). In our case the note got implemented as a part of the upgrade and after upgrade jobs in our quality system  failed with message “Lock table overflow”.

FAILURE.png

The number of locks in SM12 are controlled by profile parameter  enque/table_size.This is maintained by BASIS team. The parameter value shouldn’t be increased beyond a certain limit.

/wp-content/uploads/2016/03/rz10_907658.png

Possible solutions to this problem can be

1. To limit the selection of copy. Each large step has to be replaced with smaller selection steps . This can lead to more maintenance issue as the selections need to be updated regularly.

2 Use a macro to copy – If the system has large number of time series KF  then a unique macro needs to be created for each copy. Macro will have more run time.

3 Use the “Activate LC lock “option for the custom SNP planning area.This option was implemented and details are below.

Consider a Custom planning area with three time-series KF as shown below.

Case 1 : “Activate livecache lock” is unchecked.

/SAPAPO/RTSCOPY was run with below selection.

SM12  shows a very large number of locks . This is a representative screen shot and in our actual test the job failed with table overflow.

Case 2 :”Activate livecache lock” is checked.

SM12 locks show only one entry with reference to LCA_GUID_STR .

Report  /SAPAPO/TS_LC_DISPLAY_LOCKS   shows the below and more information is visible in the details button.

SAP note :1988958 ( Data is locked: How to find out locked planning objects when using liveCache locking logic) explains the above report.

If the planning area has inconsistency then the report fails with the below message . Same can fixed by running consistency reports and OM17.

The change in locking logic of planning area can have huge impact and must be tested thoroughly. Some of the scenario which we tested are :

  1. Same selections + Same planning version : Locking logic is working as expected  and second occurrence is locked out . The first user was in change      mode and second user got “selection locked” message.
  2. Same selection + Different version : No Locking  message for 2ned user as expected
  3. Different selection + Same version : No Locking message  for 3 users as expected.

Conclusion: “Activate Livecache lock” is a good option for SNP planning area  and will prevent table overflow error.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. ARAVA SANTOSH KUMAR

    Hi Radhakrishna;

    Please try to execute the program /SAPAPO/TS_LCM_REORG_SNP. Mostly your up gradation issues coming due to PA locks at database level. The problem can be stated to the Basis team and they can try to clear with DB lock entries which is causing the Lock table overflow. Some times it also throws the error stack overflow in your scenario.

    Regards;

    AravaSantosh 

    (0) 
    1. Radhakrishnan G K Post author

      Hi Santosh

      To my knowledge , very few projects actually use this option for SNP planning area. In my case we have 20 SNP versions and  10 time series KF . We had large number of copy steps which copied  time series KF from one version to another .All these copy steps started failing with table overflow message. SAP suggested us to use LiveCache locking option and it solved our problem. I believe this option is good and worth trying. Extensive testing is needed in any case.

      (0) 

Leave a Reply