Introduction
Historically, database replication became a huge
topic when distributed and homogeneous systems began to require information that
was not readily available through common database connections or gateways. As
an example, in the early days of Oracle, when SQLNet was not available,
replication took the form of backup and recovery scenarios such as using export
and import. This was not a huge issue twenty-plus years ago when databases were
very small. However, the databases of the last 10 – 15 years require a much
more robust mechanism to replicate data. The early approach to replication
worked well in homogeneous environments but quickly fell apart when, say,
someone needed to replicate data from an Oracle database to DB2. While most
databases have replication abilities, both native and non-native, this causes
some issues: each database vendor will more than likely have multiple methods
of replication. Oracle, for example, has database links, Oracle Streams,
Materialized Views, Warehouse Builder, and gateway products for replicating
data between non-heterogeneous databases—complicating not only the choice of
approach but the staff’s ability to maintain and administer multiple
technologies effectively.
Setting
up replications, when the target table already exists, is as simple as right
clicking on the source table and choosing to create a new replication. From
there you just select the replication mode, select source connection and table,
select the target connection and table, verifying or altering the mappings, and
then schedule the replication process. The mappings, column matching between
source and target, are done automatically but allow the user to drag and drop
target columns on the source—simplifying the process.
Because
replication can progress beyond the simple one-to-one / source-to-target
scenarios, DBMoto has a nice interface for grouping replications through their
multiple replication wizard—enabling a user to set source, target, and
scheduling details just once for a set of replications and reduce the required
maintenance. This can also optimize the number of database connections and
reduce overhead to access database logs as the database log would only be read
once for all replications as opposed to multiple times if the replications were
not grouped together. DBMoto also provides a way to customize replication
behavior by scripting with Visual Basic .NET.
Conclusion
Simple and effective is the best way I can
describe DBMoto. DBMoto is easy to set up, easy to configure,, and makes it easy
to replicate between the major platforms. The strongest point about DBMoto is
that it doesn’t require a user to understand replication technology for all the
major database environments. Replicating between Oracle, DB2, Informix, SQL
Server, etc. is basically all the same—just point click and shoot. With a wide
array of replicating options, scripting, and a nicely written user guide,
DBMoto can easily be configured for a variety of environments. You can obtain a
full working 30-day copy, with full support here: DBMoto
Evaluation Download.
