Transactional replication typically starts with a snapshot of the publication database objects and data. As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time).
Transactional replication typically starts with a snapshot of the publication database objects and data.
As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time).
The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed.
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 allows an application to respond to each change (such as firing a trigger), not simply 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 publications should be treated as read-only, because changes are not propagated back to the Publisher. However, transactional replication does offer options that allow updates at the Subscriber.
Source: Transactional Replication
