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 by using the MESSAGE APPEND REGISTER PUBLICATION statement, see MESSAGE APPEND.
For users to access a publication, they must have REFRESH privileges 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.
Note A replica database can only refresh from publications that are defined in the master database. A replica cannot use a publication that has been defined in the replica database itself. If a CREATE PUBLICATION statement is executed in the replica database, the publication definition is stored in the replica, but is not used unless the replica is also a master database for another tier in a multi-tiered replication topology.
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). For example:
The initial refresh is always a full publication and all data that meets the search criteria 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, it is recommended that you use incremental publications. Typically, only publication updates with the latest modifications need to be sent to a replica. For details about setting up tables to track modifications for incremental publication, see Creating incremental publications.
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. For more details about COMMITBLOCK, see "Setting the commit block size.
Note You can also restrict the resources that are available for the refresh operations by using the Synchronizer.ReplicaRefreshLoad parameter.
Combining subscribed and local data
A table on the replica can contain not only subscribed data, but also local data. To have rows for local use only in a replica database, the publications should have WHERE constraints that exclude the local rows. In this situation, the replica keeps the local rows in the table, and adds the subscribed data from the master database.
Dropping subscriptions
After the subscribed data becomes obsolete in the replica database, you can delete the subscribed data by using the DROP SUBSCRIPTION statement in the replica database. For details, see DROP SUBSCRIPTION.
Unregistering or dropping publication registrations
Registered publications can be unregistered in the replica database by using the MESSAGE APPEND UNREGISTER PUBLICATION statement. For example:
This must be part of a message that gets propagated to the master database.
Registered publication definitions can also be dropped in the replica database (without sending a message) by using the DROP PUBLICATION REGISTRATION statement, see DROP PUBLICATION REGISTRATION.
For example:
DROP PUBLICATION publ_customer REGISTRATION;
The DROP PUBLICATION REGISTRATION statement is meant only for situations where the replica database cannot communicate with the master database. If you drop a subscription without notifying the master database, then any system information for that subscription will remain on the master database and occupy space indefinitely. Most importantly, synchronization history data is gathered for this replica database even though the replica database does not use it. If possible, you should remove the synchronization history by using the DROP SUBSCRIPTION statement in the master database, see DROP SUBSCRIPTION.