History tables and their impact on Replication in HANA 1.0 and HANA 2.0

[NaveenKumarKaus]

Working on HANA brings some operational challenges and we have to take care of few Standard  restrictions:

• 
  

  Registering a secondary with operation mode logreplay against a primary running on an SAP HANA revision less than or equal to SPS10 will not work, because the primary does not yet support this feature. Furthermore, for operation mode logreplay_readaccess the primary must be running on a revision SAP HANA 2 SPS00 or higher.

  
  


• 
  

  Switching operation modes from logreplay back to delta_datashipping requires a full data shipping.

  
  


• 
  

  The combination of logreplayand delta_datashipping as well as logreplay_readaccess and delta_datashipping in an SAP HANA multitier system configured with system replication is not supported. However, if logreplay_readaccess is configured between the primary system (tier 1) and the tier 2 secondary system, then logreplay is allowed between the tier 2 and tier 3 secondary systems.

  
  


• 
  

  When the connection to the secondary with operation mode logreplay or logreplay_readaccess is not available, the primary system will keep the redo log segments in the online log area to be prepared for the delta log shipping after the connection is reestablished. These log segments are marked as RetainedFree until the secondary is in sync again.

  
  


• 
  

  The operation modes logreplay and logreplay_readaccess do not support history tables.

  
  


• 
  

  For the operation mode logreplay_readaccess the primary and the secondary systems must have the same SAP HANA version.

  
  


• 
  

  With the operation mode logreplay_readaccess the secondary allows read-only access on column tables via SQL providing a delayed view on the data compared to the primary. There is no minimum delay guarantee. The read access on system and monitoring views is supported as well.

  
  


• 
  

  The usage of the Active/Active (read enabled) feature is supported only for tier 2.

  
  

However history table is quite confusing and has cost the delay as still the permanent fix is not available. Alternatives are definitely possible, like delete the history table and then Set replication with logreplay or logreplay_readaccess.

 

However question is what if replication setup with logreplay or logreplay_readaccess and then history tables are created. As no clear information found anywhere, thought to share experience via this blog:

 

HANA 2.0:

Replication setup with CLR and replication works perfectly fine.

Now we create the history tables using below command:

CREATE HISTORY COLUMN TABLE "SYSTEM"."TEST_HISTORY_TABLE5" ( "Id" BIGINT , "NAME" VARCHAR(20), "CITY" VARCHAR(20), PRIMARY KEY ("Id"));



And replication continue to work in HANA 2.0 even history tables are created post replication setup.



Which proves history tables do not impact HANA system replication whence set with logreplay or logreplay_readaccess.

 

HANA 1.0

Replication setup with CLR and replication works perfectly fine.

Now we create the history tables:

CREATE HISTORY COLUMN TABLE "SYSTEM"."TEST_HISTORY_TABLE5" ( "Id" BIGINT , "NAME" VARCHAR(20), "CITY" VARCHAR(20), PRIMARY KEY ("Id"));



Table creation fails but replication continues to work. which means history table does not deteriorate when setup.

It can only cause an error if one tries to setup replication with logreplay. As stated earlier, please consult the history table owner n get rid of history tables before utilizing logreplay benefits.

 

NOTE:  SAP Note 2480889 contains updated information on history tables.

with. revision 122.14 and HANA 2.0 SP 01 , history tables are supported with replication.