Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

BI solutions running on HANA will require data feeds from current OLTP systems.  SAP have a goal of implementing OLTP and OLAP on the same HANA system; however implementations of HANA are likely to consist of ‘side by side’ systems for some considerable time ; not least because this is fastest and cheapest route to get access to data processing on HANA as the cost and time of migrating current OLTP system to HANA will be significant.  Therefore  ‘real time’ replication into HANA based OLAP systems will be key to providing HANA performance to an enterprise.

My experience of working with Sybase RS has shown it is capable of replicating very large volumes of data in homogenous and heterogeneous environments, with minimal impact on the source systems.   I would suspect that a trigger/table base replication, as provided by SAP LT, may not have the potential to scale as well as Sybase RS. However within a ‘SAP only’ environment you have the benefit of implementing a proven and tightly integrated solution with SAP LT.

Considering implementations of HANA outside of SAP applications (and surely this is major goal for SAP  - in fact it’s pretty much a stated goal with their 2015 market place target) then I consider Sybase RS a better choice for feeding data into a HANA BI solution; it can be implemented with minimum impact on source systems offers a great deal of flexibility in architecture and replication design.

SAP provide a number of options for getting data into HANA, for initial load and/or on-going ‘feeding’ of a DI solution.     These include :-

  • Direct Table Imports. I.e. Import table via HANA Studio or ‘import data’ command
  • Business Objects Data Services (BODS) – an ETL tool
  • Direct Extractor Connection (DXC) 
  • SAP Landscape Transformer (LT) Replication Server.

SAP have a mature data replication product  -  Sybase Replication Server (RS)  which is due to made available to work with HANA in 2013.

SAP report that a majority of “Live SAP HANA” customers use SAP LT for data replication.

So how do these two products compare? What would be gained from utilizing Sybase RS over SAP LT?

SAP LT if logically similar to Sybase RS, they both: -

  • Provide ‘real time’ replication from various database sources
  • Can configure multiple sources to single target or single source to multiple target
  • Implemented as a separate process
  • Transformation and filtering of data through replication processing is possible

However the implementation is very different.  SAP LT uses databases triggers at the source database to log modified rows into logging tables on the source system.  These rows are extracted via a SAP LT read module; mapping and transformation is applied before apply the data to the target system via the write module.

Sybase RS utilizes utilises a agent process running on the source database to read the transaction log, forwarding data from replicated tables to the replication server where they are stored to disk.  RS server transforms the data, where applicable and applies the data to target systems – defined via replication subscription definitions. 

SAP LT’s major advantage would seem to be it’s integration with the whole SAP ecosystem; it’s been integrated into the SAP landscape for some time and    can be managed using SAP HANA Studio – allowing relatively simply configuration and support.

However – coming from a background of using Sybase RS I can see one some major advantages that RS has over SAP LT: -

  • Performance.
    • Trigger execution on the source system – and the associated writes to logging tables  - will have a performance overhead
    • As will marking rows as processed once the commit is completed to the target system
  • Replicating Stored Procedures -  Sybase RS allows replication of the execution of a stored procedure
  • Cannot easily utilize on source systems which already have triggers  - i.e. for use by source application
4 Comments
Labels in this area