How to convert Classic Infocube/DSO to HANA optimized cubes/ DSO
We can convert Standard info cube into In-Memory info cube by using the Report “RSDRI_CONVERT_CUBE_TO_IN-MEMORY ”. Or Call transaction RSMIGRHANADB directly. To add the option of conversion of DSO also in the same program/T-code we can add the parameter ENBL_HDB_MIGR_DSO = X in RSADMIN Table.
During a conversion a lock is set, preventing all maintenance activity and load processes.The conversion is executed as a Stored Procedure within HANA and therefore shows an excellent performance.
During conversion DataStore objects are not available for reporting / staging. Querying on the InfoCubes is however possible during this time.
After migration to the SAP HANA database, normal standard InfoCubes are in the SAP HANA database’s column-based store and have a logical index (Calculation Scenario). In the analysis, they behave like BWA-indexed InfoCubes.If the InfoCubes have data persistency in BWA, the content is deleted during the system migration to HANA and the InfoCubes are set to inactive. If you want to continue using one of these InfoCubes as a standard InfoCube, you need to activate it again and reload the data from the former primary persistence (DataStore object for example).
We can make DSO as an In-Memory based DSO only if it is of Standard type. Also Standard DataStore objects can be converted into SAP HANA-optimized DataStores only if:
1) The DSO is not included in a BW 3.x data flow (for example, by using update rules).
Exception: If you use the BW 3.x data flow only on an inbound basis (but not on an outbound basis), you can still convert the DataStore. However, in general, we recommend that you migrate the old data flow before converting the DataStore. See: http://help.sap.com/saphelp_nw73/helpdata/en/8d/6b1b58cc1744e1b</p><p>ce7898a50e19368/frameset.htm
2) DSO is not supplied by real-time data acquisition. Since small data volumes are usually produced for each activation step when data is supplied by RDA, RDA-supplied DataStores do not benefit in the same way as staging-supplied objects. Continue to use classic DataStore objects for this use case instead.
3) DSO is not part of a HybridProvider or a semantically partitioned object (SPO).You can recreate SPOs based on SAP HANA-optimized DataStore objects
Different options available for DSO migration:
1) Simple Migration: Only Active data gets converted and change log history gets deleted. Conversion is faster and requests cannot be rolled back after migration.
2) Full Migration: Active data gets converted along with change log history. Conversion is slower but there is no restriction on rollback of requests.
Very Informative Blog Isha. Can u pls clarify on the below queries.
1) Can we do the same for other type's of Dso's like Write optimised ,Direct Update Dso's.
2) will it support on top of Partioned DSO's also.
Phani Rayasam
Hi,
No, Write optimised ,Direct Update Dso's or Existing Partioned DSO's cannot be converted to InMemory DSO's. For working with Partioned DSO you can first convert std DSO to InMemory and then perform partioning on top of it.
Regards
Isha
Hi,
Nicely written. I hope this option would be available only in BI 7.3 version. If I convert the existing DSO to In Memory DSO there will be 2 DSOs one in the first database and another one in in-memory database right? will future loading synchronize these two automatically?
Yes HANA can be implemented with only BI 7.3 version. Once you convert the DSO to InMemory, the DSO will be deleted from original database and exist only in HANA now. There will be only one instance of the DSO and not two.