Skip to Content
Author's profile photo Jay Cramblet

The Quick and Dirty Guide to Sybase Replication Server Training

If you’ve ever attended a Computer Science class, odds are someone has told you, “Never maintain duplicate data!!!”

Why not? 

Because it’s so difficult to keep it in sync.  If you have a clock, you know what time it is.  If you have two clocks, you’re never sure.

This is where SAP Sybase Replication Server fits in.  Rep Server maintains duplicate data.  When someone runs a transaction that changes data in a database, Rep Server captures that transaction, delivers it to a replicate database, and executes it.  The result: your data can be distributed across the enterprise, but stays in sync.

This may seem like a small thing, but as it turns out, there are a thousand and one reasons to do this.  From maintaining a simple warm standby environment to distributing data globally, maintaining duplicate data can make managing data much easier.  Think about a typical business application.  The online users want a highly normalized set of tables with a reasonable degree of indexing, row-level locking, and archiving of old data.  The reporting users, on the other hand, want a star schema and lots of indexes.  And, don’t remove any of the data: they might need it in the future.

How do you make both groups of users happy?  Simple.  Put them in two separate databases.  Use replication to coordinate the reporting database in realtime with the online database.  Each set of users gets what they want.  And Replication Server takes care of the details.

What if you’ve got more than one type of database to deal with?  Replication Server supports ASE, Oracle, DB2, and MS SQL Server.  It replicates to Sybase IQ.  And, HANA is soon to come.  You can define replication table-by-table, or set it up for the entire database.  You can even replicate stored procedures.  You can do “vanilla” replication, between two identical databases, or transform the data as you replicate.  

Synchronize your data.  Integrate your data.  Migrate your data.  Consolidate your data.  All with Replication Server.

So, what do you need to use Replication Server?  To be an effective Replication Server administrator, you need to know five things:

1)      How to design a Replication Server system

2)      How to install the software and create a Replication Server domain

3)      How to establish replication

4)      How to troubleshoot replication

5)      How to tune Replication Server

There are two classes that will get you what you need.  Fast Track to Replication Server (EDB377) will introduce you to Replication Server, and show you how the pieces fit together.  You’ll get a chance to install the software, create a Replication Server, and add databases to the system.  Then you’ll get a chance to set up replication, using replication definitions and subscriptions, and set up a Warm Standby system.  The class concludes with basic troubleshooting.

Replication Server Masters (EDB577) covers the rest of the curriculum.  You learn how to interrogate the system, read error messages, and fix problems.  Then, you learn how to tune replication.  You’ll learn the details of how Replication Server works, how to measure the performance of the system, and use a variety of tuning features to make data move faster.

Don’t wait.  If you’ve got problems with data, Replication Server can solve them.

For information about Sybase IQ training, go here.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi, Jay. I have a simple question, I hope.What happens if some records in the destination database have some field different from source database? And we have to do a delete from the source database...Primary Keys are equal but other fields have changed. Will the replication server delete those records in destination, in spite of being different from the source? How do you control this situation?

      Author's profile photo Jay Cramblet
      Jay Cramblet
      Blog Post Author


      This is not a problem for Replication Server.  Rep Server performs deletes by primary key.  As long as the primary key is correct, the other columns don't matter.

      Hope this helps,