Replica databases use refreshes to request publication data from the master. Refreshes depend on the publication definition in the master database. You must be sure that the replica registers publications so that they can be refreshed from.

Users are unable to refresh from publications that are not registered in the replica. Registering publications allows publication parameters to be validated.

Publications are registered in a replica using the MESSAGE APPEND REGISTER PUBLICATION statement. The syntax is:

For example:

For users to access a publication, they must have REFRESH privilege on the publication, and they must have privileges on the tables that are used in the publication. The table owners (or DBA) must grant privileges on the tables that are used in the publication, and the publication creator (or DBA) must GRANT REFRESH to give the user access rights on the publication. For details, see Implementing security through access rights and roles.

Publication data is requested from the master database as a publication call with a set of input parameter values (if they are used in the publication). The syntax is:

For example:

The initial “refresh” is always a full publication and all data meeting the search criterion of the publication is sent to the replica database. Subsequent refreshes for the same publication contain only the data that has been changed since the prior refresh. This is known as an incremental publication. To save resources and increase performance, we recommend that you use incremental publications. Typically, only publication updates with the latest modifications need to be sent to a replica. See Creating incremental publications for details on setting tables to track modifications for incremental publication.

When you use the keyword FULL with REFRESH, this forces the fetching of full publication data to the replica. If the publication is a large one, then the initial (non-incremental) download of the data to the replica database will make a large transaction. In such cases, the size of a single transaction of a synchronization message can be limited with the COMMITBLOCK option. See “Setting the commit block size for more details about COMMITBLOCK.

Tip: You can also restrict the resources available for the refresh operations by using the ReplicaRefreshLoad parameter.

A table on the replica may contain not only subscribed data, but also “local data”. To have rows for local use only at a replica, the publications should have “where” constraints that exclude the local rows. In this situation, the replica will keep the local rows in the table, and will add the subscribed data from the master.

After the subscribed data becomes obsolete in the replica, you can delete the subscribed data by dropping the subscription using the DROP SUBSCRIPTION command in the replica. For details, see Modifying publications and tables in publications.

Registered publications can be unregistered in the replica using the following command in a synchronization message:

For example:

This must be part of a message that gets propagated to the master.

Registered publication definitions can also be dropped in the replica without sending a message. The syntax is:

For example:

The DROP PUBLICATION REGISTRATION command is meant only for situations where the replica cannot communicate with the master. If you drop a subscription without notifying the master, then any system information for that subscription will remain on the master and use up space indefinitely. Most importantly, synchronization history data is gathered for this replica even though the replica will never use it. This causes bloating of the “shadow tables” related to the publication. If possible, you should manually release that system info by going to the master database and dropping the subscriptions using the following command: