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
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, read Implementing security through access rights and roles.
Note A replica can only refresh from publications that are defined in the master. A replica cannot use a publication that has been defined in the replica database itself. If a CREATE PUBLICATION command is executed in the replica database, the publication definition is stored in the replica, but it not used unless the replica is also a master to another tier in a hierarchy of three or more tiers.
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:
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. Read 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.
Combining subscribed and local data
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.
Dropping subscriptions
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, refer to Modifying publications and tables in publications.
Unregistering or dropping publication registrations
Registered publications can be unregistered in the replica using the followingcommand in a synchronization message:
This must be part of a message that gets propagated to the master.
Registered publication definitions can also be dropped in the replica withoutsending a message. The syntax is:
DROP PUBLICATION publication_name REGISTRATION
For example:
DROP PUBLICATION publ_customer REGISTRATION;
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: