Need of declustering/depooling:-
SAP HANA approach “Code-to-Data” is focused on pushing data-intense expensive operations to database layer itself to improve agility for business analysts & business users. Possibility of applying logical operations on cluster/pool tables at database level is very restrictive, in fact missing.
Therefore, to take full benefits from HANA code enablement, transition to transparent tables is necessary. SAP note 1892354 talks more about need of this optimization and handling for cluster & pool tables in HANA database.
How declustering/depooling is performed technically during migration:-
During migration or heterogeneous system copy from anyDB to HANA, Table/Index/View structure file is created by R3LDCTL. It identifies the type of object at runtime & creates associated *.STR file as per object’s definition in ABAP dictionary.
For a table cluster, R3LDCTL identifies the associated cluster tables inside that cluster or pool & creates a *.STR.logical file containing dictionary definition of all those logical cluster tables.
e.g.
In anyDB Source System:-
EDI40 is a cluster for storing IDOC data records in AS ABAP ERP system.
and, EDID4 is the cluster table associated to EDI40 table cluster.
Before actual source system export, R3LDCTL creates one STR file for table cluster EDI40 as EDI40.STR& another STR.logical file for cluster table EDID4 named as SAPEDI40.STR.logical.
EDI40.STR contains ABAP dictionary definition for table cluster EDI40.
SAPEDI40.STR.logical contains logical definition of cluster table EDID4.
During actual export, R3LOAD reads these *.STR & *.STR.logical files & creates associated *.CMD, *.TOC, *.TSK, *.LOG for each file separately.
When inspecting into LOG files, we can see how R3LOAD performed declustering by expanding EDI40 cluster into transparent table EDID4. Here type of EDID4 is mentioned as a transparent table instead of cluster table.
Here SAPEDI40.STR.logical is used by R3LOAD along with EDI40.STR and table cluster EDI40 with 8033630 rows is expanded into transparent table EDID4 with 1130299444 rows in this example.
Reason of this increased number of rows in EDID4 is that SAP kernel compresses the data when stores data in a table cluster, therefore when R3load expands a cluster into a transparent table that kernel compression is no longer valid. This results into decompressed increased data line items in transparent table.
As a result, export dump files:-
For EDI40 --> EDI40.001 does not contain any application data. (i.e. 0 exported rows)
Instead,
For SAPEDI40à SAPEDID4.001 contains expanded cluster data in compressed form. (i.e. n..number of exported rows)
*it is always important to check table clusters regularly before any migration is performed. SAP note 1784377 explains more about checks that can be performed at regular intervals in anyDB source system.
Possible error you may face during system export is:
myCluster (255.9.Exp): 14831: inconsistent field length for field MANDT (cluster: 6, transparent: 3).
myCluster (255.9.Exp): 9062: DECLUSTER: error checking target structure for logic table EDID4 .
myCluster (255.9.Exp): 3407: failed to convert cluster data of cluster item.
myCluster: EDI40 **101****0000000000000001****000**
myCluster (255.9.Exp): 561: error during conversion of cluster item.
Above error can be removed by using latest version of R3load available at marketplace. Use SAP note 2118195 gives detailed resolution of this error.
Import into HANA DB target system:-
While import is performed into target HANA database, same behavior continues. That is R3load creates table EDI40 as table cluster& EDID4 as transparent table in HANA DB.
Import LOG file for EDI40 shows:
And LOG file of EDID4 shows:
Finally, after successful migration to HANA DB, we can check consistency of same in target system. Target system based on SAP HANA database shows following attributes for EDI40 & EDID4.
i.e. Table EDI40 is available in HANA db as cluster without any data.
And table EDID4 as transparent table with all uncompressed data line items.
Almost all of clustered & pooled* tables are converted in similar way during migration of AS ABAP from anyDB to HANA DB.
*There are some pooled tables that cannot be converted into transparent tables for technical reasons. Keep these tables as pooled tables. This might apply to the following tables:
GLP1, GLP2, GLPPC, GLS1, GLS2, GLSPC, GLT1, GLT2, JVS1, T157T. It might also apply to all pooled tables with the prefix M_.
For more information, following SAP notes 1849890, 1794490 & 1785060 are helpful.