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.
Code2Solutions (11/6/2009)
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.