Wednesday, February 4, 2009

Note 363221 - Consulting: Proportional factors / version copy

Note 363221 - Consulting: Proportional factors / version copy

Summary

Symptom
    1. When calculating proportional factors or performing a version copy in Demand Planning
      a) Performance is insufficient
      b) Oracle error -600 Argument 20083 occurs
      c) Oracle bitmap indexes grow very quickly
      d) You want to use parallelisation
Additional key words


proportional factors, copy planning version, performance, parallel /SAPAPO/MC8V

Cause and prerequisites
    1. Define 2 variants for report /SAPAPO/RMDP_CUBE_INSERT_PARAM (SE38)
      a) Variant INDEX_DROP: Enter the name of your infocube and hit Enter
      Records per INSERT block: Choose a very high value (e.g. 1.000.000)
      Remark: If the value for Records per INSERT block is too high, the job might not complete successfully due to a memory allocation error (OS dependent). In this case, you must decrease Records per INSERT block.
      Drop & recreate indexes: 1
      b) Variant INDEX_KEEP: Enter the name of your infocube and hit Enter
      Records per INSERT block: Choose the standard value (e.g. 3.000)
      Drop & recreate indexes: 150.000
      Remark: You must have implemented note 379598 before you can use variants with report /SAPAPO/RMDP_CUBE_INSERT_PARAM in batch mode.
    2. Define a variant for report /SAPAPO/RMDP_SHARE_MANAGER, which completely covers the new time horizon.
    Remark: You can also use the outlined procedure, if you want to perform a version copy. In this case, you must ensure that all characteristics combinations for all periods exist.
Solution


SAP recommends that you perform the following initialisation action,
each time you switch to a new period (or perform a version copy).
Execute a batch job with the following steps:

    1. Report /SAPAPO/RMDP_CUBE_INSERT_PARAM with variant INDEX_DROP
    2. Initialisation report for proportional factors or version copy
    /SAPAPO/RMDP_SHARE_MANAGER with suitable variant (see section Cause and Prerequisites).
    3. Report /SAPAPO/RMDP_CUBE_INSERT_PARAM with variant INDEX_KEEP

Result of this batch job: New entries are created in the tables belonging to the infocube. Step 1 of the batch job ensures that the bitmap indexes do not exist while the inserts (step 2) take place. After the inserts, the insert parameters are changed back to their default values (step 3) to prevent dropping of the indexes.
Subsequent actions will then result in updates, not in inserts.

Additional remark: If you want to perform several initialization
steps in one batch job, you can implement a similiar strategy.
Execute a job step executing report /SAPAPO/RMDP_ICUBE_PERFORM
with a variant that drops the infocube indexes as the first step and
a job step executing report /SAPAPO/RMDP_ICUBE_PERFORM with a variant
that recreates the infocube indexes as the last step.

Source code corrections

Header Data



Release Status:Released for Customer
Released on:04.02.2001 23:00:00
Master Language:English
Priority:Recommendations/additional info
Category:Consulting
Primary Component:SCM-APO-FCS Demand Planning
Secondary Components:SV-BO Backoffice Service Delivery

Affected Releases

Software
Component
Release
From
Release
To
Release
And
subsequent
SAP_APPL
46
46A
46A

Related Notes




379598 - DP 2.0: /SAPAPO/RMDP_CUBE_INSERT_PARAM in background

372718 - Demand Planning 2.0: Advice - parallel jobs

370601 - Composite SAP note: APO 3.0 and 3.1 performance

199470 - Advice: Indexes are increasing / ORA-600 [20083]

159779 - Problems with BITMAPINDEX under ORACLE in BW

No comments: