Pull Subscriptions
Pull subscriptions are created at the Subscriber, and the Subscriber requests data and updates made at the Publisher. Pull subscriptions allow the user at the Subscriber to determine when the data changes are synchronized, which can be on demand or scheduled.
Use pull subscriptions when:
- Administration of the subscription will take place at the Subscriber.
- The publication has a large number of Subscribers (for example, Subscribers using the Internet), and when it would be too resource-intensive to run all the agents at one site or all at the Distributor.
- Subscribers are autonomous, disconnected, and/or mobile. Subscribers will determine when they will connect to the Publisher/Distributor and synchronize changes.
Data will typically be synchronized on demand or on a schedule rather than continuously. One feature of pull subscriptions is that the Distribution Agent for snapshot and transactional publications and the Merge Agent for merge publications all run at the Subscriber. This can result in a reduction of the amount of processing overhead on the Distributor. However, if you need the Distribution Agent or Merge Agent to run at the Distributor, you can offload agent processing from the Subscriber.
For example, you might use this option if the Subscriber will determine when it is connected to the network and ready to synchronize, but you want to run the agent at the Distributor to make use of better processing power at the Distributor. For more information, see Remote Agent Activation.
Another feature of pull subscriptions is that members of the sysadmin or db_owner roles at the Subscriber decide which publications are received and when. Each Subscriber can have subscriptions to multiple publications at different Publishers.
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 Pull Subscription Wizard. You can create a pull subscription to any publication that has been enabled for pull subscriptions on a registered Publisher.
When you create a pull subscription, you specify:
- The name of the subscription database.
- Whether the Snapshot Agent should create an initial snapshot and the Distribution Agent or Merge Agent should apply that snapshot at the Subscriber.
- The location of the snapshot files to apply when initializing the subscription.
- The priority of the subscription for merge.
- 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).
- Whether the Distribution Agent or Merge Agent runs continuously, on demand, or on a scheduled basis.
- Services that will be started to create the subscription.
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 information about the subscription and the Subscriber is not stored.
When you create a pull subscription and a push subscription for the publication already exists for the Subscriber, an error message informs you that the push subscription already exists and that you should drop any push subscriptions before proceeding. When you create a pull subscription, and another pull subscription to the same publication already exists, you will be required to drop the existing subscription before adding the new one unless the first subscription has expired.
To create a pull or anonymous subscription
SQL-DMOTo view or modify pull or anonymous subscriptions
To delete a pull subscription