Data inconsistencies in SNP

Source: https://websmp230.sap-ag.de/sap%28bD1lbiZjPTAwMQ==%29/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361706E6F7465735F6E756D6265723D35373730333826

 

Symptom

There are inconsistencies in your system that can cause errors in interactive Supply Network Planning (SNP), SNP mass processing, and SNP data extraction. The system may issue the following error messages:

• E207(/SAPAPO/TSM) 'No liveCache anchor found.

• E020(/SAPAPO/OM_TS) 'Time series does not exist'

• E219(/SAPAPO/TSM) 'Invalid data status'

• E230(/SAPAPO/TSM) 'No plannable characteristics combinations available'

• E001(/SAPAPO/SDP_MD) 'Planning object could not be determined'

• E085(/SAPAPO/SDP) 'Error reading data - planning book cannot be processed'

Memory consumption in the liveCache increases disproportionately in relation to the master data volume.

Other Terms

/SAPAPO/TS_LCM_CONS_CHECK, /SAPAPO/TS_LCM_CONS_CHECK_ALL,
/SAPAPO/TS_LCM_REORG_SNP, /SAPAPO/TS_LCM_REORG

Reason and Prerequisites

SNP master data is created in the system for the APO master data. This enables navigation in SNP interactive planning. The SNP master data corresponds to the aggregates defined in the SNP planning area and is saved in the database tables.
           Aggregate Database table
           9AMALO /SAPAPO/MATLOC
           9AMALORE /SAPAPO/MATLORES
           9ALORE /SAPAPO/LOCRES
           9AMALA /SAPAPO/MATLANE
           9AMALARE /SAPAPO/MATLARES
           9AMAPR /SAPAPO/MATPPM
           9AMARE /SAPAPO/MATRES
           9AREPR /SAPAPO/RESPPM
           9AACPR /SAPAPO/ACTPPM
           9AMALOSA /SAPAPO/MALOSA
           9AMALASA /SAPAPO/MALASA

If you create master data in APO or change assignments, you must also create the missing SNP master data or time series. The SNP master data and the time series in the liveCache should normally be updated by the initialization of the planning version (and not by /SAPAPO/TS_LCM_CONS_CHECK).

These master data changes can lead to inconsistencies in one of the following situations:

• The version is not initialized, or the initialization job terminates.

• Jobs for changing the master data are terminated.

• This problem is due to a program error.

Solution

Initialize the planning version
Initialize a version that has already been initialized, without first deinitializing it and without changing the initialization period (delta initialization).

• For planning areas that do not have a time series key figure, it is sufficient to initialize one version.

• For planning areas with time series key figures, you must initialize each version.

Correct inconsistencies
If the inconsistencies were generated by a program termination or a program error, you can correct them using /SAPAPO/TS_LCM_CONS_CHECK.

Correct the cause of the error
If the inconsistencies were generated by a program error, it is necessary to find the cause of the error and remove it. To ensure that SAP Support can find the cause of the error, you need to provide an exact description of the process that resulted in errors:

• Which master data was changed and how?

• Was the planning version initialized?

• You can use the existing check programs to check the consistency of your data for each step: If you know which step led to the error, SAP can analyze your process with a view to providing a correction.

There are three check programs that you can use for consistency checks in SNP: /SAPAPO/TS_LCM_CONS_CHECK, /SAPAPO/TS_LCM_REORG_SNP and /SAPAPO/TS_LCM_REORG. You can execute the programs in repair mode by setting the "Repair" indicator. You should always block the planning version by setting the "Block planning version" indicator.

Check with /SAPAPO/TS_LCM_CONS_CHECK
This report checks the following for a version of a planning area:

• The consistency of the SNP master data.
  It checks for all characteristics combinations, whether master data exists (unnecessary characteristics combinations), and whether there is master data without SNP master data (missing characteristics combinations).
  Since the SNP master data is version-independent, you only need to execute the master data check for one version of the model.

• The liveCache anchors and time series in the liveCache.
  The report checks whether there are liveCache anchors and time series in the liveCache for the time series key figures for all characteristics combinations.
  If the 'Check liveCache anchor' indicator is set, the report checks whether the corresponding characteristics combinations exist for all liveCache anchors (only for DP planning areas).
  In the case of planning areas with time series, the time series must be checked for each version.

To correct the inconsistencies, you can execute the report in repair mode. For example, you can execute it before the planning run or after a mass change to master data to ensure a consistent status.

• If you have set the "Check SNP master data" indicator, the report creates the missing SNP master data in repair mode and deletes the unnecessary SNP master data. Since the SNP master data is version-independent, you only need to execute the master data check for one version of the model.

• If the planning area has time series key figures, the report deletes the liveCache anchors without SNP master data and the related time series in the liveCache in repair mode.

Check with /SAPAPO/TS_LCM_REORG_SNP
The report checks whether there is SNP master data for all liveCache anchors for a version of an SNP planning area. This check is required after you have deleted a large amount of master data.

To delete the superfluous liveCache anchors and the related time series in the liveCache, you can run the report in repair mode.

Check with /SAPAPO/TS_LCM_REORG
The report checks for a version for all DP and SNP planning areas whether there are liveCache anchors for all time series in the liveCache. This check is necessary if technical inconsistencies occur after a job was terminated.

To delete the unnecessary time series without liveCache anchors, you can run the report in repair mode.


Sequence of steps:
We recommend that you execute these program steps in the following sequence:

1. /SAPAPO/TS_LCM_CONS_CHECK
Since superfluous SNP master data is deleted, this program must be executed first.

2. /SAPAPO/TS_LCM_REORG_SNP
This program should be executed regularly for SNP planning areas with time series key figures after master data has been deleted in the system.

3. /SAPAPO/TS_LCM_REORG
This program should be executed after jobs are terminated to repair any technical inconsistencies in the liveCache.

Frequency of execution:
You should monitor the check programs over a sufficiently long period to estimate whether and when exactly they are required. Under normal circumstances, they should be used only to localize errors that create inconsistencies. You should execute the /SAPAPO/TS_LCM_CONS_CHECK program more often than the /SAPAPO/TS_LCM_REORG_SNP program and this more often than the /SAPAPO/TS_LCM_REORG program.

• /SAPAPO/TS_LCM_CONS_CHECK
  Since the SNP master data does not depend on either the planning area or the version, you only have to check the SNP master data for one version of the model. The consistency check is not required after the planning version has been initialized. In the normal process flow, the consistency check should not take place before the planning run, but it can be carried out weekly, for example.

• /SAPAPO/TS_LCM_REORG_SNP
  This program should be executed regularly after master data is deleted in the system. How often the program is executed depends on the quantity of deleted master data. You can always execute the program after a large quantity of master data is deleted, on a weekly basis, for example.

• /SAPAPO/TS_LCM_REORG
  This program should be executed monthly to check the consistency of the time series in the liveCache.

Header Data

Released On	05.06.2009 09:57:53
Release Status	Released for Customer
Component	SCM-APO-SNP-BF Basic Functions
Priority	Correction with medium priority
Category	Consulting

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

SAP Notes

1384831		9AMAPR inconsistencies for PDS in inactive version
1344612		Performance: Planning areas with time series key figures
1331576		Initialization and Delta Handling for SNP Master Data
1045639		Consulting notes in SNP/CTM
997456		Delta queues level 2 are not deleted
669287		Superfluous time series for SNP planning areas
402046		Error message 'No LiveCache anchor found'

This document is referenced by:

SAP Notes (6)

1045639		Consulting notes in SNP/CTM
1331576		Initialization and Delta Handling for SNP Master Data
1344612		Performance: Planning areas with time series key figures
1384831		9AMAPR inconsistencies for PDS in inactive version
997456		Delta queues level 2 are not deleted
669287		Superfluous time series for SNP planning areas

SAP SCM system Technical Resources

Resource	Location
Latest version of installation and update guides for SAP components	http://service.sap.com/instguides
General information about SAP SCM	http://service.sap.com/scm
SAP Business Maps – information about applications and business scenarios	http://service.sap.com/businessmaps
Sizing, calculation of hardware requirements – such as CPU, disk and memory resource – with the Quick Sizer tool	http://service.sap.com/quicksizer
Released platforms and technology-related topics such as maintenance strategies and language support	http://service.sap.com/platforms
Platform Availability Matrix	http://service.sap.com/pam
Information about network security – SAP Security Guides	http://service.sap.com/securityguide
Information about high availability	http://www.sdn.sap.com/irj/sdn/netweaver
Performance	http://service.sap.com/performance
Information about Support Package Stacks, latest software versions, and patch level requirements	http://service.sap.com/sp-stacks
Information about Unicode technology	http://www.sdn.sap.com/irj/sdn/i18n
Information about SAP Notes	http://service.sap.com/notes
Information about creating error messages	http://service.sap.com/message
SAP Software Distribution Center (software download and ordering of software)	http://service.sap.com/swdc
SAP Online Knowledge Products (OKPs) – role-specific Learning Maps	http://service.sap.com/rkt
Documentation on SAP Help Portal	http://help.sap.com

SAP APO and SAP liveCache's New Backup and Recoverability Features Bolster High-Performance Supply Chain Planning

by Jörg Hoffmeister, SAP AG, source: SAPInsider

Planning and decision-making for a company's supply chain - from determining when your supplier should send the next widget to creating a detailed, long-term production schedule - involves analyzing huge amounts of data from your own business processes and from the partners along your supply chain. In contrast to typical ERP data models, the demands on such planning systems require models designed to process vast amounts of data in near real time. Thus companies often find themselves in a data-processing dilemma: for any heavy-duty planning solution to achieve acceptable performance under these circumstances, processing must be done where the data is. To get another performance boost, processing must be done on main memory. The first paradigm omits extra network roundtrips, the second one avoids unnecessary disk access. And then, of course, efficient backup and recovery of this critical data is key. mySAP Supply Chain Management (mySAP SCM) offers a way out of this dilemma: SAP APO (SAP Advanced Planner and Optimizer) with SAP liveCache. SAP APO increases the speed of transactions for supply chain planning many times over. Now, with the newest version of SAP liveCache and SAP APO, SAP customers will continue to see high performance and availability, but they will also find simpler and more powerful tools for full point-of-failure recovery of planning data. High Performance and Unique Point-of-Failure Recovery SAP APO offers planning functionality for strategic, tactical, and operational planning of supply chains. Combined with SAP liveCache, it helps SAP customers respond to the data-processing challenges of supply chain planning. Designed to improve the flow of information, SAP APO offers real-time and collaborative decision processes, advanced planning, and optimization as part of the SAP system to cover long- and short-term planning issues, such as supply network planning, demand planning, and production planning. (For more information, see the article "Supply Chain Planning with mySAP SCM" in this issue of SAP Insider.) SAP APO pulls data out of your mySAP SCM solution and other applications and transforms and stores it to its own object- and network-based data model, with its own representation in its own database server. The system can either work off the SAP APO database server for more basic planning data, or off SAP liveCache for high-performance, high-memory planning issues. Application servers can also handle multiple connections to the different databases (see Figure 1), meaning that multiple processes and applications can connect simultaneously with different systems during the same session, and can work on data in either SAP liveCache or the SAP APO database server. Figure 1 Architecture of SAP APO Systems with SAP liveCache SAP liveCache is based on a memory-centric offshoot of the SAP DB technology (www.sapdb.org)1 shipped with SAP APO since Release 2.0. For the most resource-intensive planning questions, SAP APO pushes performance-critical application logic to SAP liveCache. The data required for those processes is also pushed to SAP liveCache, where it is kept persistent. The persistence of both the data and the application logic is a real benefit, since it allows different processes to work on the same data and avoids bottlenecks by following the paradigm "run the logic where the data is." SAP liveCache 7.4 Also Planned for SAP APO 3.0 SAP liveCache 7.4 is currently delivered with SAP APO 3.1, but a release is also planned for those customers using SAP APO 3.0. With this scenario, the application logging that customers currently have in place in APO 3.0 will be switched off; logging will be performed by SAP liveCache 7.4 only. To migrate to 7.4, the current SAP liveCache data will be saved back into the SAP APO database. After SAP liveCache is upgraded, that data will be reloaded. For more information on release and availability, SAP users can log on tohttp://service.sap.com/scmand go to mySAP SCM Technology -->Backup and Recovery. SAP liveCache and SAP APO's New Approach to Backup and Recovery With such critical business data, backup and recovery is always a concern. SAP liveCache's self-sufficiency in backup and point-of-failure recovery is one of the unique features that separates SAP APO from its competitors. Until recently, SAP APO handled recovery through logging on the application level, together with switching log areas and SAP liveCache checkpointing. This required complex synchronization of processes during any restart of SAP APO and SAP liveCache, and involved special treatment to recognize the point where users could return to their work. Furthermore, there was potential for slow-downs at the SAP liveCache checkpoints during normal operation. In the latest release of SAP liveCache (7.4) delivered with SAP APO 3.1, administrators now have a simpler solution: new, encapsulated logging and recovery capabilities for the persistent data in SAP liveCache. In fact, the applications no longer have to deal with logging and recovery procedures at all. Although the SAP APO and SAP liveCache databases are independent, they are designed to ensure the consistency of data and transactions. Any open SAP APO transactions whose modifications have been rolled back during an SAP liveCache restart will receive a return code, and will be undone by the application and thus the SAP APO database. Likewise, SAP APO cannot execute procedures on SAP liveCache data while SAP liveCache is unavailable, so this ensures consistency between the SAP APO core system and SAP liveCache when it comes to transactions. Unlike earlier implementations, users can now go on with their work as soon as SAP liveCache is up and running again, and recovery time is significantly decreased. With backup and recovery moved away from the applications, administration functions for SAP liveCache are available right within SAP liveCache's own Database Manager tool. Figure 2 shows the backup process displayed in the Database Manager, which provides support for backup and user guidance during recovery, and maintains media definitions, protocols, and backup history.2 (Note that external backup tools are also an option, but be sure to check any third-party tool's documentation regarding compatibility with SAP liveCache's administration functions.) Figure 2 New Recovery Functions in the Database Manager In Figure 2, the administrator sees SAP liveCache's default recovery route, recommended for optimal performance: a complete data backup is restored (DAT_00001), followed by an additional incremental backup (PAG_00002) for recovery, followed by a log backup (LOG_00008). During log recovery, SAP liveCache will switch from the log backup to its own log volume as soon as it reaches a log page in the backup that is also available in the log volume. Now, administrators can customize the backup process in the Database Manager. For example, the administrator could choose an alternative recovery strategy, based on log backups only, by checking "LOG_00003." The tool would then mark all logs for recovery and omit the incremental backup. SAP liveCache - The Technology As the price of memory chips decreases while performance increases, the driving forces behind SAP liveCache - high availability and increased performance and persistence - have become even more accessible to SAP customers. With these hardware innovations and SAP liveCache technology, data can primarily be processed in main memory, and normally does not have to be moved between the disk and memory during transactional processing. As a result, supply chain management and planning applications can hit even higher performance targets. For example, moving a typical set of data from SAP liveCache to the application server for processing (see figure, top right) would take at least 1 millisecond (A), compared with the microseconds it would take if processed inside SAP liveCache (B). Processing of Data with the SAP liveCache Approach SAP liveCache depends on the enhanced use of stored procedures for persistent stores of C++ class instances. It is designed to speed up processing by dynamically linking application code (in C++) directly to the database kernel code during runtime. As a result, the stored procedures are executed directly in the SAP liveCache address space without switching back and forth to the application server. The application data is completely available in main memory and will only be written to disk to achieve the requisites for recovery and thus persistency. This has no impact on performance because SAP liveCache is supplied with a highly efficient asynchronous I/O system. Call to SAP liveCache from the Application Server Consider a stored procedure call to SAP liveCache (see figure, bottom right). In this case, SAP APO is looking to schedule an order via SAP liveCache. The call is performed from the ABAP code layer of an SAP APO application. The procedure "schedule_order" is identified in the code by name; a stored C++ procedure with the same name has been registered to SAP liveCache during startup. An ABAP call will be bound to an SAP liveCache session. When the call occurs, that session runs as a task within a thread. Then, within SAP liveCache, the Object Management System (OMS) within SAP liveCache locates the "schedule_order" procedure code in the external C++ library. Then the OMS adapts the parameters of "schedule_order" to match its own object and network structures. This C++ procedure is executed directly inside the SAP liveCache kernel address space, using the OMS class interface of SAP liveCache. From there, the processing returns to the application server. Conclusion By providing a powerful interface to achieve persistence together with a stored procedure model, SAP liveCache solves the data-processing dilemma. For your most resource-intensive planning problems, the application can "run where the data is" - within SAP liveCache - with a minimized number of roundtrips and disk I/O, and a powerful backup and recovery concept to safeguard your supply chain planning data and keep your planning processes running smoothly. SAP APO is unique in its use of this SAP liveCache technology, which means that users and administrators reap the benefits: high performance, high availability, and simplified, reliable backup and recovery. SAP liveCache is currently available on Tru64, the 64-bit versions of Solaris, HP-UX, and AIX and Windows Server. SAP liveCache on Windows 2000 also supports AWE. A general release for .NET Server3 is planned for liveCache 7.4 in 2003. For more information on SAP APO and SAP liveCache 7.4, registered SAP customers can visit the mySAP SCM Technology section at http://service.sap.com/scm. For more on SAP DB technology, on which liveCache is based, visit www.sapdb.org. 1 For more on SAP DB, see "SAP DB, SAP's Open Source RDBMS: Free, Scalable Database Management" in SAP Insider (October-December 2001). 2 The Database Manager is designed as a client/server application and provides a batch interface as well. The user interface is a Windows interface or, for non-Windows platforms, it is a browser-based interface with nearly the same functionality. All interfaces are clients that communicate with the Database Manager server, which runs as an independent program on the same server as the SAP liveCache kernel. 3 Synonymous with Windows IA64.