In the next posts, I will present SAP SRS and how it enables Business Continuity solutions.
Some brief words of history.
1993. Sybase Replication Server (SRS in short) pioneered the database software replication. SRS was born from a co-innovation effort with Wall Street customers. Sybase originally developed its Replication Server with funding from two major Wall Street customers (Goldman Sachs & Co. and Morgan Stanley & Co). Both firms were able to contribute to the design of the project in exchange for their capital contributions.
2013. Twenty years and 3,000 customers later, SRS now belongs to the database technology portfolio of SAP. SAP SRS is a mature, proven and robust database replication solution that continues to provide best of breed innovative capabilities.
1993. Sybase Replication Server (SRS in short) pioneered the database software replication. SRS was born from a co-innovation effort with Wall Street customers. Sybase originally developed its Replication Server with funding from two major Wall Street customers (Goldman Sachs & Co. and Morgan Stanley & Co). Both firms were able to contribute to the design of the project in exchange for their capital contributions.
2013. Twenty years and 3,000 customers later, SRS now belongs to the database technology portfolio of SAP. SAP SRS is a mature, proven and robust database replication solution that continues to provide best of breed innovative capabilities.
SRS has three main use cases:
- Data distribution and database migration
- Distribute: move centralized data to operational applications
- Share: share data between operational applications
- Synchronize: maintain consistency in overlapping data values
- Database migration: move from older version of database platform to newer one
- Real-time Decision Support
- Create ODS (copy of OLTP production systems for daily reporting)
- Real-time loading of data warehouses (SAP HANA, IQ, ASE, Oracle, Microsoft SQL Server, IBM DB2)
- Business Continuity solutions
- Enable business continuity in event of site-wide disaster
- Maintain application availability during planned/unplanned downtime
Key features.
Before developing this last use case, I will shortly list some features of SRS:
Before developing this last use case, I will shortly list some features of SRS:
- Transaction log based replication
For completeness and consistency purposes, the origin of the replication flow is the source database transaction log. Extracting transactions from transaction log has a low performance impact on the source database operations.
- Continuous replication – Real Time replication
Replication flow is by default applied continuously. Replication latency in LAN environments is typically a few seconds.
- Asynchronous replication
Transactions in the source database are picked by SRS for replication and applied asynchronously to target databases.
- Application transparency
Applications do not need to be modified to set up SRS. By contrast, trigger-based replication require developing/modifying triggers in the source database.
- Fault tolerant
SRS uses a loosely coupled connnection model. If one of the components is not available, replication flow will resume and continue as soon as the missing component becomes available again.
- Database or object level replication
Objects (Tables, stored procedures) can be individually replicated or globally at database level.
- DML operations replication
INSERT, DELETE, UPDATE, TRUNCATE TABLE are replicated DML operations.
- DDL operations replication
CREATE/DROP TABLE, CREATE/DROP PROCEDURE (…) can be replicated.
- Transformations
Basic transformations can be implemented via SRS’s powerful function string feature. DML operations can be customized easily to fit special requirements. For instance, UPDATE statements can be applied with INSERT statements.
- Heterogeneous data movement
More than 400 customers rely on SRS to replicate non SAP databases like ORACLE, DB2 or Microsoft SQL Server.
Key components.
A replication system depends on the following basic components.
- Source database
The source database can be SAP ASE database or non SAP databases like ORACLE, IBM DB2, Microsoft SQL Server. Source database is also often referred to as the primary database).
- Source transaction log
Transactions to be replicated are extracted from the source database transaction log.
- Replication Agent
Replication Agent is a special component that scans the transaction log of the source database and picks up transactions for replication. Replication
Agent can work with various transaction logs like SAP ASE transaction log or ORACLE redo log/archive log. Replication Agent forwards transactions to
the main replication component SRS.
- SRS
SRS receives transactions from Replication Agent processe(s), sorts them and applies them to target database(s) in a consistent way. Replication data is stored on disk partitions for recovery and resilience purposes. SRS has a repositiory database (named RSSD) which stores the list of the replication cobjects and the current replication state.
- Target database
The target database can be an SAP database like SAP HANA, ASE, SQL Anywhere and IQ or non SAP databases like ORACLE, IBM DB2, Microsoft SQL Server, any ODBC target or even a message bus. SRS appears like an ordinary client to the target database. Target database is also referred to as the replicate or destination or standby database.
Diagram below depicts a basic replication setup.
Note that these components can be located on different and remote hosts. This is particularly important from Business Continuity perspective. The target database server can be located in a server in the same LAN, or in a remote site on a metropolitan network or on a WAN.
The underlying idea is that important business data can be continuously replicated to one or more disaster/recovery locations regardless of the distance. Performance of the primary site is not burdened by the distance, because SRS uses asynchronous replication. Distance will only impact the replication.
SRS solutions for Business Continuity.
Today, SRS has three solutions for Business Continuity purposes. They all provide up and running disaster/recovery sites which are immediately available.
Warm/Standby (1995. SRS release 11.0)
Warm/Standby is the oldest Business Continuity Solution supported by SRS. SRS replicates transactions from an Active or Primary database (applications connect to the active database) to a Standby database. Only one SRS is used for this setup and the replication is 1:1 (1 source database to 1 target database)
The remarkable feature of Warm/Standby is that the direction of the replication flow can be switched. The primary database will become the standby database and vice versa.
Multi Site Availability (2003. SRS release 12.6)
Multi Site Availability (or MSA in short) can be considered as an extension of Warm Standby. It allows for replicating a source database to one or several target databases. (1:n replication - 1 source database and n target databases). Replicated objects can be filtered out with inclusion or exclusion list. On the other hand, it does not have the ability to switch the replication flow. But bi-directional replication flows can be setup.
HA/DR (2013, SRS release 15.7.1 SP100)
High Availability / Disaster Recovery feature is the brand new Business Continuity solution of SAP SRS for ASE 15.7.1 SP100. It can be used for Business Suite landscapes powered by ASE and custom applications with ASE. For Business Suite, the scope of the replication is the entire source database server (3 databases: master, saptools, and the SAP database).
HA / DR feature relies on a new component named DR Agent. DR Agent improves the usability of SRS at several levels:
- It simplifies the initial installation of SRS.
Sapinst GUI installer drives the installation of SRS, replication items (SRS processes, routes, database replication definitions, database replication subscriptions) on both nodes. DR Agent is used to control the execution of complex installation steps.
- It automates the failover process.
DR Agent runs individual failover tasks (like replication agent starting/stopping); it controls their execution.
- DR Agent monitors the availability of servers
Comparison of SRS solutions for Business Continuity.
To complete this post, I will compare the three Business Continuity solutions offered by SRS. In the next post, I will detail the Warm Standby solution.
| Feature | Warm/Standby | MSA | HA/DR |
|---|---|---|---|
| Use cases | Server and site availability Custom application | Server and site availability Custom application | Server and site availability HA/DR for Business Suite |
| Number of SRS | 1 | 1+ | 2 always (1 on primary, 1 on standby) |
| Replication scope | database | database | database |
| DML replication | YES | YES | YES |
| DDL replication | YES | YES | YES |
| Business Suite certified | not applicable | not applicable | YES |
| Target availability | YES, readonly | YES, readonly | YES, readonly |
| Objects inclusion/exclusion list | NO | YES | NO |
| Number of databases | 1:1 | 1:n | 3:3 |
| Switch/Failover | YES | NO | YES |
| Client redirection | MANUAL | MANUAL | AUTOMATIC |
| Standby database initialization | Hot backup. No downtime | Hot backup. No downtime | Hot backup. No downtime |
| Remote target (WAN) | YES | YES | YES |
Databases | ASE-ASE ORACLE-ORACLE only | ASE-ASE ORACLE-ORACLE typically | ASE-ASE only |
References:
[1] “SAP Sybase Adaptive Server Enterprise Getting Started with the Sybase Database and the SAP System” http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/0040e969-b4a1-2f10-998d-e0eeec6fb...
[2] SAP Note 1650511 SYB: High Availability Offerings with SAP ASE
[3] “Adaptive Server® Enterprise Helps Ensure Critical SAP Applications are Always Available to Organizations”
http://www.sap.com/corporate-en/news.epx?PressID=21357
[4] “SAP Sybase Replication Server” information
http://www54.sap.com/pc/tech/database/software/sybase-data-replication-software/index.html
[5] “SAP Sybase Replication Server” documentation
http://help.sap.com/replication-server
---
Stay in the conversation by following SAP Services on
Check our Database Services Content Library
Follow along throughout the event on Twitter at @SAPServices
2 Comments
