Transactional replication is a problem

i have got transactional replication going on.
when i check the status on publisher database , publisher to distrubutor history shows perfefcely fine but distributor to subscriber is waiting since forever
and when i check the status on subscription/distributor side this is what i get
k

i disconnect from ssms and connect again using the server name instead of IP so the error message is gone,
but distributor to subscriber is still waiting for looooooooooooong time.
k

Similar Messages

Transactional replication from a failover cluster instance to a SQL Server Express DB

Hello,
I have been poking around on Google trying to understand if there are any gotchas in configuring transactional replication on a instance DB of a failover cluster, to a SQL Server Express DB. Also, this client would like to replicate a set of tables between
two instances DB's which both reside on nodes of the cluster.
Everything I've read suggests there is no problem using transactional replication on clustered instance as long as you use a shared snapshot folder. I still have some concerns:
1) Should the distributor need to live on a separate instance?
2) What happens in the event of an automatic, or manual failover of a publisher, especially if the distributor does not need to live on a separate instance? I know that when a failover occurs, all jobs in progress are stopped and this seems like a recipe for
inconsistency between the publisher and subscriber.
There is a paramount concern, that this particular client won't have staff on hand to troubleshoot replication if there are problems, hence my hesitancy to implement a solution that relies on it.
Thanks in advance.

1) Should the distributor need to live on a separate instance?
Answer: It is recommended to configure the distributor on the different server, but it also be configured on Publisher/subscriber server. (Subscriber in our case is not possible as its a Express edition)
2) What happens in the event of an automatic, or manual failover of a publisher, especially if the distributor does not need to live on a separate instance? I know that when a failover occurs, all jobs in progress are stopped and this seems like a recipe for
inconsistency between the publisher and subscriber. There is a paramount concern, that this particular client won't have staff on hand to troubleshoot replication if there are problems, hence my hesitancy to implement a solution that relies on it.
Answer: If you configure both publisher and distributor on the same server and the SQL instance is failed over, the data synchronization/replication is suspended till the instance comes online.
Once the instance is up,all the replication jobs will start again and it will continue to synchronize the data to subscriber. No manual intervention is required.

Transactional replication very slow with indexes on Subscriber table

I have setup Transactional Replication for one of our databases where one table with about 5mln records is replicated to a Subsriber database. With every replication about 500-600.000 changed records are send to the Subscriber.
Since one month I see very strange behaviour when I add about 10 indexes to the Subscriber table. As soon as I have added the indexes replication speed becomes extremely slow (almost 3 hours for 600k records). As soon as I remove the indexes the replication
is again very fast, about 3 minutes for the same amount of records.
I've searched a lot on the internet to solve this issue but can't find any explaination for this strange behaviour after adding the indexes. As far as I know it doesn't have to be a problem to add indexes to a Subscriber table, and it hasn't been before on
another replication configuration we use.
Some information from the Replication Log:
With indexes on the Subscriber table
Total Run Time (ms) : 9589938 Total Work Time : 9586782
Total Num Trans : 3 Num Trans/Sec : 0.00
Total Num Cmds : 616245 Num Cmds/Sec : 64.28
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 9580752
Time Spent on Commits (ms): 2687 Commits/Sec : 0.00
Time to Apply Cmds (ms) : 9586782 Cmds/Sec : 64.28
Time Cmd Queue Empty (ms) : 5499 Empty Q Waits > 10ms: 172
Total Time Request Blk(ms): 5499
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 10378 Cmds/Sec : 59379.94
Time Cmd Queue Full (ms) : 9577919 Full Q Waits > 10ms : 6072
Without indexes on the Subscriber table
Total Run Time (ms) : 89282 Total Work Time : 88891
Total Num Trans : 3 Num Trans/Sec : 0.03
Total Num Cmds : 437324 Num Cmds/Sec : 4919.78
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 86298
Time Spent on Commits (ms): 282 Commits/Sec : 0.03
Time to Apply Cmds (ms) : 88891 Cmds/Sec : 4919.78
Time Cmd Queue Empty (ms) : 1827 Empty Q Waits > 10ms: 113
Total Time Request Blk(ms): 1827
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 2812 Cmds/Sec : 155520.63
Time Cmd Queue Full (ms) : 86032 Full Q Waits > 10ms : 4026
Can someone please help me with this issue? Any ideas?
Pim

Hi Megens:
Insert statement might be slow with not only indexes and few others things too
0) SQL DB Blocking during inserts
1) If any insert triggers are existed
2) Constraints - if any
3) Index fragmentation
4) Page splits / fill factor
Without indexes inserts will be fast because, each time when new row going to insert to the table, SQL Server will do
1) it will check for the room, if no room page splits will happen and record will placed at right place
2) Once the record updated all the index should be update
3) all these extra update work will cause can make insert statement bit slow
Its better to have index maintenance jobs frequently to avoid fragmentation.
If every thing is clear on SQL Server Side, you need look up on DISK IO, N/W Latency between the servers and so on
Thanks,
Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue :)

Transactional Replication - Slow running sp_MSget_repl_commands

We are running transaction replication, with a publisher and a single subscriber located in different data centres. The distribution database is located with the subsciber.
We get high replication latency regularly, and during those times I have identified the bottleneck as the execution of sp_MSget_repl_commands by the distribution reader. Monitoring this thread in the DMV dm_exec_requests, it is consistently getting long waits
for wait_type ASYNC_NETWORK_IO.
Why would distribution reader by waiting on network? The thread and distribution database are all located on the same server. Is there something else that the distribution reader thread does that requires accessing the publisher?

Do you have a remote distributor?
Expect the ASYNC_NETWORK_IO wait type when the distribution agent is replicating over a wan/lan. Pull subscriptions may work better.
However, you need to determine what your latency is. If your replication latency is high, server minutes, or something which does not work for you - you have a problem. Otherwise it is just an inherent limit you can't do much about.
looking for a book on SQL Server 2008 Administration?
http://www.amazon.com/Microsoft-Server-2008-Management-Administration/dp/067233044X looking for a book on SQL Server 2008 Full-Text Search?
http://www.amazon.com/Pro-Full-Text-Search-Server-2008/dp/1430215941

Transactional Replication sp_MSupd RUNNABLE and never ends

Hello,
I came across not understandable problem connecting transactional pull replication. Once or twice a month I have a problem that stored procedure on subscription server (sp_MSupd) cannot be finished. It is not blocked by any other session and does not have
any wait type. It simply hangs and remains in task status RUNNABLE. The only one way to recover the replication is initilizing it from backup or snapshot. Do you have any suggestions. Have you faced similiar problem?

Hi, Lydia
Thank you for your reply. What do you mean that this is the "busy update on the publication". Could you please describe it in more details? Does it mean that on the publisher there was a huge update on a huge amount of rows? On the Publisher to
Distributor History I can see that there is no problem. All transactions are delivered without any delays (few seconds). But in Distributor to Subscriber History I have all actions completed in few seconds except the last one that hangs. How can I check if
it is the "busy update on the publication" problem? What should be done if it hangs more than few hours?
I found out that sp_MSget_repl_commands hangs on Publisher for remote Subscriber. It hangs with ASYNC_NETWORK_IO
Hi KirKuz,
I originally mean distribution agent reader &writer latency issue, and you can use SQL profiler or DMVs to examine in detail the Transaction Replication, which is described in this
blog.
Regarding to ASYNC_NETWORK_IO, based on my research, it's simply waiting for something external to SQL. The drive with your distribution database might be a bottleneck of such issue, or maybe the distribution tables are getting too large. Please check your
disk performance, also check your indexes on the replication tables for fragmentation.
Here is a similar thread for your reference.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d0117651-f94c-488a-83e8-30038e38d510/transactional-replication-slow-running-spmsgetreplcommands?forum=sqlreplication
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support

Transactional Replication Not replicating non-clustered Indexes

Hi
I have created a transactional replication.I am sure that I have configured it to replicate Non-Clustered indexes,
but It does not do so.
I tried several times to reinitialize the subscription,but still no luck.
Regards

It is True for sure.
But the problem is solved.I had to wait until the Initialize process get completed.
But I am sure that this problem happened before.Sometimes it works fine but sometimes not.
Hi ArashMasroor,
According to your description, it seems that you encounter the issue that non-clustered indexes property is reset to “False” sometimes.
To work around this issue, you can use a post-replication SQL script to create the indexes. Whatever articles you’re publishing open up the indexes drop down list of the article in object explorer, right-click on an index and levitate over Script Index as,
then Create-to, then click New Query Window editor.
Up will pop up a new query window with the resulting index. Work your way through all the indexes on all the articles of the publication, copy and pasting just the create index line and below of each script, pull them all together into one query window.
Once you’re done find a safe folder somewhere on your hard drive and save the SQL query as an .sql file with a sensible name. Then you can execute this script after applying the Snapshot. For more details, please review this
blog.
There is also a similar thread for your reference.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b0f3870d-1a65-4384-a17b-96825ec5f098/transactional-replication-nonclustered-indexes-not-copying?forum=sqlreplication
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support

Snapshot Error When Adding Article to Transactional Replication

I am trying to add an table articles to my transactional replication setup.   When I do, the snapshot error fails with the following message:
Source: Microsoft.SqlServer.Smo
Target Site: Microsoft.SqlServer.Management.Smo.SqlSmoObject GetSmoObject(Microsoft.SqlServer.Management.Sdk.Sfc.Urn)
Message: Attempt to retrieve data for object failed for Server '<servername>'.
Stack:    at Microsoft.SqlServer.Management.Smo.Server.GetSmoObject(Urn urn)
   at Microsoft.SqlServer.Replication.Snapshot.SmoScriptingManager.BuildSmoObjectArrayAndUrnLookupTable(IDictionary& dictUrnKeyArticleScriptingBundles)
   at Microsoft.SqlServer.Replication.Snapshot.SmoScriptingManager.DoScripting()
   at Microsoft.SqlServer.Replication.Snapshot.SqlServerSnapshotProvider.DoScripting()
   at Microsoft.SqlServer.Replication.Snapshot.SqlServerSnapshotProvider.GenerateSnapshot()
   at Microsoft.SqlServer.Replication.SnapshotGenerationAgent.InternalRun()
   at Microsoft.SqlServer.Replication.AgentCore.Run() (Source: Microsoft.SqlServer.Smo, Error number: 0)
Get help: http://help/0
Source: Microsoft.SqlServer.Smo
Target Site: Microsoft.SqlServer.Management.Smo.ObjectKeyBase CreateKeyFromUrn(Microsoft.SqlServer.Management.Sdk.Sfc.Urn)
Message: The input Urn must specify Name at level UserDefinedFunction.
Stack:    at Microsoft.SqlServer.Management.Smo.SchemaCollectionBase.CreateKeyFromUrn(Urn urn)
   at Microsoft.SqlServer.Management.Smo.Server.GetSmoObjectRec(Urn urn)
   at Microsoft.SqlServer.Management.Smo.Server.GetSmoObject(Urn urn) (Source: Microsoft.SqlServer.Smo, Error number: 0)
Get help: http://help/0
Specifics:
Transactional replication: Both Immediate Sync and Allow Anonymous are set to 0.
Publisher and Distributer are same server: SQL Server Standard 2008 R2 (10.50.4000.0) on Windows 2008 R2 SP1
If I add even one table article (doesn't matter, I've tried different ones), I get the error above when I run the snapshot agent.
If I remove the table just added and rerun the snapshot agent, it succeeds with the message "A snapshot was not generated because no subscriptions needed initialization", so at least I don't have to reinitialize (thank goodness!).
Any ideas as to what might be causing this, and how I can add articles to my existing publication?
Thanks in advance for your help.

Hi John V.Barone,
I’m writing to follow up with you on this post. Was the problem resolved after performing our action plan steps? If not, according to your error message, we need to verify if it is caused by replicating Meta Data corruption. You can check if there is a bad
row
in “sysarticles” (for a table) or “sysschemaarticles” (for a UDF) for which we do not have a corresponding “ObjectId” in sysobjects . If yes, delete
manually this row
from Published (sysarticles, sysschemaarticles, syssubscriptions) and Distribution DB (MSsubscriptions,sysschemaarticles,MSarticles).
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

Transaction replication blocking

Hello,
I am seeing that transaction replication inserts are causing a lot of blocking in the subscriber database. The blocked statements are select statements. Does Transaction replication lock tables when it inserts?Can this blocking be prevented?
Thanks

Best way to handle this is either decrease the commitbatchsize and commitbatchsizethresholds on the distribution agent profile, or the use the snapshot isolation level (READ_COMMITTED_SNAPSHOT)
on your subscriber database.
You might want to also change the fill factor on the problem tables, examine the indexes there to see if they are used, and then examine the blocking workload to see if there is anything you can do to reduce its impact. Indexing may help.
Replication may cause blocking, especially if more than 5000 rows are being inserted in a batch. Disabling lock escalation will help here - if table level locks are being held. Disabling lock escalation is not always a good thing to do - you will need to
carefully examine locking/blocking to determine what your best approach is.
looking for a book on SQL Server 2008 Administration?
http://www.amazon.com/Microsoft-Server-2008-Management-Administration/dp/067233044X looking for a book on SQL Server 2008 Full-Text Search?
http://www.amazon.com/Pro-Full-Text-Search-Server-2008/dp/1430215941

Dropping existing subscriber from a pualisher who has multiple subscriber in Transactional Replication

Hi Everyone,
We have a transactional replication(one publisher and multiple subscribers). If I drop one of subscribers, will this cause any locking or performance problem for publisher or other subscribers? I am going to do that using SSMS.
Thanks
Aspet
A.G

Hi Mourmansk,
Agree with others，In addition, before you deleting Subscriber, we need to verify that Publisher define a source database where replication starts, Subscriber is the destination database where replication ends. If you want to drop a Subscriber, it means that
you should delete the related pull subscription or push subscription in transaction replication. Usually, for example, to delete a push subscription, you use
sp_dropsubscription on the publication database, and execute sp_subscription_cleanup to remove replication metadata in the subscription database. There is a similar issue about delete subscriber from replication, you can review it.
http://social.technet.microsoft.com/Forums/en-US/1354e29f-4904-46dd-8e64-d1150263ba7c/unable-to-drop-subscriber-from-replication?forum=sqlreplication
For more information, see：http://msdn.microsoft.com/en-us/library/ms151212.aspx
http://msdn.microsoft.com/en-us/library/ms151861.aspx
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

Noncovergence in transactional replication with updatable subscription

Hello all,
I have a Transactional replication with updatable subscription setup having 1 publisher and 3 subscribers. All the servers are SQL 2008 and have conflict resolution
policy set as subscriber wins. Of late, I have been observing data mismatch for few tables. Some tables have records but their column values doesn't match. Some records are there on one subscriber but missing on publisher and other subscribers. However replication
is running fine without any issue. I am trying to understand what could have caused this issue and how it could be avoided in future.
Do you guys have any idea what might be causing this and how to fix this?
Let me know if you need any further details.
FYI: There is no filter defined for any articles in replication.
Thanks,
Nainesh.

If these problem rows do not show up as conflicts you will need to create audit tables and triggers to determine why these rows are not being picked up for replication.
looking for a book on SQL Server 2008 Administration?
http://www.amazon.com/Microsoft-Server-2008-Management-Administration/dp/067233044X looking for a book on SQL Server 2008 Full-Text Search?
http://www.amazon.com/Pro-Full-Text-Search-Server-2008/dp/1430215941

SQL Server 2008 R2 Transaction Replication Tracer Tokens always pending

On a new transaction replication publiciation/subscription, the tracer tokens I generate always show pending for publisher to distributor and distributor to subscriber. The log reader agent is running and last action continues to update. The
Performance column in the repl monitor shows Excellent with a 00:00:03 latency. Distribution cleanup, agent history clean up, and replication agents checkup all show job succeeded and a resent last start time and their running times are usualy around
a second or show 00:00:00. On the subscriber, the "view synchronization status" is being updated with number of transactions and commands being delivered. I can confirm that updates are making it to the subscriber database. On
the surface, everything apears ok but I'm bothered by the tracker tokens not working.
this is SQL Server 2008 R2 10.50.1600.1 - OS is Windows Server 2008 R2 SP1.
-Larry
-Larry

In this case run sp_replcounters at the published db to see if the log reader delivers commands from the published db to the distribution db.
Yaniv Etrogi
site |
blog | linked in |
mail
Please click the Mark as Answer button if a post solves your problem! or
Vote As Helpful

Peer-to-Peer Transactional Replication (three or more participating databases): What if all the nodes are working at the same time

In the topologies that have three or more participating databases.
What if all nodes are working at the same time? "The topology is not partitioned by time.".
location 1 will do insert/update/delete/read in the same time location 2 also will do insert/update/delete/read .......
**Data that will be added by each location is different(each location has its own primary key ranges).
Is it recomended to use Peer-to-Peer Transactional Replication in such scinarios?

Read these
https://msdn.microsoft.com/en-us/library/ms151196.aspx
http://www.brentozar.com/archive/2012/01/highly-available-local-replication/
The only problem that you have to tackle is what happens when the same data is being updated in multiple locations at the same time. If that is not a possibility with you then p2p is a good choice. Check the above links you will have a better understanding.
Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

Invalid rowid error while running the snapshot agent in transactional replication

Hi All,
I am getting an Invalid rowid error while replicating an large tables i.e around 30 millions rows from oracle(publisher) to sql server(Subscriber) while running the snapshot agent in transactional replication.
Its taking around 18 hours and its then its throwing this error.
Is there any faster way that i can replicate the initial snapshot this large table as 18 hours is very high on time.
Kindly suggest.i am always got quick and accurate response always..hope the same in this case also.
Thanks,

Hi,
Could you please create a replication with some small tables for a test?
You can disable the firewall on both sides and rerun snapshot. Enable verbose logging to level 4 for snapshot agent and check the results if it fails.
http://support.microsoft.com/kb/312292
Here is a document says for the error: ORA-10632: Invalid rowid Cause: Segment Highwatermark was overwritten due to shrink and space reused Action: Reissue this command.
I also suggest you contact the Oracle support team for further help.
Thanks.
Tracy Cai
TechNet Community Support

Error while setting up Transactional Replication

Hi Team,
I am getting below error while configuring Transactional Replication.
Specifically, when I started configuring the distributor that when I am getting below error. I am getting this in GUI as well TSQL script as well.
SQL Server could not configure 'TEST-PC\SQL2K8' as a Distributor.
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Destination path D:\SQL2K8DATA is not valid. Unable to list directory contents. Specify a valid destination path.
Changed database context to 'master'. (Microsoft SQL Server, Error: 14430)
Background of the error.
========================
I installed 3 sql instances of "SQL Server 2008 Developer edition, SP3 (x64)".
I started configuring a remote distributor using one of the instance and error started popping up.
Initially I had the replication running fine and I removed it and tried to reconfigure distributor thats when the error starting popping up.
The folder physically exists and the service account has full permissions and I have logged in as service account and trying to setup Transactional Replication.
He is local administrator on the box and also sysadmin login at sql server level.
Not sure why this error is popping up.....
After wasting a lot of time. I tried to install 3 new fresh instances with same service pack level i.e. sp3, but still the error remains the same.
Appreciate if anyone can guide me resolving this issue.
Thank you.

Hi Brandon,
I generated the script and tried again. No Luck. It is throwing error at creation of distribution database itself i.e. exec sp_adddistributiondb .
/****** Scripting replication configuration. Script Date: 2/25/2014 11:43:31 AM ******/
/****** Please Note: For security reasons, all password parameters were scripted with either NULL or an empty string. ******/
/****** Installing the server as a Distributor. Script Date: 2/25/2014 11:43:31 AM ******/
use master
go
exec sp_adddistributor
@distributor = N'TEST-PC\S2',
@password = N'123'
GO
exec sp_adddistributiondb
@database = N'distribution',
@data_folder = N'C:\Program Files\Microsoft SQL Server\MSSQL10.S2\MSSQL\Data',
@log_folder = N'C:\Program Files\Microsoft SQL Server\MSSQL10.S2\MSSQL\Data',
@log_file_size = 2,
@min_distretention = 0,
@max_distretention = 72,
@history_retention = 48,
@security_mode = 1
GO
Error Message :
Msg 14430, Level 16, State 1, Procedure sp_adddistributiondb, Line 227
Destination path C:\Program Files\Microsoft SQL Server\MSSQL10.S2\MSSQL\Data is not valid. Unable to list directory contents. Specify a valid destination path.
use [distribution]
if (not exists (select * from sysobjects where name = 'UIProperties' and type = 'U '))
   create table UIProperties(id int)
if (exists (select * from ::fn_listextendedproperty('SnapshotFolder', 'user', 'dbo', 'table', 'UIProperties', null, null)))
   EXEC sp_updateextendedproperty N'SnapshotFolder', N'\\TEST-PC\repldata', 'user', dbo, 'table', 'UIProperties'
else
   EXEC sp_addextendedproperty N'SnapshotFolder', N'\\TEST-PC\repldata', 'user', dbo, 'table', 'UIProperties'
GO
exec sp_adddistpublisher @publisher = N'TEST-pc\s1',
@distribution_db = N'distribution',
@security_mode = 1,
@working_directory = N'\\TEST-PC\repldata',
@trusted = N'false',
@thirdparty_flag = 0,
@publisher_type = N'MSSQLSERVER'
GO

Running transactional replication on SQL server 2008R2 but: "The process could not connect to subscriber 'SERVER NAME'"

I've set up Replication (transactional replication) between two remote servers. On the one of server that I configure Distribution & publication .another server is subscription. The subscription is all set & snapshot agent is started .but the actual
replication doesn't take place.
When viewing the Synchronization Status of the subscription, i get an error, saying "The process could not connect to Subscriber ‘Server name'."
Clicking on start, this is the error message I get:
The agent could not be started.
Additional information:
An exception while executing a Transact-SQL statement or batch.
SQL Server Agent Error: Request to run job Server1-EDUSRV-Pubs-Server2-14 (from User Server1\Administrator) refused because the job is already running from a request by User sa.
Change database context to 'EDUSRV'.(Microsoft SQL Server Error:22022)
What can i do?
Please help me.Thanks

The error The process could not connect to Subscriber 'Server name' indicates that the Distribution Agent process account does not have enough permissions to connect to the Subscriber.
If this is a push subscription, verify the Distribution Agent process account is db_owner in the distribution and subscription databases, is a member of the PAL, and has read permissions on the snapshot share.
If this is a pull subscription, verify the Distribution Agent process account is db_owner in the subscription database, is a member of the PAL, and has read permissions on the snapshot share.
The permissions required are covered in
Replication Agent Security Model.
If you have anymore questions, please let me know. I hope this helps.
Brandon Williams (blog |
linkedin)

Transactional replication is a problem

Similar Messages

Maybe you are looking for