Transactional Replication
Transactional replication typically starts with a snapshot of the publication database objects and data. When the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur. The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher.
Transactional replication is typically used in server-to-server environments and is appropriate in each of the following cases:
- You want incremental changes to be propagated to Subscribers as they occur.
- The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber.
- The application requires access to intermediate data states. For example, if a row changes five times, transactional replication permits an application to respond to each change, not only the net data change to the row.
- The Publisher has a very high volume of insert, update, and delete activity.
- The Publisher or Subscriber is a non-SQL Server database, such as Oracle.
By default, Subscribers to transactional publication should be treated as read-only, because changes are not propagated back to the Publisher. However, transactional replication does offer options that permit updates at the Subscriber. For more information, see Publication Types for Transactional Replication in SQL Server 2005 Books Online.
For information about implementing transactional replication, see Implementing Replication in SQL Server 2005 Books Online.
For information about common scenarios that involve transactional replication, see Replicating Data in a Server to Server Environment in SQL Server 2005 Books Online.
See Also
Concepts
Snapshot Replication
Merge Replication
Replication Components
Replication Considerations (SQL Server Express)