Q.  Which databases does it support?

A.  Today, SRO Replicator supports Oracle, Microsoft SQL Server, Informix, Sybase ASE, Sybase SQL Anywhere, Progress, DB2 and Postgre SQL databases.
Because SRO Replicator accesses the database as a client, it can replicate the high-end databases whether they are running on Windows, Unix, or other platforms. 
Many other products support only one database, or very few databases.

A.  SRO Replicator is a truly heterogeneous peer-to-peer environment and does not distinguish between “sources” and “targets.” It replicates bi-directionally between all supported databases with full “update-everywhere” capabilities and you can use different physical databases at different sites in the same distributed system. Some other products claim to be heterogeneous, but really only support one or a few
Database/s fully and the others with severe limitations (e.g., through gateways, non-bidirectional,
and/or “target-only”).

A.  SRO Replicator is an official Internet standard service on TCP/IP ports 242 and 2584.
Replication products that are nonstandard are more difficult to use (or cannot be used) through firewalls.

A.  SRO Replicator uses industry-standard, government-endorsed Triple-DES, SHA, and ECC security  lgorithms through Certicom’s efficient Security Builder library.
Beware of products which use “custom” security or claim to have added security recently.

A.  SRO Replicator was designed from the start for ease of portability to run natively on Linux, Unix and other platforms. The replication engine is written entirely in standard C++. SRO Replicator  uses Microsoft, Certicom and DataDirect libraries and tools supported on all popular computing platforms.
Replication products that are developed using non-portable languages or tools are difficult to port to other platforms in response to customer needs.

A.  SRO Replicator supports BLOBs, from small to multi-megabyte binary data.
Many replication products do not support BLOBs.

A.  SRO Replicator supports true asynchronous update-everywhere replication. Sites connect in pairs, and each replication session bi-directionally transfers new updates to and from both sites. Other products use message-based or synchronous replication. Both are weaker, even though they are sometimes touted as “features”. Message-based replication is weaker because it is;

A.  For a 5M row database which undergoes 10% change each day, SRO Replicator averages 8% CPU usage on a 700MHz Pentium III over the course of the day (and less, if replicating over a slower network so that replication is network-bound). When not replicating, SRO Replicator consumes negligible CPU time.

Other products that can visibly slow down the system while running are inappropriate for unattended transparent background operation for most users.

A.  SRO Replicator replicates:
  -  only the changes (“deltas”)
  -  made since the last replication 
  -  to the subset of the data that both sites have in common d) with full compression.

With SRO Replicator’s “fragment” feature, this usually means replicating only small parts of a record, not full records, and allows true “trickle” and near-real-time replication. Sub-minute replications are common.

Many products replicate only full “snapshots” of the database, complete images of all or much of the database’s data, even if little has actually changed. Others say that they replicate only changes, but actually transmit far more. Others use inefficient protocols that do not operate well over slow networks.

Q.  Does it allow concurrent replications of the same database?

A.  SRO Replicator can replicate with arbitrarily many sites simultaneously. Concurrent sessions ‘follow’ each other through the schema, gathering and applying updates. This allows highly efficient ‘passthrough’ replication: For example, if site A is replicating with site B, and while that’s in progress B starts to replicate with site C, and C with site D, then the replication sessions overlap and updates travel from A to D nearly as quickly as if A and D were replicating directly.
Some other products are limited to a single replication at a time, which reduces scalability and usability. Even products which allow concurrent replications rarely support efficient ‘passthrough’ replication. (For more about pass-through replication, see also the next question.)

Q.  If I have a large network with thousands of updates taking place at all sites, won’t it take a long time for the updates to be propagated?

A.  SRO Replicator automatically optimizes propagation times, because of its automatic load balancing and concurrent ‘passthrough’ replication ability. When a replication time occurs, sites dynamically select replication partners based on how much data they have in common and how fast the partner (and/or the network connection to the partner) can operate. Sites that contain the full database (“Complete” sites) organize themselves into an efficient tree configuration for optimal replication.

Most other replication products are very inefficient at replicating updates to large numbers of other sites.

Q.  Does it prevent key collisions (i.e., does it allow safe distributed record creation)?

A.  SRO Replicator's “globally unique IDs (GUID)” are efficient 4-byte integers, and allow new records to be safely created in the same table offline at different sites without key collisions.

Some replication products offer no GUID support at all. Others support a “probably unique” ID which is a large text value (typically ~30 bytes) containing a site ID concatenated with a timestamp, a sequence number, and other information; this usually works, but it is at best inefficient.

A.  A false collision occurs when two, separate users, with valid update authority, simultaneously update different fields of the same record. Resolving these conflicts is certainly a major source of administrative overhead. SRO Replicator's “fragments” feature correctly allows updates to different fields in the same record at different sites without any false collision. Fields that should not be allowed to change independently are defined as such by the database developer.

Most replication products do “record-level” replication, and so updates to the same record at different sites are always a collision even if the updates are to logically unrelated fields (e.g., Customer.Address and Customer. Credit rating). This is a serious integrity weakness if only one of the updates survives until an administrator checks the conflict log and reapplies the “losing” update. (Note: These “false collisions” account for the vast majority of collisions in most replication systems.)

Q.  Does it guarantee that related fields in a record will change together?

A.  SRO Replicator's “fragments” feature correctly guarantees that fields in the same record that should change together (as defined by the database developer) will always change together. Attempts to make competing updates to these related fields in the same record at different sites are always caught as a collision.

Some replication products do “field-level” replication, and so updates to different fields of the same record at different sites are always allowed. This is a serious integrity issue if some fields should not change independently (e.g., Customer.Address and Customer.ZipCode; if a site knows to change one, it knows enough to change the other, and since they have a “common update responsibility” the fields should change together).

A.  As shown above, SRO Replicator first prevents key collisions and false collisions, which are the majority of current replication collisions. When a true collision or conflict does occur, SRO Replicator's default behavior is ‘Most Recent Update Wins’. Although the default handling mechanism may be adequate for 99% of the situations, it can easily be changed and customized using conflict event handlers. SRO Replicator currently differentiates between nine categories of true collisions. For example, sites A and B synch, then offline a user changes the same customer’s address differently at each site, then A and B replicate again: this is categorized as a “Type 1A” collision because the competing updates were made based on the same pre-image (original data in that record fragment).

Q.  Does it preserve relational integrity?

A.  SRO Replicator always automatically replicates parent records before dependent records.

Some other products do not automatically enforce correct relational integrity for foreign key relationships.

A.  SRO Replicator supports full ACID transaction support without compromise to SRO Replicator's peer-to-peer, update-everywhere, and fully heterogeneous operation.

Some replication products do not support transactions. Others support transactions, but only in a “source/target,” “master/slave” or “hub-and-spoke” configuration, or with only unidirectional replication. This is restrictive for users, and not scalable. Few or no other products can add transactions during replication.

Q.  Is it secure enough for replicating safely over public/semipublic networks like WANs, Internet and GSM connections?

A.  SRO Replicator was designed from the start to be strongly secure. It uses industry-standard government-endorsed Triple-DES, SHA, and ECC security algorithms. All replication sessions are automatically strongly encrypted to ensure that eavesdroppers cannot read transmitted data. (This never affects performance).

Most other products do not replicate data securely. Beware products which say they will add (or have added) security in a new release: security affects a system’s architecture, and it is difficult or impossible to retrofit security properly onto a system that has not been designed from the beginning with strong security in mind. If you want security, reject out of hand any product that uses “custom” or “proprietary” home-brew security; it will not be secure.

A.  SRO Replicator's Dynamic Data Slicing Architecture (DDSA) permits query based data deployment known as ‘worksets’. This allows distribution of only the data which is pertinent to the user or site. DDSA gives administrators ‘Need to Know’ security control which limits an enterprise’s data exposure and controls the amount of information a user is allowed to see, without application changes.

Few or no other replication products provide there security features.

Q.  Do customers have to rewrite their applications’ database access code?

A.  SRO Replicator never sits ‘between’ the application and the database. SRO Replicator always operates as “just another client” to the database. The application can use whatever database access method it likes.

Some other products require that the application must access the database through their proprietary ODBC driver or other fixed method. This forces the customer to rewrite the application to use that method.

A.  SRO Replicator does not require any API calls. The minimum requirement for a customer application is that the application can not change the existing primary keys.

Some other products require API calls to make the replication work. Other products are not complete runtime products at all, but only toolkits or libraries that require the customer to do actual programming.

Q.  Do customers have to make extensive changes to their database schema?

A.  No changes need to be made to the application’s schema. SRO Replicator automatically adds its own Control and System tables to the existing schema.

Some other products also do not require database changes, but instead require applications to be specially rewritten to access the database through their proprietary method. Other products require significant database changes.

A.  SRO Replicator's rich API can be used by any application to directly control the replication engine’s configuration and functionality. Furthermore, the SRO Replicator SDK provides administrators with the ability to create turn-key Deployment Kits, which can automatically install the replication engine, along with your custom application.

Few or no other replication products are easily embedded.

A.  SRO Replicator does not sit between the client and the database, and no API calls are required, so the application can be written using any tool or language. If the application intends to make optional SRO Replicator API calls, it must only be able to call a standard Win32 DLL or use a Linux shared object.

Q.  Do administrators have to micromanage which data subsets go to which sites?

A.  With SRO Replicator “worksets” and “fragments” features, the database designer sets up the distribution rules once, at design time. All sites, where the database is installed, will use the same shared rules. Once the replication network has been established with these rules, the Administrator can ‘subscribe’ individual sites to the appropriate data subsets. This can be accomplished, remotely, through the SRO Replicator Administrator application or programmatically, via the SRO Replicator API. There is no need for administrators to micromanage which data goes to which sites. Each site easy gets
exactly “all and only” the subset of the database that it needs, with full referential integrity. (See the SRO Replicator Developer’s Guide for more information.)

Other replication products require complex SQL queries to manage which data is needed at a given site. This greatly limits scalability because it is time-consuming and error prone. (One of the most common complaints SRO Replicator has heard from customers about other replication products is that “I can’t afford to put a DBA at every site.”)

A.  SRO Replicator's peer-to-peer architecture allows the entire distributed database to be administered from any site. An authorized administrator can set site replication schedules, data subset (“slice”) subscriptions and any other configuration from any site.

This is possible because SRO Replicator's internal housekeeping information is itself replicated using the same flexible sharing rules that SRO Replicator supports for customer databases.

Q.  Do administrators have to micromanage which sites replicate with each other?

A.  As sites are added and removed, SRO Replicator's automatic adaptive load balancing transparently reconfigures the network dynamically for the most efficient propagation. When a new site is installed, it performs an initial replication with any existing site, and then is a fully participating member of the database network with housekeeping information about the location, schedules, subscriptions, and other information about other sites.

No manual housekeeping is needed.

Most other products require an administrator to define which sites should replicate with which others in which order. This does not scale to networks with thousands of sites.

A.  SRO Replicator is an official Internet standard service on TCP/IP port 242. To replicate through a firewall, simply allow port 242 inbound and outbound.

Q.  Does it support true “update-everywhere”?

A.  SRO Replicator allows database updates at any site, with no restrictions. All sites are true peers; when an update is made at one site, it is replicated to only the other sites interested in that piece of data.

Some replication products restrict updates to originate at only some sites (“master/slave,” “master/replica” and “source/target” models), or even at only one site (“publish/-subscribe” model). This can severely restrict end-user work.

A.  SRO Replicator's philosophy is that the user should not be able to tell the difference between working online at head office and offline on the road; the application and data are “just always there.” SRO Replicator performs replication as a background task, and users never need to know that replication is even occurring,. Whenever the computer has a network connection that allows it to see another site (for example, the user has logged onto the Internet from home to browse web pages), replication will  automatically occur as scheduled. If the connection is interrupted during a replication, then the next time
SRO Replicator will replicate the rest of the updates with the same partner site or with any other available site. By utilizing the SRO Replicator API, much of the replication engine’s workings can be controlled by the application, so that it can become a transparent part of another software product.

Other products require users to be aware of replication, and even to initiate replication.

Q.  Can data management (“which data needs to be stored at which sites”) be made completely transparent for both administrators and end users?

A.  Yes. SRO Replicator's “work sets” feature makes it easy to subset the database in a way that is fully transparent to both administrators and end users. For example, consider a database sub-setted by customer, so each site is subscribed to the information related to each customer that it cares about. Then, in the application program, when the user clicks on a customer he’s never clicked on before and the user has permission to subscribe to that customer, the application can automatically subscribe the site to that customer with a single function call. For example, if it was customer #12, the function call is just DSECSubscribe (dbname, “Customer”, 12). During the next replication cycle, SRO Replicator will contact another site that already has that customer’s information and automatically add exactly and only that customer’s information into the local database; from then on, the local site is just another peer that sends and receives updates to that customer’s information. Similarly, the application can transparently unsubscribe to slices of data that are no longer needed.

Most other products require “a DBA at every site” to manage the contents of local databases. Some products allow users to manage these themselves, which reduces the need for expert DBAs but also means that replication is no longer transparent to the user.

Q.  Can replication be fully automated?

A.  SRO Replicator allows full flexible replication scheduling, and authorized administrators can manage replication schedules for the entire network from any site.
Some other products cannot be fully automated without custom programming work.

Q. What happens in the event of the database being deleted or after a backup is restored?

A. The SDR makes database backup and recovery easy; in the event of a hardware failure a full restore of the database is automatic by either creating a new empty database or restoring any old database from a backup. When the SDR replication engine communicates with another database in the replication network the lost data is automatically re-built on the fly.