Usage of write optimized DSO's (WDSO's)

Write optimized DSO's can be really useful, not only for an acquisition layer in a BW system architecture.

For full loads a WDSO is ideal since data do not have to be activated. This means great performance improvements. No change log is filled either causing duplicate DB storage for every load. (unless you would clear the changelog after each load)

If you use a particular table only for lookups from other transformations, please notice the use of a proper index.

Be ware of the switch for uniqueness of data check. Standardly this is switched off, meaning during the load towards the WDSO the data in the load is being checked for uniqueness on the fields entered in the semantic key. Be aware, the DTP below will have semantic grouping switched on to be able to do this uniqueness check. This can have performance issues in bigger full loads when preparing the datapackages. Also the WDSO will automatically create an index on the fields in the Semantic Key,

Switching this option in the WDSO will enable you to freely load towards the object, but make the load towards the object "dummy" proof. Also, the table will have no index yet, you have to create one your own if needed.

Reactivate Transformations and DTP's

Are you also annoyed after changing an infoprovider (even description) that all transformations / DTP's are inactive?

Instead of manually reactivating them, you can also use program RSDG_TRFN_ACTIVATE to activate all inactive transformations (object status INA)...or activate transformation ID individually. Their related DTP's are then activated as well.