Database Replication

Editor's Note: The Buyer's Guide summarizes vendor-submitted information. To find out about future Buyer's Guide topics or to learn how to include your product in an upcoming Buyer's Guide, go to http://www.winnetmag.com/buyersguide. To view previous Buyer's Guides on the Web, go to http://www.winnetmag.com/articles/index.cfm?action=buyersguides.

To view this issue's Buyer's Guide, click here.

A few years ago, database replication was a high-end capability that few companies considered, let alone implemented. Now, more businesses are interested in database replication for two main reasons: Businesses are becoming more geographically dispersed yet their employees still need access to a single set of coherent data, and many companies work with massive datasets that they can't quickly restore in the event of a system failure.

Database replication is different from file replication, which essentially copies files. Database-replication products log selected database transactions to a set of internal replication-management tables. The software then periodically checks these tables for updated data and moves the data from the source to the target systems while guaranteeing data coherency and consistency.

Database replication helps handle many of the problems you can encounter with distributed systems. Replicating databases to systems in branch offices lets branch-office users access a local copy of the data instead of accessing a central server over WAN links. Database-replication products also let you transfer selected data sets to a reporting server so that you can move your processor-intensive reporting processes off of your main transactional database.

Database replication can also supplement your disaster-recovery plans by duplicating the data from a local database server to a remote database server. If the primary server fails, your applications can switch to the replicated copy of the data and continue operations. Many database-replication products even have built-in tools to let you update the primary database with any changes that users made to the backup database while the primary database was offline.

If you have just one database management system (DBMS), you probably don't need a database-replication product—databases such as Microsoft SQL Server, Oracle, and DB2 provide internal replication features that copy data to like databases. However, if you have multiple DBMSs, a database-replication product can help because none of the major database products replicate very well to other vendors' databases.

When comparing database-replication products, check which database platforms the product supports, what types of replication the product provides (e.g., snapshot, near-realtime, two-way), whether the product supports scheduling replications, what mechanisms trigger replication, whether the replication process is program controlled, and what database object types you can replicate. Also, determine whether you can make schema changes, whether the product supports data transformations, and whether the product supports computing new fields in replicated tables.

In addition to these basic product features, you should ensure that the database-replication product you choose is compatible with your application environment. Some database-replication products might require system changes that could make your database incompatible with your applications.

Database-replication products can provide a powerful mechanism to distribute your data and maintain backups that you can use if a disaster occurs. However, you must test and evaluate database-replication products in your own environment because each environment is different and might react in ways that you don't expect.

End of Article