We’re excited about dbcompare because it comes out of the gate with some exciting features:

  • Compare any 2 databases, even if they are on different platforms. Have a customer table in SQL Server and a copy of that data in MySQL? Yep, dbcompare can compare the data.

  • Dbcompare can use your SymmetricDS config for an nice, automatic comparison of 2 of your nodes. This includes using table transforms that map table names and column names. So for example, if you have an H2 “transactions” table sync’ing up to a table called “TX_TRN” on Oracle, dbcompare can handle that comparison across different database platforms and table names.

  • Dbcompare is designed to be a standalone tool, as well, that can run on and compare 2 databases, even if those databases have nothing to do with SymmetricDS. Download a copy of SymmetricDS and use the dbcompare command line utility against the databases you want to compare.

  • Dbcompare generates a useful report that spells out the state of all tables, whether they are different or not.

  • The tool can also optionally general full SQL output that will will bring the target database into sync with the source database. So that’s all the INSERTs, UPDATEs, and DELETEs, with the correct formatting, syntax, etc. for the target database.

  • Dbcompare is part of the open source core of SymmetricDS.

Dbcompare could be a nice tool to set up a cron job for extra monitoring of your syncs, or something used for occasional troubleshooting.

Technically, dbcompare is a command line utility in the “bin” directory of the SymmetricDS installation. To run dbcompare, you will need two engines.properties files with database connection information. One properties file is the “source” database, and the other is the “target” of the comparison.

Here’s an example of running dbcompare for two source tables “transaction” and “sale_return_line_item”:

<symds>/bin/dbcompare transaction,sale_return_line_item -s ./path/to/source.properties -t ./path/to/target.properties --output_sql ./%t.diff.sql

Let’s break this down a little:

transaction,sale_return_line_item = a comma separated list of tables to include in the comparison. You can omit this if the source database uses SymmetricDS. If omitted, then dmcompare will run for all tables with SymmetricDS triggers.

-s = The source engines.properties file to use for the comparison. If you’re using SymmetricDS, just grab the engines.properties file from your engines folder, or point this to that file. If you are not using SymmetricDS, you’ll need to set up your DB connection info in a new properties file.

-t = This is the target engines.properties file for the comparison.

--output_sql = This specifies a file to write out SQL statements that would being the target database into sync with the source datasource. Note the use of “%t” in the name here. If you use that %t, you will get one .sql script per table, with the %t replaced with the table name.

Running this command generates a report (to standard out, which you can redirect > or pipe to file) and the SQL files.

Here’s an example of the report and SQL.

The 10 missing transactions server to create this TRN_TX.diff.sql:

Feel free to download dbcompare and try it out, or to contribute to our community site (http://www.symmetricds.org/download) . Let us know what you think!

View the source code here on githib:


Mark Michalek

I should have known I'd like working with data when I tried to use my i486 to catalog my hockey card collection. Fast forward and I've worked with data persistence, data replication, POS and Java in general for over 15 years. I've participated in the design and development of new products such as an enterprise-grade mobile POS, as well as led POS and SymmetricDS implementations. In my free time I like running, tinkering with Arduino robots with my kids, and antique cars.