The objective of Write-Optimised DSO is to save data as efficiently as possible to further process it without any activation, additional effort of generating SIDs, aggregation and data-record based delta. This is a staging DataStore used for a faster upload.
Write-Optimized DSO has been primarily designed to be the initial staging of the source system data from where the data could be transferred to the Standard DSO or the InfoCube.
- The data is saved in the write-optimized Data Store object quickly. Data is stored in at most granular form. Document headers and items are extracted using a DataSource and stored in the DataStore.
- The data is then immediately written to the further data targets in the architected data mart layer for optimized multidimensional analysis.
The key benefit of using write-optimized DataStore object is that the data is immediately available for further processing in active version. YOU SAVE ACTIVATION TIME across the landscape. The system does not generate SIDs for write-optimized DataStore objects to achive faster upload. Reporting is also possible on the basis of these DataStore objects. However, SAP recommends to use Write-Optimized DataStore as a EDW inbound layer, and update the data into further targets such as standard DataStore objects or InfoCubes.
When is it recommended to use Write-Optimized DataStore
Here are the Scenarios for Write-Optimized DataStore.
- Fast EDW inbound layer.
- SAP recommends Write-Optimized DSO to be used as the first layer. It is called Enterprise Data Warehouse layer. As not all business content come with this DSO layer, you may need to build your own. You may check in table RSDODSO for version D and type "Write-Optimized".
- There is always the need for faster data load. DSOs can be configured to be Write optimized. Thus, the data load happens faster and the load window is shorter.
- Used where fast loads are essential. Example: multiple loads per day (or) short source system access times (world wide system landscapes).
- If the DataSource is not delta enabled. In this case, you would want to have a Write-Optimized DataStore to be the first stage in BI and then pull the Delta request to a cube.
- Write-optimized DataStore object is used as a temporary storage area for large sets of data when executing complex transformations for this data before it is written to the DataStore object. Subsequently, the data can be updated to further InfoProviders. You only have to create the complex transformations once for all incoming data.
- Write-optimized DataStore objects can be the staging layer for saving data. Business rules are only applied when the data is updated to additional InfoProviders.
- If you want to retain history at request level. In this case you may not need to have PSA archive; instead you can use Write-Optimized DataStore.
- If a multi dimensional analysis is not required and you want to have operational reports, you might want to use Write Optimized DataStore first, and then feed data into Standard Datastore.
Functionality of Write-Optimized DataStore
Only active data table (DSO key: request ID, Packet No, and Record No):
- No change log table and no activation queue.
- Size of the DataStore is maintainable.
- Technical key is unique.
- Every record has a new technical key, only inserts.
- Data is stored at request level like PSA table.
No SID generation:
- Reporting is possible(but not optimized performance)
- BEx Reporting is switched off.
- Can be included in InfoSet or Multiprovider.
- Performence improvement during dataload.
Fully integrated in data flow:
- Used as data source and data target
- Export into info providers via request delta
- Can be included in Process chain without activation step.
- Partitioned on request ID (automatic).
- Allows parallel load.
Uniqueness of Data:
- Checkbox “Do not check Uniqueness of data”.
- If this indicator is set, the active table of the DataStore object could contain several records with the same key.
You cannot use reclustering for write-optimized DataStore objects since this DataStore data is not meant for querying. You can only use reclustering for standard DataStore objects and the DataStore objects for direct update.
Write-Optimized DataStore is partitioned on request ID (automatic), you may not need to create additional partition manually on active table. Optimized Write performance has been achieved by request level insertions, similarly like F table in InfoCube. As we are aware, F fact table is write-optimized while the E fact table is read optimized.