What is the different delta updates and when to use which updates?
Delta loads will bring any new or changed records after the last upload. This method is used for better loading in less time. Most of the std SAP datasources come as delta enabled, but some are not. In this case you can do a full load to the ODS and then do a delta from the ODS to the cube. If you create generic datasources, then you have the option of creating a delta on Calday, timestamp or numeric pointer fields (this can be doc number, etc).
You'll be able to see the delta changes coming in the delta queue through RSA7 on the R3 side.
To do a delta, you first have to initialize the delta on the BW side and then set up the delta. The delta mechanism is the same for both Master data and Transaction data loads.
There are three deltas:
Direct Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.
Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.
Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
Delta loads will bring any new or changed records after the last upload. This method is used for better loading in less time. Most of the std SAP datasources come as delta enabled, but some are not. In this case you can do a full load to the ODS and then do a delta from the ODS to the cube. If you create generic datasources, then you have the option of creating a delta on Calday, timestamp or numeric pointer fields (this can be doc number, etc).
You'll be able to see the delta changes coming in the delta queue through RSA7 on the R3 side.
To do a delta, you first have to initialize the delta on the BW side and then set up the delta. The delta mechanism is the same for both Master data and Transaction data loads.
There are three deltas:
Direct Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.
Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.
Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
Comments