SDR

Today, SRO's Data Replicator supports Oracle, Microsoft SQL Server and DB2 databases.

Because SDR 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.

SRO Replicator is a genuinely 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 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”).

SDR 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.

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 locations. Other products use message-based or synchronous replication. Both are weaker, even though they are sometimes touted as “features”. Message-based replication is more vulnerable because it is:

• Less efficient
• It often relies on another transport like e-mail and .ftp that does not always provide delivery time guarantees;
• It is less robust; for example, sites cannot correctly determine and adjust for clock drifts.

A replication product is incomplete if it relies on other transports (e-mail, .ftp) to operate. Synchronous replication (the same or similar to traditional “distributed databases”) is weaker because it usually requires that all affected sites be available at the same time.

SRO Replicator is the right peer-to-peer system.

Any site can replicate with any other that connects to any TCP/IP network, including the Internet. Replication is symmetric and bidirectional, even if the two locations are running different databases (e.g., MS SQL and Oracle), or one site has much more data than the other (e.g., 50MB on a laptop and 50GB on a regional server). Sites exchange updates to whatever data they have in common. SRO Replicator does not enforce a distinction between “sources” and “targets,” but it does fully support non-peer configurations (see next question).

Most replication products distinguish between “sources” and “targets,” or “masters” and “slaves/replicas.” This can severely limit end-user usability and scalability, especially if it requires a centralised hub-and-spoke configuration where all databases must replicate with one central site. Also, many products support certain databases only if they are used as targets (“target-only”).

SRO Replicator supports all of these configurations because they are just subsets of true peer-to-peer operation.

For example, an information vendor may replicate specific subsets of a legal information database to specific customers who pay for that specific data, but the data may only ever be updated at one central site and “published” or “pushed” to the others.

Most replication products support these configurations but are limited to these configurations only (see the previous question).

SRO Replicator is massively multithreaded and uses a separate thread for each replication session.

It can run on a small notebook computer right on up to multiprocessor servers, and will immediately take advantage of the extra power. Because of SDR's efficiency, extra CPU power is almost never needed; this is most appropriate when the local database has frequent and very large changes, such as a terabyte-sized video jukebox database whose videos are frequently updated.

Any SRO Replicator database is as easy to deploy to two sites as to two thousand.

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. As machines are added or removed, SRO Replicator's automatic adaptive load balancing transparently re-configures the network dynamically for the most efficient propagation.

No manual housekeeping is needed.

Most other products require an administrator to define which sites should replicate with which others in which order, SQL queries to define the subsets of data to reside at each site, and so on. This does not scale to networks of thousands of sites. (See the “Runtime Administrator Ease-of-Use” section.)