Sybase Replication vs SLT

[Former Member]

Hi All,

I have been reading about Sybase replication server as a medium of data replication from source systems to HANA Database .Previously i have used SLT andlot of clients have been using SLT or BODS.

I see Sybase option also allows real time data replication and it has more benefits than SLT . Any particular reaon why Sybase has been ignored

I would appreciate if some one can throw some light on disadv of using Sybase Replication

Thanks in adv

[Former Member]

//push

Have you already find out, whats the main difference between those and why almost everybody uses SLT?

[former_member254877]

Log-Based Replication (SYBASE) is no longer publicly available. The Log-Based Replication (SYBASE) is part of the SAP HANA appliance software enterprise extended edition that runs out of maintenance on December 31, 2012

It is still available and just renamed to SAP REPLICATION SERVER.

pls follow the below link.

https://help.sap.com/replication-server

[Former Member]

Thank you!

[c_baker]

Log-based SRS (SAP Replication Server) is absolutely still available.  In addition to replicating ASE to ASE as always, it also now supports heterogeneous replication from ASE, Oracle, MSSQL and DB2 UDB to HANA.

SRS 15.7.1 SP300 has just been released with many new features.

It is also at the core of the ASE HADR Always-On option for SAP ECC running on ASE.

The major difference between SLT and SRS is trigger-based vs. log-based.  SLT can be used to migrate ECC systems and maintain them in sync, among other capabilities, while SRS can be used to replicate custom-applications from source to target and for DR (as always).

Obviously, the SCN here has a lot of details:

http://scn.sap.com/community/sap-replication-server

as well as the product page:

http://www.sap.com/pc/tech/database/software/sybase-data-replication-software/index.html

Chris

[arun_sitaraman]

Srinivas,

The log based (SRS) SAP Replication Server (erstwhile Sybase Replication Server) is a fully supported product.

Chris Baker has already explained SRS and SLT.

Thanks,

Arun

[former_member182259]

I think one has to be very careful with may of the statements above as those that lack knowledge about SRS are definitely providing incorrect information.

I will try to provide a bit of a more balanced view and some background....

First, for many years, SLT was the only *approved* method of replicating data between BuS systems.  We are all aware of customers that used other products, but .....none were certified and those customers did so understanding the risks of those implementations and the lack of support for such.  We will choose to ignore those non-supported installations.

Fast forward to about 5 years ago when SAP acquired Sybase.   In that acquisition, SAP obtained (then) Sybase (now) SAP Replication Server (SRS) - which was and still is one of the dominate data replication products in the markets - in many areas far exceeding the capabilities of Oracle's Golden Gate (which sadly is their 4th data replication implementation....maybe they will stick with this one).   While SRS may have started with a goal of providing DR capabilities - and many still use it for that - it quickly became a fast way to provide light-weight integration between systems, report offloading, and to support autonomous distributed systems with full bi-directional data flows.   Many customers who have used it for years at their sites have complicated topologies with hundreds and in numerous cases thousands of interconnected databases replicating data across countries, the globe, etc.  One Asian customer has something like 160 SRS instances connecting >1000 source systems and (according to them) 100K+ targets.   That sounds a bit extreme, but I personally know of multiple customers in that same range and many not too far behind.   As a result, most customers call the topology diagrams "spaghetti charts" as the lines depicting data flows often become quite complicated.   However, there are 1000's of SRS customers out there - so to say "most customers use SLT" is a bit misleading and likely needs to be put on the context of SAP BuS applications and then specifically migrations (a common use) which may or may not result in long-term use vs. temporary.

While it is log-based (vs. trigger) and therefore has less impact on the primary systems, in the early years, SAP Replication Server faced some challenges with SAP BuS systems.   First, many of the legacy systems didn't use standard character sets - or at least they were not used in standard fashion.   Rumor has it that this was done by SAP to allow more multi-byte characters prior to the avent/rise of UTF as a standard (which explains why SAP now uses utf-8 as a standard for installations) particularly on OS's where singlebyte charsets were standard.  One needs to remember, that SAP applications have been around for ~50 years....utf a lot less.   While SRS can do character set translations (e.g. eucjis --> utf-8, etc.) it assumes that the character sets were used as anticipated.   So replicating legacy SAP systems to new environs using SRS was out.....which is one of the common SLT implementations (migrations).   For that reason, you may see a comment that SRS only supports utf8 based BuS systems - while SRS supports most common charsets, the utf8 restriction is one way to ensure that only non-legacy BuS systems are attempted vs. legacy non-standard charset implementations.

The second issue was pool/cluster tables.   While in most databases, these are simply implemented as LOB types (e.g. image for ASE/MSSQL) and SRS could replicate LOB data transparently - when replicating to HANA (which doesn't have pool/cluster tables) there was a requirement to decluster/depool these tables.   While SRS does have the ability to easily customize the delivery via a scripting syntax of the target DBMS, this is something DBA's are more familiar with vs. the usual BASIS admin who typically runs most BuS implementations.  As a result, there was a requirement to productize the declustering/depooling of these tables - which was implemented in SRS several years ago.   SLT didn't have this challenge as it access data through the logical schema layer.

Net result is that BuS customers may be more familiar with SLT and hence their preference for it, however, SRS can be used to replicate out of (recent) BuS environs on MSSQL, ORA, ASE, DB2 and into HANA.   It also can be used in HA/DR implementations as well as replicating to non-SAP reporting instances (e.g. several customers have done this).

The question of which product to use all depends:

1 - the NZDT migration implementation is based on SLT.  Consequently, if simply doing a migration, SLT may be the obvious choice.  Given the legacy support aspect as well as DBMS's that SRS doesn't support, there is no reason to change NZDT to SRS.

2 - SRS is not only log based, but fully transactional - e.g. data at the target is always transactionally consistent.   If replicating to a reporting system and transactional consistency is desired, then SRS may be the best option.

3 - SLT customization can be done via ABAP coding - so if the data movement needs customization and the logic is being developed by BASIS personnel, then SLT may be the best choice due to ABAP familiarity.    SRS customization is implemented using the SQL scripting dialog of the target DBMS - if the developers of the transformation logic are more familiar with the target DBMS dialect, then it might be the better choice.

4 - Because of the transactionality, SRS may be the better choice for HA/DR systems - particularly with ASE 16 with HADR in which synchronous replication from the primary prevents any data loss

5 - Because of the BuS focus, SLT can be quite simple to implement for BASIS admins.  Because of the focus on enterprise installations and support for large scale environs, SRS can appear to be complicated to BASIS admins - less so to DBA's familiar with similar database replication products.

All the above is in reference to BuS systems.   One needs to remember that large scale interconnection between BuS and other applications is intended to be done via application messaging (such as EDI) and not using data replication - therefore it is unintended that BuS systems would be involved in the complicated large scale topologies that we normally see for SRS.....so SLT or SRS both are quite usable.   Ultimately it comes down to most likely who will be doing the implementation....if BASIS - perhaps SLT......if DBA's - perhaps SRS.

However, for custom applications, not sure why one would use SLT - it isn't likely that custom apps have ABAP developers on hand and the resource consumption is considerably higher than SRS (somewhat due to NW requirements).   Certainly, once you start doing anything really complicated and large scale, SRS definitely is the preferred solution for custom apps.

[Former Member]

Wow! A huge thank you & and Like!
Thanks for this voluminous reply!