Optimizing performance of ODS objects(来自sap notes 384023)

1. Size of the table for new data (techn. M-table)

              The size of the table for new data of the ODS object should not exceed 1 million data records. The system stores up to 1 million data records in the main memory and the verification to existing records in the table for new data is made in a common request. However, this only applies when the ODS object is being updated by an InfoSource that contains all the InfoObjects of the ODS object. If only individual key figures are changed, then the update is implemented by individual selects.

With more than 1 million data records, this validation is made by individual selects, which prolongs the load time.
              Therefore note:

a) Activate more frequently so that the size of the table with new data remains small.

b) However, if the table increases to more than 1 million data records, you should split the data packets into several requests in order to ensure a good performance. This can be achieved by generating several requests which are loaded more frequently.

              Simultaneously,

c) the data packets within a request should be greater than 10% of the table for new data, that means greater than 10% of the newly loaded, not yet activated records. Example: For a number of 1 million data records, that means that the number of records within the data packet is at least 100 000. If this is not the case, the system does not load the data into the main memory but executes a sinle select against the table for new data, which in turn would affect the performance.

2. Initialization before deltas

              In order to load data into an ODS object, you should first make an initialization and afterwards load deltas. That the table for new data should not exceed 1 million data records applies also to the initialization. If necessary, you must make the initialization in several steps by using selection criteria.

3. Avoiding SIDs

              The creation of SIDs is time-consuming and can be avoided in the following cases:

a) You should not set the indicator for BEx Reporting if you use the ODS object only as a data storage. Otherwise, setting this indicator will have the effect that SIDs are generated for all new characteristic values.

b) If you use line items (for example document number, time stamp and so on) as characteristics in the ODS object, you should mark them as 'Exclusively attribute' in the Characteristics Maintenance.

4. DB partitioning on the table for active data (techn. A table)

              You can accelerate the deletion of data from the ODS object by partitioning on database level. Select the characteristic according to which you want to delete as partitioning criterion. Refer to the database documentation (DBMS CD) for more details on the partitioning of database tables. Partitioning is supported on the following databases: Oracle, DB2/390, Informix.

5. Indexing

              You should use selection criteria for queries on ODS objects. If the key fields are specified, the system uses the existing primary index. The characteristic to which the system accesses frequently should be left-aligned.

              However, if the key fields are only incompletely specified in the selection criteria (recognizable in the SQL trace), you can optimize the runtime of the query by creating additional indexes. You must maintain these secondary indexes manually in Transaction SE11.

6. Locking by parallel loading

              First,you should always load data into the PSA and only if this activity is completed, you should update the data into an ODS object. If you update directly into an ODS object from a source system, the system may parallel the load process. However, in the case of parallel processing,the first process triggers a table lock (for consistency reasons and performance reasons) so that the subsequent process can no longer write into the ODS table and thus a termination occurs.

              These locks can also occur when you use the Data Mart interfaces. For this reason you should set field DREQSER of the entry for DELTA = 'CUBE' from '0' to '2' in table RODELTAM if you extract within the BW via the Myself connection from InfoCubes into an ODS object. As a result, the data packets run into the ODS object in sequence.