Data Load Performance Optimization

1、 Upload Sequence: Always load master data before transaction data. The master data load creates all SIDs and populates the master data tables (attributes and/or texts). If the SIDs does not exist when transaction data is loaded, these tables have to be populated during the transaction data load, which slows down the overall process.
If you define selection criteria in your InfoPackage and the selection of the data is very slow, consider building indices on the DataSource tables in the source system.
2、Parallelizing Upload: Parallel processing is automatically initiated during an extraction from an SAP system; the settings for the DataPackage size directly influence the number of DataPackages that are likely to be sent in parallel. Moreover, a setting in the InfoPackage defines the degree of parallelism of updating to PSA and DataTargets. Thus, data load performance is fully scalable.
3、 User Controlled Parallelism: Create several InfoPackages for the same or different DataSources (Master Data) and then schedule them in parallel. Note that delta uploads from one DataSource cannot be parallelized - even if you initialized the delta with disjoint selection criteria. One delta request collects all delta records for this specific DataSource - regardless of any selection criteria.
4、Load Flat File from Application Server: If possible, load the data from a file on the application server and not from the client workstation as this reduces the network load. This also allows you to load in batch.
5、Use ASCII Flat File: If possible, use a fixed record length when you load data from a file (ASCII file). For a CSV file, the system only carries out the conversion to a fixed record length during the loading process.
6、 Delete Indexes: When you load large quantities of data in InfoCubes, you should delete the secondary indexes before the loading process and then recreate them afterwards if the following applies: The number of the records that are loaded is big in comparison to the number of records that already exist in the (uncompressed) F fact table. For non-transactional InfoCubes, you must delete the indexes to be able to carry out parallel loading. The secondary indices of the ODS objects can also be deleted before activating ODS data.
7、NumberRange Buffering (SNRO): When you load large quantities of data in an InfoCube, the number range buffer should be increased for the dimensions that are likely to have a high number of data sets. When you load large quantities of data, you should increase the number range buffer for the info objects (Master Data) that are likely to have a high number of data sets. The number ranges buffer for the SIDs and DIMs resides on the application server and reduces DB server accesses.
8、PSA Partition Size: Set the PSA partition size according to the expected package sizes. If you expect many small packages, set the partition size to a rather small value, so that these partitions can be deleted quickly. In transaction RSCUSTV6 the size of each PSA partition can be defined.
9、Start routines enable you to manipulate whole data packages (database array operations) instead of changing record-by-record.
10、 Change Run: Apply the change run ONCE for all newly loaded master data for a given period. Do not schedule it for the load of every master data object. Change run is executed serially in a background process; use the parallel change run if your hardware resources are sufficient and if your aggregates are distributed among several InfoCubes.
11、Set Threshold for Aggregate Change Run: In the customizing, you can define a threshold (percentage of changed master data) that decides between delta aggregation and aggregate rebuild. Meaning: unless the threshold is reached, delta records are created for all changes to the aggregate and posted to the aggregate as additional records. If the threshold is exceeded, then the aggregates a dropped and rebuilt from scratch. Test results have led to the recommendation to set the threshold parameter to approximately 30%. If the InfoCube contains non-cumulative key figures with exception aggregation (MIN, MAX), all aggregates are rebuilt (no delta aggregation).
12、Set the "Unique"-Flag in ODS: if you are sure that all your records are unique. The "Unique"-Flag accelerates data activation significantly. Only usable for documents that cannot be changed, e.g. sales documents.
13、Do not use "BEx Reporting" flag: if not necessary. The BEx Reporting flag forces the system to draw SIDs for the master data; although they are determined in parallel, this slows down activation performance.
14、Compression: If you are sure, that every request contains a disjoint set of keys (i.e., the same key only occurs within one record), the compression can be optimized by omitting the UPDATE statement and rather using only INSERT into the E-fact table. If you are sure, that the compression for an InfoCube never updates existing records in the E-table (but only inserts new records), set the COMP_DISJ flag for this InfoCube (see SAP Note 375132).