Transactional replication update causing deadlock

Hello,
I am using sql server 2012 SE. I am using Transactional replication and noticed that we have been receiving deadlocks lately. The select statement that is inserting data into a temptable is getting deadlocked by the transactionalreplication update statement.
I am in the process of avoiding this deadlock. Is adding any missing index is the only solution here? PLease find the deadlock information below:
3/13/2015 11:03:17,spid3s,Unknown,waiter id=process85b6b2928 mode=IX requestType=wait
03/13/2015 11:03:17,spid3s,Unknown,waiter-list
03/13/2015 11:03:17,spid3s,Unknown,owner id=process505246558 mode=S
03/13/2015 11:03:17,spid3s,Unknown,owner-list
03/13/2015 11:03:17,spid3s,Unknown,pagelock fileid=1 pageid=8285871 dbid=6 subresource=FULL objectname=PaigahDB.dbo.EmailLogs id=lock73c690280 mode=S associatedObjectId=72057594176077824
03/13/2015 11:03:17,spid3s,Unknown,waiter id=process505246558 mode=S requestType=wait
03/13/2015 11:03:17,spid3s,Unknown,waiter-list
03/13/2015 11:03:17,spid3s,Unknown,owner id=process85b6b2928 mode=IX
03/13/2015 11:03:17,spid3s,Unknown,owner-list
03/13/2015 11:03:17,spid3s,Unknown,pagelock fileid=1 pageid=8286764 dbid=6 subresource=FULL objectname=PaigahDB.dbo.EmailLogs id=lock3d4201500 mode=IX associatedObjectId=72057594176077824
03/13/2015 11:03:17,spid3s,Unknown,resource-list
03/13/2015 11:03:17,spid3s,Unknown,Proc [Database Id = 6 Object Id = 323532236]
03/13/2015 11:03:17,spid3s,Unknown,inputbuf
03/13/2015 11:03:17,spid3s,Unknown,[FullName] = case substring(@bitmap<c/>2<c/>1) & 8 when 8 then @c12 else [FullName] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[LastName] = case substring(@bitmap<c/>2<c/>1) & 4 when 4 then @c11 else [LastName] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[FirstName] = case substring(@bitmap<c/>2<c/>1) & 2 when 2 then @c10 else [FirstName] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[AddressOrder] = case substring(@bitmap<c/>2<c/>1) & 1 when 1 then @c9 else [AddressOrder] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[EmailType] = case substring(@bitmap<c/>1<c/>1) & 128 when 128 then @c8 else [EmailType] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[AddressContactAttempts] = case substring(@bitmap<c/>1<c/>1) & 64 when 64 then @c7 else [AddressContactAttempts] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[Address] = case substring(@bitmap<c/>1<c/>1) & 32 when 32 then @c6 else [Address] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[Timestamp] = case substring(@bitmap<c/>1<c/>1) & 16 when 16 then @c5 else [Timestamp] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[LogStatus] = case substring(@bitmap<c/>1<c/>1) & 8 when 8 then @c4 else [LogStatus] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[JobID] = case substring(@bitmap<c/>1<c/>1) & 4 when 4 then @c3 else [JobID] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,[EmailAddressID] = case substring(@bitmap<c/>1<c/>1) & 2 when 2 then @c2 else [EmailAddressID] end<c/>
03/13/2015 11:03:17,spid3s,Unknown,update [dbo].[EmailLogs] set
03/13/2015 11:03:17,spid3s,Unknown,frame procname=PaigahDB.dbo.sp_MSupd_dboEmailLogs line=52 stmtstart=4900 stmtend=8184 sqlhandle=0x03000600ccb54813d9b8250031a4000001000000000000000000000000000000000000000000000000000000
03/13/2015 11:03:17,spid3s,Unknown,executionStack
03/13/2015 11:03:17,spid3s,Unknown,process id=process85b6b2928 taskpriority=0 logused=793868 waitresource=PAGE: 6:1:8285871 waittime=1805 ownerId=591093165 transactionname=user_transaction lasttranstarted=2015-03-13T11:03:07.047 XDES=0x8fbb7cd28 lockMode=IX
schedulerid=2 kpid=1496 status=suspended spid=70 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2015-03-13T11:03:15.870 lastbatchcompleted=2015-03-13T11:03:15.867 lastattention=1900-01-01T00:00:00.867 clientapp=webapp_rep_10032014 hostname=DBServer
hostpid=3112 loginname=dom\user isolationlevel=read committed (2) xactid=591093165 currentdb=6 lockTimeout=4294967295 clientoption1=671156320 clientoption2=128056
03/13/2015 11:03:17,spid3s,Unknown,Proc [Database Id = 17 Object Id = 853578079]
03/13/2015 11:03:17,spid3s,Unknown,inputbuf
03/13/2015 11:03:17,spid3s,Unknown,where el.[Timestamp] between ji.LastExportTime and @currentExportTime;
03/13/2015 11:03:17,spid3s,Unknown,join PaigahDB.dbo.EmailLogStatuses es on el.LogStatus = es.EmailLogStatusID
03/13/2015 11:03:17,spid3s,Unknown,join PaigahDB.dbo.EmailLogs el on el.JobID = ji.EmailJobId
03/13/2015 11:03:17,spid3s,Unknown,from #JobIds ji
03/13/2015 11:03:17,spid3s,Unknown,select 'EMAIL'<c/> el.EmailLogID<c/> el.ImportPersonId<c/> el.JobID<c/> el.Timestamp<c/> es.Details<c/> es.Name<c/> el.AddressContactAttempts<c/> null<c/> null<c/>
el.LogStatus<c/> es.Details<c/> el.EmailLogIdentity
03/13/2015 11:03:17,spid3s,Unknown,(MessageType<c/> LogId<c/> ImportPersonId<c/> JobId<c/> [Timestamp]<c/> Details<c/> Name<c/> NumberContactAttempts<c/> Number<c/> PatientResponse<c/> LogStatusID<c/>
LogStatus<c/> LogIdentity)
03/13/2015 11:03:17,spid3s,Unknown,insert into #LogFlexes
03/13/2015 11:03:17,spid3s,Unknown,frame procname=PlazaDB.dbo.GetJobResults line=111 stmtstart=7788 stmtend=9074 sqlhandle=0x030011005f91e032b241de0050a4000001000000000000000000000000000000000000000000000000000000
03/13/2015 11:03:17,spid3s,Unknown,executionStack
03/13/2015 11:03:17,spid3s,Unknown,process id=process505246558 taskpriority=0 logused=0 waitresource=PAGE: 6:1:8286764 waittime=7082 ownerId=591097183 transactionname=INSERT lasttranstarted=2015-03-13T11:03:10.667 XDES=0x8f5b68d28 lockMode=S schedulerid=1
kpid=5128 status=suspended spid=188 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2015-03-13T11:03:10.397 lastbatchcompleted=2015-03-13T11:03:10.397 lastattention=2015-03-13T10:52:07.350 clientapp=.Net SqlClient Data Provider hostname=GW-W hostpid=5468
loginname=abc\admin isolationlevel=read committed (2) xactid=591097183 currentdb=17 lockTimeout=4294967295 clientoption1=673185824 clientoption2=128056
03/13/2015 11:03:17,spid3s,Unknown,process-list
03/13/2015 11:03:17,spid3s,Unknown,deadlock victim=process505246558
03/13/2015 11:03:17,spid3s,Unknown,deadlock-list
Experts I need your valuable inputs.
Thanks a ton

This is what I would do.
Check when update statistics were ran last time?
Check for any fragmentation on tables?
Turn on trace flag 1204, 1222
Use deadlock graph, deadlock chain and narrow down the statements and tune them.
See below link which might be useful.
https://www.simple-talk.com/sql/performance/sql-server-deadlocks-by-example/

Similar Messages

Unecessary use of SELECT...FOR UPDATE causing Deadlock

DB version:10gR2
We are getting a deadlock issue frequently. When i looked at the trace file i found that the Rolled back SQL and the Successfull SQL are both SELECT FOR UPDATE statements. They both are declared before UPDATE statments.
Both of these PL/SQL codes are developed by a C++ guy. When is it appropriate to use SELECT ..FOR UPDATE. I've seen SELECT ...FOR UPDATE very rarely in the codes developed by PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE to lock rows before UPDATE/DELETE/INSERT in their codes?

For update is a rowlevel locking. like
Session 1
SQL> conn scott/tiger
Connected.
SQL> select * from emp;
 EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
 7369 SMITH CLERK 7902 17-DEC-80 800 20
 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
 7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
 7566 JONES MANAGER 7839 02-APR-81 2975 20
 7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
 7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
 7782 CLARK MANAGER 7839 09-JUN-81 2450 10
 7788 SCOTT ANALYST 7566 19-APR-87 3000 20
 7839 KING PRESIDENT 17-NOV-81 5000 10
 7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
 7876 ADAMS CLERK 7788 23-MAY-87 1100 20
 EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
 7900 JAMES CLERK 7698 03-DEC-81 950 30
 7902 FORD ANALYST 7566 03-DEC-81 3000 20
 7934 MILLER CLERK 7782 23-JAN-82 1300 10
14 rows selected.
SQL> select * from emp where empno = 7369 for update;
 EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
 7369 SMITH CLERK 7902 17-DEC-80 800 20
SQL>
Session 2
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> update emp set sal = 1000 where empno = 7900
2 /
1 row updated.
SQL> commit;
Commit complete.
SQL> update emp set sal = 1000 where empno = 7369
2
SQL> /In session 1 we have lock row where empno = 7369 & in session 2 we are updating salary where empno = 7900 it is updating successfully, but we are updating a empno = 7369 then session 2nd hangs for waiting for the next session.
Also read the Link (http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html)

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

Transaction replication DML [update] operation not allowing

We are configuration the transaction replication from production to DR site, while I am trying to perform the DML [update] operation in publication database, DML [update] operation not allowing.
Note: How we can perform DML [update] operation in publication database.

Hi MSDN_12345,
According to your description, after configuring
SQL Server transaction replication between two different Servers successfully. We can execute the update commands on Publisher Server. In theory, after updating the publication database, we also sync the data to the subscription database.
For more information, see:
http://msdn.microsoft.com/en-us/library/ms152754.aspx
So as other post, please post more details for analysis.
If the update command was not allowed to perform, we need to verify if your account has the related permission on the publication table, such as update permission, select permission and so on. Usually, the members of the sysadmin fixed server
role, the db_owner and db_datawriter fixed database roles, have update permissions.
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

Cannot see Transaction replication with updatable subscription in new publication wizard-sqlserver 2005 standard edition

Folks,
I am planning to implement transactional replication with updatable subscription between two sql2005 Instance .I am surprised that i cold see this type of replication in the new publication wizard in the source server instead i see peer-to-peer replication.
Could you please help me in understanding how to setup transactional replication with updatable subscription in sqlserver 2005 standard edition.
Thanks.

Hi soories,
In addition to Ashwin’s post, peer-to-peer replication is available only in SQL Server 2005 Enterprise Edition. Please
execute ‘Select @@version’ in SQL Server to verify the version and edition of your SQL Server instance.
Also if you cannot see the option “Transaction replication with updatable subscription” in New Publication Wizard, you can use T-SQL to achieve this requirement.
How to: Create an Updatable Subscription to a Transactional Publication (Replication Transact-SQL Programming)
https://technet.microsoft.com/en-us/library/ms146922(v=sql.90).aspx
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support

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: Alter view changes are not reflect on Subscription database

Hi All,
we are configured transactional replication in our environment on sql server 2008 R2 , Yesterday I made a view alter on publisher database the view also present in replicated articles but unfortunately the changes not reflect in subscription, I already have
checked the : Replicate Schema change option in Subscription option its also true, there is not latency exist in replication monitor , i have checked the blocking on subscription and publication. one more thing I tested the changes on replicated table its
working fine
Please help me to fix the issue.
Regards,
Pawan Singh
Thanks

Hi Pawan,
According to your description, the alter on the view in publication doesn't be reflected in subscription database. As my analysis, the issue could be caused by that the distribution agent job doesn’t run after altering the view.
I make a test on my computer, and set up transactional replication to replicate tables and views. Firstly, when creating subscription, I set the distribution agent job ‘Run continuously’(as the screenshot below), and alter the view in publication database,
then the change is successfully reflected to the corresponding view in subscription database.
However, I also make another test with setting the distribution agent job ‘Run on demand only’(It is determined by you), and find that it is not reflected to subscription database unless I run the distribute agent job manually.
The distribution agent is used to read the updated transactions written to the distribution database and applies the change to the subscription database, so please check if your distribution agent job runs after you alter the view. If not, please run the
job and check if the issue still occurs.
Regards,
Michelle Li

Replication update statement takes long time

Hi Replication experts,
I have a issue and please suggest if my understanding and solution is correct.
We have a transactional replication setup for data warehouse, from today morning replication got huge latency so when I looked into it I saw the "sp_MSupd_< tablename >" was running for very long time and by this time it was running for 9 hours
still no data was updated, Latency went very high. What we feel is that the index maintenance was not done in subscriber also it was not replicated too. So due to high fragmentation the update statement could take very long.
As there was no error message or blocks found all we see is the update taking very long. So to avoid this we are planning to remove the index, as this is just data warehouse index maintenance is not required by removing we can gain some space too. Is this a
good Idea to implement?
When we ran profiler nothing was found, no error or alert logged.
Please let me know your suggestions
Thanks
Best Regards Moug

Hi All,
The Issue we found to be is that a day before, new column was added to the table and 9000 rows were updated ... This caused the distributor to slow down the update operation as the index in subscriber(15 million rows) was updating every time a row
is updated.. So we suspect that adding a new column and updating it at the same time is the culprit..
But still am not convinced as per my understanding the distributor operates by comparing the primary key of publisher that was changed with the primary key of the subscriber and apply those change.. If that is the case why should it worry about the new column
added or the number of updates..
Also one strange thing is another table was also lagging behind in its operation ,though that table was updated with just 18 rows.. So in a nutshell the update operation was totally down by distributor operation on that day..
Can someone please shed some light on this, Replication is my favorite topic but now I got fear of it.. after failing to know what could be issue...
Best Regards Moug

Transactional replication issue

Hi,
i have configured transactional replication with separate distributor server, the data copied and snapshot delivered,last 2days it is running, publisher to distributor is good, but distributor to subscriber it show heavy latency and it is showing critical
status,when i see in the replication monitor, it shows undistributed commands 65000 records, when i see in snchronization status it showing 'deliverimg replication', when i compare to publisher and subscriber records difference is there, i checked the file
tranfer speed 100mbps and bandwidth speed is als good....how to fix it

Was there any issue which caused replication to stop for some time or was there any huge updates that happened at publisher..
Take a look at this link..
http://blogs.msdn.com/b/chrissk/archive/2009/05/25/transactional-replication-conversations.aspx
It explains very clearly to troubleshoot this.. You might only have to look at the distribution agent latency part, as per your description...
Apart from this, check if there are any triggers in the subscriber end which is making the subscriber updates slow..
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

Transactional Replication Stalled.

Hi,
We are having a Transactional replication issue where the Data does not get replicated and the log Just keeps grawing.
Last week we had an accidental load 15 Million records, on one of the T replication enabled Db's .Then the replication stopped working i mean i look at the replication monitor it says NO transactions to replicate but we have a lot difference
with the DATA.I also see that the logfile file for the DB is growing.
1.I did a few things like stopping the log reader and restarting.
2.Reinitialize the Snapshot ,the snapshot is taken but is not being applied to the subscriber .No error msg that i can see.
So had to drop the replication entirely , shrink the log and recreate it adding few bunches of articles, creating a snapshot for them wait until they are applied and then add the other articles which worked fine for few days , and DB replication
stopped again and log started growing.This time it is also effecting other replications this time too.
I am running out of options can some one plz help!
THanks,
Jack

That message means the log reader agent is going through the log reading commands from it. If your ETL operation does large batch operations replication many not be able to keep up. You might need to break these batches up into smaller batches - batchsize
works well here.
Another thing to consider is to do your ETL operation on both sides. This works well if the only source of changes occurs from the ETL process - then you would not publish these tables.
If not - think about use MaxCmdsInTran - you can set this to something like 10,000 which means that if you do a million row update - the log reader agent will start to read the commands out of the log for every 10,000 changes and replicate them to the subscriber
- before the transaction is committed on the publisher.
This is a command that you can put in your log reader agent profile so you can turn it off when the ETL process is done and replicated.
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

In SQL Server Transactional replication what all changes I can do on subscriber table

In SQL Server Transactional replication what changes I can do on subscriber table
Thanks

Hi Ajay.G,
According to your description, if you want to do some updates at the Subscriber, you need to note the following things.
•If TIMESTAMP or IDENTITY columns are used, and they are replicated as their base data types, values in these columns should not be updated at the Subscriber.
•Subscribers cannot update or insert text, ntext or image values . Instead, you could partition the text and image columns into a separate table and modify the two tables within a transaction.To update large objects at a Subscriber, use the
data types varchar(max), nvarchar(max), varbinary(max) instead of text, ntext, and image data types, respectively.
•Updates to unique keys (including primary keys) that generate duplicates and then they are not allowed and will be rejected because of a uniqueness violation.
•If the Subscriber database is partitioned horizontally and there are rows in the partition that exist at the Subscriber but not at the Publisher, the Subscriber cannot update the pre-existing rows.
For more information, see: Updatable Subscriptions for Transactional Replication
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

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 triggers disabled after server restart

Hello Everyone,
I have been facing this issue since couple of days. I have configured transactional replication with updatable subscriber in sql server 2008 R2. It was working fine till date. Recently we are facing an issue where subscriber whenever restarts, one
of the table's replication triggers(insert, update and delete) are disabled automatically. We have to manually enable all the triggers for that table. Other tables are working fine. Please help. Thanks in advance.
Regards,
Sai

Have you checked information from replication monitor?
You should disable all triggers because you don't want SQL Server to fire the trigger on the Subscriber database when the database receives an insert, update, or delete operation. Because the trigger has already fired on the Publisher database, firing the trigger
on the Subscriber database might repeat the transaction.
http://technet.microsoft.com/en-us/library/ms151718(v=sql.110).aspx
http://msdn.microsoft.com/en-us/library/ms152529.aspx

At what point is it a good practice to Drop and Add back an Article for Transactional Replication?

Hi,
We have transactional replication Setup in our company , a set of tables involved in replication needed to be reloaded on prod say about 12-13 Million rows .
We decided to drop the articles and add it back to replication so that a new snapshot for the specific articles can be generated and the transfer of data is fast and no breakage in the replication.
But what is the best practice or a threshold point for taking this route i.e dropping an article and adding it back ?
I mean
when Is it good to go this route i.e when the load is more than 10, 000 rows or 50.000 rows 100,000 or at what number do we start this process?
Thanks,
Jack

That is a function of horsepower and bandwidth.
If you do drop a table out rather than replicate a 1% change of its data, 100% of the table will need to be snapshotted which might cause havoc with users trying to access that table, and if you are running immediate sync all of the tables will need to be
resnapshotted.
With the Enterprise Edition of SQL Server you will be able to use a sync type of database_snapshot which will mean no locking, otherwise it could be painful. Initialize from a backup is also an option to save you the cost of a snapshot.
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 update causing deadlock

Similar Messages

Maybe you are looking for