The first time that a replica database refreshes from a publication in the master database, the replica database must download a copy of all the information in the publication (full refresh). After the first download, the replica only needs to download the records that have changed since the previous download (incremental refresh).

When synchronizing changed data from the master database to a replica database, both databases must know what data was written to these databases since the previous synchronization. If the data updates occurred, then the database must have a record of the previous version of the row before the update. The old versions of updated rows are stored in a synchronization history table.

After synchronization, a background process purges data (that is older than the most recent synchronization) from the history tables.

The use of incremental publications is highly recommended for optimum performance. For details on setting up incremental publications, see Creating incremental publications.

In a system where update operations are frequent (relative to how often the replica databases request refreshes), the history tables can grow large. By default, solidDB creates a new row in the history table whenever a row of the main table is updated in the master database. However, you can reduce the amount of data stored in the history table by specifying which columns of a synchronized table need to result in a new entry in the history table when data is changed. Only those columns in the publication that are used as search criteria (used in a WHERE clause or join columns) need to be specified as history columns; for technical details, see Using SET HISTORY COLUMNS.

If your publication definition contains all rows of a table, then specify the primary key columns as the HISTORY COLUMNS of that table by using the ALTER TABLE statement, see ALTER TABLE.

Without this definition, all update operations in the master database cause a new entry to the history table when the corresponding synchronized table is updated. If you have rows that are frequently updated, setting history columns can significantly reduce overhead in terms of performance and disk space consumption in the master database.

Assume you created the following table and enabled synchronization history:

You can now use the following statement to specify that the history entry occurs only if the accountid column value is changed by an update operation.

Now any changes to the balance column value do not cause a history table row update.