Push Subscriptions

Push subscriptions can simplify and centralize subscription administration because you do not need to administer each Subscriber individually. The Distribution Agent or Merge Agent runs at the Distributor when synchronizing a push subscription. Push subscriptions are created at the Publisher, and the replication agents propagate data and updates to a Subscriber without a request from the Subscriber. Changes can also be pushed to Subscribers on a scheduled basis.

Use push subscriptions when:

• Data will typically be synchronized on demand or on a frequently recurring schedule.
  
  
• Publications require near real-time movement of data without polling.
  
  
• The higher processor overhead at a Publisher using a local Distributor does not affect performance.
  
  
• You need easier administration from a centralized location (the Distributor).

The centralized Distributor will establish the schedule on which connections will be made with remote, occasionally connected Subscribers. With push subscriptions, the Distribution Agent (for snapshot and transactional publications) or the Merge Agent (for merge publications) runs at the Distributor. However, if you need to offload agent processing from the Distributor but retain some of the benefits of easier administration, you can run the agent at the Subscriber. For more information, see Remote Agent Activation.

Because remote agent activation is available, the determining factors to consider when setting up subscriptions is what type you will need (push, pull, or anonymous) and where the replication agent will run.

Users who are members of the sysadmin or db_owner roles at that Subscriber can set up a push subscription. However, for a member of the db_owner role to set up a push subscription, a member of the sysadmin role must register the Subscribers.

For a subscription to be created, you must have a publication at the Publisher and a subscription database at the Subscriber. You can create the subscription database before creating the subscription, or specify a new subscription database in the Create Push Subscription Wizard. You can create a push subscription for any Subscribers that are enabled in the Publisher and Distributor properties.

Push subscriptions and pull subscriptions are known as named subscriptions because information about the subscription and the Subscriber is stored at the Publisher, and performance information about the Subscriber is stored at the Distributor. This is in contrast to anonymous subscriptions (which are a type of pull subscription) for which little or no information about the subscription and the Subscriber is stored.

When you create a push subscription, you specify:

• The name of the Subscriber.
  
  
• The name of the subscription database.
  
  
• Whether the Distribution Agent or Merge Agent runs at the Distributor (default) or at the Subscriber using remote agent activation.
  
  
• Whether the Distribution Agent or Merge Agent runs continuously, on a scheduled basis or on demand only.
  
  
• If the Snapshot Agent should create an updated initial snapshot for the subscription and if the Distribution Agent or Merge Agent should apply that snapshot at the Subscriber.
  
  
• For snapshot or transactional publications that allow immediate updating or queued updating, the options that this subscription will use (available if you enable advanced options in the Push Subscription Wizard).
  
  
• For merge replication, the priority value for the changes made in the subscription database to be used during conflict detection and resolution.
  
  
• For snapshot replication and transactional replication, specify that the subscription will use immediate updating, queued updating, or transform published data options (these must first be enabled when creating the publication).
  
  
• Services that will be started to create the subscription.

To create a push subscription