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