SCM Planning Solutions IBP APO Ariba: Note 429422 - SAP APO System Requirements for multiple Planning Versions

Summary

Symptom

This SAP Note describes how to optimize your liveCache Main Memory
Requirements when using multiple SAP APO Planning Versions
and especially how to enter the correct amount of Planning Versions
in the Quicksizer in oder to obtain realistic main memory
requirements for the SAP liveCache.

Other terms

Multiple Planning Versions, DP, SNP, PP/DS, liveCache, requirements,
main memory, swap, performance, sizing, hardware resources, Demand
Planning, Supply Network Planning, Planning Versions

Reason and Prerequisites

You use multiple Planning Versions and want to optimize your Main
Memory requirements for the SAP liveCache.

Solution

---------------
Introduction
---------------

Multiple Planning versions held in the SAP liveCache Main
Memory have a linear multiplicator effect for the required amount of
liveCache Main Memory in the Quicksizer.
However, there are different ways to reduce your SAP
liveCache Main Memory requirements due to the amount of versions.
Furthermore, you must enter the correct amount of Planning versions
in the Quicksizer, so that the resulting memory requirements are
realistic. Please, note that if you enter "n" Planning Versions, the
Quicksizer will assume that these Planning Versions are all used at the
same time and that all Versions have the same size : This is usually
not the case.

A possible way to optimize main memory requirements due to the amount
of planning versions, is, for example, optimizing version copy
procedures.
Please, see more details below.

-----------------------------------------------------
1. Optimization of liveCache Main Memory Requirements
-----------------------------------------------------

----------------------------
1.1 SAP APO Demand Planning
----------------------------

In case of SAP APO Demand Planning, if you store few versions
in liveCache Main Memory and keep the rest on the BW Info Cube on the
SAP APO Database, you can optimize your main memory requirements for
SAP liveCache.
This recommendation can be important if your SAP liveCache Main
Memory Requirements are high independently of the amount of versions,
that is, if you plan with a high amount of characteristic
combinations, key figures, etc.
However, for performance reasons, this alternative is
only recommended if your SAP liveCache main memory requirements are
much higher than the available memory addressing capabilities of
your liveCache server, for example, if you are using SAP liveCache
on a 32-Bit Windows Server.
Please, also note that some Demand Planning Versions may only be
required for reporting purposes in form of BW Info Cube Backups on
the SAP APO Database and not necessarily in the SAP liveCache main
memory : In such cases it is correct to enter this amount of Planning
Versions in the Quicksizer as "Amount of Demand Planning Versions in
the BW Info Cube" and NOT as "Amount of Demand Planning Versions in
the liveCache".

------------------------------------
1.2 Planning Version Copy Procedures
------------------------------------

Not all SAP APO users need copies of 100 % of the objects
for a Planning Version. You can avoid the copy of unnecessary data
and reduce your memory requirements by using the following approach
when copying versions for DP, SNP or PP/DS :
a) The central transaction for administration of versions and models
is /sapapo/mvm. This version will allow you to create and copy versions
restricting the amount of data to be stored in the version.
b) For time series data, you can also use transaction /sapapo/tscopy
which is more effective than /sapapo/vercop because it offers you the
choice to select which data area is going to be copied. If you take
advantage of the selective capabilities of /sapapo/tscopy for Time
Series, the result will be similar as if you had performed a 50 %
version copy.
c) Transaction /sapapo/vercop is recommended to be used only with Order
data and not with Time Series data : Please, do not check the Time
Series box when using /sapapo/vercop.

Please, note that liveCache processes planning data in basically two
ways depending on the kind of planning concept in use :
a) If planning is based on time buckets processing, like for DP,
the so called Time Series liveCache will be used.
b) If planning is based on order (sales orders, stock orders, etc.)
processing, like for SNP or PP/DS, the so called Order liveCache will
be used.

SAP Notes about Model and Version Management for SAP APO are available
in the component APO-MD-VM.
You can also check the size of your planning versions with
/SAPAPO/OM16 : See SAP Note 431299 for details.

--------------------------------------------------------------------
2. Tips & Tricks : How to enter the "right" data in the Quicksizer ?
--------------------------------------------------------------------

Especially for global customers with several business units, multiple
users may work with multiple versions and/or copies of SAP APO DP, SNP
and PP/DS versions.
However, in general, not all versions will be used at the same time and
not all versions are equally big in size.

1) You can get a first approximation about the system requirements for
your SAP APO by using the Quicksizer for SAP APO in :
http://service.sap.com/quicksizer

Currently, the SAP APO quicksizer is available for DP, SNP, PP/DS, ATP
and CIF. The results of the quicksizer are optimized for mass
processing (batch planning) rather than for interactive planning.
However, overhead CPU resources for interactive planning are also
given based on the amount of concurrent users.
Please, ask your hardware
Partner to perform the sizing of your SAP APO and/or to review your
your quicksizer results. SAP is also available for final reviews in the
framework of the different Service offerings.
It is also strongly recommended that you perform mass/volume tests
before going productive. In this way you will be able to check
if all performance settings and sizing assumptions are adequated
for your productive system.

The quicksizer questionnaire will ask you, among others, your planned
amount of characteristic combinations, key figures, time buckets,
sales orders, stock orders, purchase orders and planning versions
for DP, SNP and PP/DS. Some of these business figures, say, the
amount of Characteristics Combinations, Key figures,
Orders, that is, transactional data, Planning Versions, etc. have a
significant influence on the resulting main memory requirements for
liveCache. On the contrary, Master Data has a small influence on
the liveCache Main Memory Requirements.
If the figures entered in the Quicksizer are not accurate and do not
correspond to your business process reality, the resulting System
Requirements will also not be correct.
For example :
Please, take into account that the SAP APO sizing relevant amount
of characteristic combinations is NOT necessarily the mathematic
product of all your customers, locations, products, etc. :
Not all mathematic combinations may be relevant for your Demand
Planning run. A lower amount of characteristic combinations will
require less SAP liveCache Main Memory.
The same is valid for the key figures. For your SAP APO sizing, please
consider only the amount of key figures which will be relevant for
your Demand Planning run. In this way you will obtain realistic
liveCache Main Memory requirements.

Furhermore, some particular quicksizer figures such as Planning
Versions have a multiplicator effect on the resulting liveCache main
memory requirements.

If you type "n" versions, the quicksizer will
assume that these versions are used in parallel and have all exactly
the same size, that is, the maximum size which is associated to your
active version and which comes from all the figures you entered in the
quicksizer (maximum amount of characteristic combinations, key figures,
buckets, orders ...).
However, planners will define their own versions for their needs.
These may contain less orders than the active version, less master
data, and be therefore much smaller in size than the active version.
Therefore, the figure you have to enter in the quicksizer as amount
of planning versions must take this into account.
Example :
You plan to use 25 SNP versions presumably in parallel. 3 of these
versions are 100 % copies of the active version, 8 versions are
supposed to contain only 50 percent of the amount of orders of the
active version, 14 versions are planned to contain only 10 % of the
orders stored in the active version. Then, the figure you should enter
in the quicksizer must not be bigger than :
3 + 50% x 8 + 10% x 14 = 3 + 4 + 2 = 9
If you enter 9 versions, the quicksizer will give as result the
required amount of main memory to hold 9 versions in main memory.
However, SAP liveCache may not need to hold all 9 versions in main
memory at the same time.

2) You do not need to size your SAP APO so that all versions can be
held in Main Memory at the same time. Versions which cannot
be held on liveCache Main Memory will be swapped to the SAP liveCache
devspaces. Swapping is performed by the liveCache management system
automatically on a page level, the size of a Page being 8 KByte.
The liveCache swapping strategy is based on LRU (Last recently used),
as for all standard RDBMS.
liveCache keeps those 8KB-pages which are used most often in main
memory and swaps the rest of pages to disk. Eventually, the performance
may be reduced if there is not enough liveCache Main Memory available
to keep all versions which are often in use.
In some cases, the active Version may be swapped to disk if users
are running jobs which often require pages from non-active versions.
This should be avoided : Goal is to keep the pages belonging to the
active planning version in Main Memory.
Example :
Even if you use 9 versions presumably in parallel, not all concurrent
users will use the 9 versions exactly at the same time. The more
frequently used versions will be held in main memory, say, 3, and the
rest will alternately be swapped to disk until they are again needed.
That is, you may enter only 3 Planning versions in the Quicksizer and
not 9.
Please, also note the following.
Let's assume that your company has 2 Business Units working on one
central SAP APO. One Business Unit is located in the USA and the other
one in Europe. In such cases, most users in the USA will certainly
not work at the same time than users in Europe and therefore will not
need all Planning versions in main memory at the same time.

--------------
Conclusions
--------------

When sizing your SAP APO, you must take the following into account :

a) How big are your sizing requirements independently of the amount
of versions (amount of sales orders, forecast orders, etc.) ?
If they are already big, more versions stored in main memory will
only increase the liveCache Main Memory requirements. If they are not
very big, you can afford to have more liveCache Main Memory available
for multiple planning versions.
b) How big is your active version ?
The active version is the one which should be held in Main Memory,
while the rest of versions may be swapped to disk without
necessarily affecting the performance of the system.
c) How many 100 % version copies will be used on average and in
parallel ?
If only some percent of the versions are used in parallel, only this
percent of versions will be relevant for your sizing.
d) How many versions are Time Series or Order relevant ?
Performing version copies with the transaction tscopy can reduce the
amount of effective versions to 50 %.
e) How big are your Planning Versions in general ?
If most of them are not as big as the active Version, you must take
this into account when entering the amount of Planning Versions in the
Quicksizer, so that the sizing results are realistic.

Header Data


Release Status:	Released for Customer
Released on:	05.04.2002 14:02:16
Priority:	Recommendations/additional info
Category:	Consulting
Primary Component:	SCM-TEC In Case of LiveCache Problems: Please use SCM-APO-LCA
Secondary Components:	BC-DB-LVC liveCache
	SCM-APO-SNP Supply Network Planning (SNP)
	SCM-APO-FCS Demand Planning
	SCM-APO-MD-VM Version Management
	BC-DB-LCA liveCache Applications