LiveCache locking for SNP planning area
This article explains the use of “Activate Livecache lock” in a custom SNP planning area.
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”.
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.
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 :
- 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.
- Same selection + Different version : No Locking message for 2ned user as expected
- 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.
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.
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.