Jeff Moden (11/5/2009)
Most of it is all very, very fast because it uses BCP behind the scenes.
Are you sure, Jeff?
I know the initial snapshot uses BCP, but (unless it's changed radically since SQL 2000), I thought the transactions were then reconstructed as individual insert/update/delete statements for application to the subscriber. It replicates "transactions" (usually involving > 1 table), and therefore has to apply the changes in the same sequence they were done on the publisher.
Since transaction replication is written to the secondary database, does that mean that the entire secondary database is read-only?
No restrictions are placed on the secondary (subscriber) database... even for the tables being replicated.
The activity on the subscriber database can have a major impact on the latency.
If you run any heavy duty reports on the subscriber, you can easily lock rows/tables, delaying the distributor's attempts to update the subscriber.
Having said that, if you don't do much on the subscriber, then it's usually a pretty slick process.