Performance Tips for DataStore Objects.
To achieve good activation performance for DataStore objects, you should note the following points:
Creating SID Values
Generating SID values takes a long time and can be avoided in the following cases:
-
Do not set the 'Generate SID values' flag, if you only use the DataStore object as a data store. If you do set this flag, SIDs are created for all new characteristic values.
-
If you are using line items (document number or time stamp, for example) as characteristics in the DataStore object, set the flag in characteristic maintenance to show that they are "attribute only".
SID values can be generated in parallel, irrespective of the activation settings. More information: Runtime Parameters of DataStore Objects
Partitioning
You can use partitioning to divide the entire dataset of an InfoProvider into several smaller units that are independent and redundancy-free. This separation can improve performance during the data analysis or when deleting data from the InfoProvider.
More information: Partitioning
Clustering on the table for active data (A table)
Clustering at database level makes it possible to access DataStore objects much more quickly. Select the characteristic that you want to use to access data as the clustering criterion. For more information, see Multidimensional Clustering.
Indexing
Selection criteria should be used for queries on DataStore objects. If key fields are specified, the existing primary index is used. This frequently accessed characteristic should be left-aligned.
If you have not specified the key fields completely in the selection criteria (you can check this in the SQL trace), you can improve the runtime of the query by creating additional indexes. These secondary indexes can be created in DataStore object maintenance.
However, you should note that many of the secondary indexes impair the load performance.
Activation Times for the Standard DataStore Object
The following table shows how much activation runtime is saved. The saving always refers to a standard DataStore object, which the SIDs were generated for during activation.
|
Flag |
Saving in Runtime |
|
|
Generate SIDs on Activation Unique Data Records |
x x |
ca. 25% |
|
Generate SIDs on Activation Unique Data Records |
ca. 35% |
|
|
Generate SIDs on Activation Unique Data Records |
x |
ca. 45% |
The saving in runtime is influenced primarily by the SID determination. Other factors that have a favorable influence on the runtime are a low number of characteristics and a low number of disjointed characteristic attributes. The specified percentages are based on experience, and can differ depending on the system configuration.
If you want to use the DataStore object as a consolidation level, we recommend that you use the write-optimized DataStore object. This makes it possible to provide data in the Data Warehouse layer 2 to 2.5 times faster than with a standard DataStore object with unique data records and without SID generation. More information: Scenario for Using Write-Optimized DataStore Objects.
Further Activation Settings
If you are sure that the active table does not contain any records with the same key, choose the setting Only process new, unique data records. This overrides the settings on the DataStore object and the system does not need to read the records again.
More information: Activation of Data in DataStore Objects
MPP-optimized activation
For MPP databases, the system uses performance-optimized data in the DataStore object. This means the activation runtime can be significantly reduced for standard DataStore objects.
More information: Activation for MPP Architectures