If a subscription has not materialized, follow the general procedure in this section. See Chapter 5, “Subscription Problems”, for specific instructions.
Procedure if subscription has not materialized
If you are materializing a large amount of data, make sure the num_threads and num_concurrent_subs parameters are large enough.
Log in to the destination Replication Server and check subscription status using check subscription. Do the same for the primary Replication Server. check subscription returns information that diagnoses the problem. The potential problems that check subscription returns information about include:
Other subscriptions to the same replication definition and replicate database have not yet processed
No connection to the primary Replication Server because of an incorrect login
Primary Replication Server down or out of stable queues
Stable Queue Manager (SQM), Stable Queue Transaction interface (SQT), and Distributor (DIST) threads down
Primary data server down, incorrect login, out of stable queues, or rows selected with holdlock
RepAgent problem
Route problem
Destination Replication Server— incorrect login or out of stable queues
Destination Replication Server DSI problem—use admin who, dsi or admin who, sqm to determine what the specific problem is
Incorrect user privileges on destination database
Use rs_helppub and rs_helppubsub to find the publications and articles that a subscription is using.
If only some columns in the table are not being materialized:
Check replication status of text, unitext, and image columns.
Verify that the replication definition is correctly defined.
Verify that the publications and articles are correctly defined.
Fix the problem.
When you think you have solved the problem, run the replication system. If subscriptions are still not being materialized correctly:
Analyze errors (see “Analyzing error logs”), or
Complete any of this section’s procedures that you skipped.
