For the server to be able to do incremental refreshes on a table, the server must store some information about the most recent preceding refresh for that table. This refresh information is known as synchronization history data. The synchronization history data for each table is stored in a synchronization history table. There is one synchronization history table for each table in the publication.
In order to make a publication incremental, you must set the SYNCHISTORY property for each table with the ALTER TABLE statement, which tells the server to gather the synchronization history data for that table, see ALTER TABLE ... SET SYNCHISTORY
You must execute this statement for each table in the publication, and you must do so on both the master and replica databases.
By default, the SYNCHISTORY property for a table is set to NOSYNCHISTORY for each table. If this property is set to SYNCHISTORY in both the master and the replica databases, then after the first refresh, subsequent refreshes to a specific publication send the replica database only new and modified rows when the data in the table is synchronized.
It is recommended that you set the SYNCHISTORY property for a table before it is referenced by any publication. If you want to alter the SYNCHISTORY property for a table after it has been included as part of a publication, you need to use the Sync Maintenance Mode. For details, see Upgrading schemas in a distributed system by using Maintenance Mode features.
For example, to set the SYNCHISTORY property of the table named SYNCDEMO, use the statement:
ALTER TABLE SYNCDEMO SET SYNCHISTORY; COMMIT WORK;
This statement creates a shadow table called a synchronization history table, that stores history data.
The data in a history table is referred to when a replica database gets an incremental REFRESH from a publication in the master database. For example, if you delete the a record from the main table, a copy of the record is stored in the synchronization history table. When the replica database refreshes, the master database checks the history table and tells the replica database that the record was deleted. The replica database can then delete that record also. If the percentage of records that were deleted or changed is fairly small, an incremental update is faster than downloading the entire table from the master database. If you perform a full REFRESH, rather than an incremental REFRESH, the history table is not used. The data in the table on the master database is simply copied to the replica database.
Versioned data is automatically deleted from the database when there are no longer any replica databases that need the data to fulfill REFRESH requests.