Troubleshooting
Replication FAQ
How do you view the commands for transactions marked for replication in the transaction log of the publishing database in a readable format?
Answer:
Use the stored procedure sp_replshowcmds. to view transactions that currently are not distributed (those transactions remaining in the transaction log that have not been sent to the Distributor). sp_replshowcmds can be run only when client connections (including the current connection) are not reading replicated transactions from the log. Hence, the Log Reader Agent needs to be stopped for this procedure to be run. This stored procedure is executed at the Publisher on the publication database.
Note sp_replshowcmds should be run only to troubleshoot problems with replication.
When is the MSreplication_subscriptions table created on the Subscriber?
Answer:
The Distribution Agent creates the MSreplication_subscriptions table at startup if the table does not already exist. Alternately, the sp_addpullsubscription stored procedure creates the MSreplication_subscriptions table if the table does not already exist on the Subscriber.
What .exe or .dll file is called for each agent?
Answer:
This table shows the agent names and associated files.
| Agent name |
File name |
| Log Reader Agent |
Logread.exe |
| Snapshot Agent |
Snapshot.exe |
| Distribution Agent |
Distrib.exe |
| Queue Reader Agent |
Qrdrsvc.exe |
| Merge Agent |
Replmerg.exe |
Note The Snapshot Agent, the Distribution Agent, and the Merge Agent can also be invoked through the Sqlinitx.dll, Sqldistx.dll and Sqlmergx.dll Microsoft® ActiveX® interfaces respectively.
When do I need multiple distribution databases?
Answer:
In most cases, you need only one. This feature is for users who are centralizing replication operations and administration and want one distribution server to host many Publishers. You can support many Publishers to one distribution database. However, there may be cases in which you want to separate logical replication applications into separate databases for administration purposes. In this case, use multiple distribution databases. Multiple distribution databases may also provide a performance benefit by reducing contention (both writing to and reading from the distribution database).
Can all servers in a merge setup have the same priority?
Answer:
The Publisher and the Subscriber can never have the same priority. Microsoft SQL Server™ 2000 enforces this while adding subscriptions. However, if there are two subscriptions (for example, S1 and S2) that have the same priority, the first subscription that propagates changes to the Publisher wins. For example, if S1 and S2 make changes simultaneously, the first one to merge changes with the Publisher wins. The same rule applies to local subscriptions, which essentially have a priority of 0 (the first one to the hub wins).
Synchronizing on Internet publications fails with the error "Couldn't deliver schema information." Why?
Answer:
It is possible that the file copy operations failed. By default, agents used with pull subscriptions use the Universal Naming Convention (UNC) path set for the Distributor and Publisher to open the files. If the computer is not on the Local Area Network (LAN), UNC will not work. You can set up a File Transfer Protocol (FTP) server at the Distributor and set the Merge Agent command line to include an FTP address. Publications enabled for the Internet will have the initial snapshot downloaded to the client computer by the Merge Agent through FTP before it is applied to the Subscriber.
I used the Disable Publishing And Distribution Wizard, and the physical files for the distribution database persisted on my hard disk. Is this by design? When I reinstall replication, what will happen?
Answer:
When you remove distribution, SQL Server attempts to remove the physical files. However, if other clients are using the distribution database or if there is a sharing violation when the file is being deleted, the file will not actually be removed from the hard disk. If the physical file is not removed and you try to install distribution again, a new name will be used for the distribution database.
If I create a publication with one table as an article, and then change the schema of the published table (for example, by adding a column to the table), will the new schema ever be applied at the Subscribers?
Answer:
Yes. The new schema will be applied at the Subscribers, provided schema changes to the published table were made through the replication publication properties dialog box in SQL Server Enterprise Manager or through replication stored procedures. Do not make schema changes to published tables using the SQL ALTER TABLE statements in a tool such as SQL Query Analyzer or by using SQL Server Enterprise Manager visual database tools. Changes made to the schema of a published table using these tools will not be propagated to Subscribers.
For more information, see Schema Changes on Publication Databases.
What is a good way to see the commands in MSrepl_commands?
Answer:
Execute the stored procedure sp_browsereplcmds at the Distributor on the distribution database.
What if the Snapshot Agent has not completed when the Distribution Agent starts?
Answer:
This is not a problem if the Distribution Agent runs at the same time as the Snapshot Agent. However, if the Distribution Agent runs and there is no snapshot available, it will shut down with a message stating that a snapshot is not yet available, unless it has been configured to run continuously. In that case, the Distribution Agent waits for the Snapshot Agent to finish.
On Windows 2000 Server, transactional replication is unavailable. Why?
Answer:
Microsoft SQL Server 2000 Personal Edition and Microsoft SQL Server 2000 Desktop Engine can be used only as a transactional replication Subscriber. These editions can be installed on any platform.
Using immediate updating subscriptions, the published table is altered. Why?
Answer:
In SQL Server 2000, tables used in publications that allow immediate updating are required to have a SQL Server uniqueidentifier column. If one does not exist, SQL Server 2000 adds one automatically when you create the publication. If you stop publishing a table, you can drop the uniqueidentifier column. Applications will work unchanged against tables with the uniqueidentifier column because you do not have to include this column in qualified INSERT, UPDATE, or DELETE statements.
See Also
Help with Replication