Articles on this Page
- 07/02/18--11:34: _Log Reader Agent
- 11/05/09--12:13: _Disabling of CDC fo...
- 07/04/18--06:20: _Unable to Alter the...
- 07/03/18--17:43: _Create Procedure sy...
- 07/09/18--10:00: _Trying to grasp rep...
- 04/03/16--14:52: _Subscription Alread...
- 07/10/18--05:50: _How to setup Replic...
- 07/11/18--03:32: _Error Inserting Row...
- 07/11/18--05:58: _Log Shipping - Data...
- 07/12/18--03:05: _Merge Replication -...
- 07/17/18--05:17: _How to check the am...
- 07/17/18--07:30: _Error in Replicatio...
- 07/17/18--07:16: _Following error app...
- 07/19/18--09:31: _Transactional repli...
- 08/13/17--18:42: _Upgraded Distributo...
- 07/24/18--02:14: _Merge replication S...
- 07/25/18--00:32: _Existing Replication
- 07/25/18--12:27: _Peer to Peer betwee...
- 07/26/18--00:48: _Conflict in Peer to...
- 07/26/18--01:32: _SAME PUBLISHER DATA...
- 07/02/18--11:34: Log Reader Agent
- 11/05/09--12:13: Disabling of CDC for a database fails
- 07/09/18--10:00: Trying to grasp replication better - need some input
- 04/03/16--14:52: Subscription Already Exists
- 07/11/18--03:32: Error Inserting Rows into Merge Replicated Table
- 07/11/18--05:58: Log Shipping - Database Owner Change
- 07/17/18--07:30: Error in Replication Monitor after upgrading to SSMS 17.8.1
- 07/19/18--09:31: Transactional replication.
- 07/25/18--00:32: Existing Replication
- 07/25/18--12:27: Peer to Peer between versions?
- We build out the new environment software.
- We configure Peer To Peer replication between the 2014 and 2016 environments.
- We setup Transaction replication between the 2016 OLTP and reporting servers like we currently have in 2014.
- At the time of our choosing we point the apps to the 2016 OLTP environment.
- 07/26/18--00:48: Conflict in Peer to Peer replication
Hi, We have few servers where updates\deletes are made in big batches and often we come across performance problems in replication. While we try to keep those batch size small, sometimes they go out of control. I came across this option "
for log reader agent and it says "This parameter specifies the maximum number of statements grouped into a transaction as the Log Reader writes commands to the distribution database." There is also a warning saying "this was not designed to be always turned on". What does it mean? What are the drawbacks if we have that turned on? any suggestions?
We have a database with cdc enabled for several tables, but when trying to disable cdc for the database this error happens:
Msg 22831, Level 16, State 1, Procedure sp_cdc_disable_db_internal, Line 216
Could not update the metadata that indicates database AgricultureSubsidy is not enabled for Change Data Capture. The failure occurred when executing the command '.sys.sp_replhelp N'DisablePerDbHistoryCache''. The error returned was 3930: 'The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.'. Use the action and error to determine the cause of the failure and resubmit the request.
Msg 266, Level 16, State 2, Procedure sp_cdc_disable_db_internal, Line 0
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 2.
Msg 266, Level 16, State 2, Procedure sp_cdc_disable_db, Line 0
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 2.
Msg 3998, Level 16, State 1, Line 1
Uncommittable transaction is detected at the end of the batch. The transaction is rolled back.
The error has been described on Microsoft connect and reported fixed back in 2008.
The same error now appears with both without SP1 and with SP1, on sql server version:
Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) Mar 29 2009 10:11:52 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.0 <X64> (Build 6001: Service Pack 1) (VM)
We have disabled all of the tabled for cdc, but can not disable database.
How can this be fixed?
when i tried to publish the replicated tables or procedures changes from VSTS 2017 below error showing. Could someone please help me.
table is replicated and cannot be modified
Procedure is replicated cannot be modified
Actually when i disable the 'Do not Alter replicated objects' option i could publish successfully. is this correct way of doing the changes (or) am i going in wrong direction.. please help....
We have a database on SQL Server 2012 r2 replicating to another database in the same machine. We were doing some table changes so I am not sure if we messed anything. Our CPU has been close to 100%.
When I run this query
FROM sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext
order by total_elapsed_time desc
I see that total_elapsed_time = 22278963 and cpu_time = 1360
Is this normal?
Never posted here before, so I apologize if I make some errors in posting.
We use Replication, but it is my belief we do not use it smartly. The person that set it up did an excellent job of doing so, but is "self-taught' and to me, we do not leverage it smartly, or fully. So, I am taking time to bullet a few things we do that I wanted to hear your thoughts on and also see if anyone here recommends a good "hands-on" type education alternative that we can attend to learn more about how to leverage replication better, and ways to correct some issues we are facing.
Again, new to here, so please forgive me if I do not provide enough information or if I give too much in some cases. Ask what you like and I will try to explain further. I am posting more of statements of issues, and would love input/thoughts to help me
understand how to explain how it is wrong, or understand that it is not and "I" am wrong.
1 - We originally set up a "replication server" to "offload the 'work' from the production servers because reporting services were creating locks and 'bogging down production'.
MY Answer to that is along the lines of, MS Access and badly written queries cause the locks we are seeing, not "report services". LCM type locks are going to lock data, thus we are still seeing locks. Badly coded sql objects that are distributed either cross-server or cross databases also lend to issues.
2 - A MAJOR one that perplexes me, is having a development --> test --> PROD environment, but coding objects that can only exist on the replicated server, not on the prod server of that line of databases, creates two actual prod databases, each different, and is highly inadvisable.
An example is a replication server that houses replicated data from more than one prod server/database line, so they can share data without having to use linked server calls, created an environment that has people coding objects that cannot be promoted to actual PROD, but need to be promoted directly to the replicated database. IMO, that is not manageable. If someone snaps the database again and overwrites, who is to say it does not blow away the non-replicated database?
3 - We have one database that does not have PKs (don't get me started..)...heh.. but it is a 3rd party thing and we need to replicate it. We use transactional repl, but I used Snapshot and it worked, but the TRN file ballooned till it filled up the drive.
I figure there has to be a way to avoid this, but have not figured that aspects out yet.. heh
Okay, I wrote a lot, and do not want to make anyone angry or offend anyone. I will watch, read, and learn some things, I hope.
Thank you all very much!
I am running SQL Server 2014 on Windows Server 2012 R2 Standard. The database server is setup to be both a publisher and distributor for replication out to several remote databases running on Windows 7. One of the remote computers running windows 7 had to be replaced. Once the new computer was setup and running, I deleted the existing subscription using SSMS. The new computer had to be named the same as the old computer that was taken out of commission. I tried to setup replication on the new computer and I get the following error.
Cannot create the subscription because the subscription already exists in the subscription database. Only one subscription to the same publication is allowed in each subscription database. Drop the subscription and add it again if necessary. If the problem
persists, replication metadata might be incorrect; see Books Online for troubleshooting information.
Parameter 2 is incorrect for this DBCC statement.
Supply either @credential_id or @credential_name.
Changed database context to 'ScaleFusion'. (Microsoft SQL Server, Error: 14058)
I have done this many times before without any issues. Now I have 4 machines behaving in the same way. I have tried to find information on how to address this issue but so far I have found nothing that has been of any help. Please let me know what I can do to fix this.
I have created 2 SQL instances on VM using Google cloud
SQL1 and SQL2
when I start configuring replication on SQL1, right click > Replication > Configure Distribution getting below error
" Select actual computer name "
when I searched I found one MSDN thread
I checked server name on both sql instances its showing below name
please advise how to do it
I have a database with about 20 tables and I am using merge replication to 2 files databases. When I run a stored procedure on the publisher to insert about 4 thousand rows into at particular table, I get the error shown below.
The ID column is an automatic ID. It is "Not For Replication" but is "Merge Published", similar to all other tables in the publication. ThePublisher Range Size for the ID column was 10,000 (by default) and theSubscriber Range Size was 1,000. I added a zero onto the end of each but I am not sure when I need to drop and recreate the subscriptions for that to take effect. Also, the error occurs during the insert, so I assume that it comes from the Publisher. If I insert a single row in SSMS, there is no error. I have run sp_adjustpublisheridentityrange @table_name = 'TableName', but it made no difference.
I am at my wits end to figure out what to do about this so any help would be appreciated.
Msg 548, Level 16, State 2, Procedure ImportSpinParamDBF, Line 27 [Batch Start Line 11] The insert failed. It conflicted with an identity range check constraint in database 'CBL_Meridian', replicated table 'dbo.SpinParameters', column 'ID'. If the identity column is automatically managed by replication, update the range as follows: for the Publisher, execute sp_adjustpublisheridentityrange; for the Subscriber, run the Distribution Agent or the Merge Agent.
I am trying to do some security cleanup. A database, that is the secondary for log shipping, has a database owner that needs to be changed. I am not able to change the database owner thru the gui because the db is in standby/readonly mode.
This is on SQL 2008 R2.
Is there any way to do this while it is in standby/readonly mode?
Any other options?
Currently we have single SQL server in one region, we are planning to expand the servers based on the traffic. ex. UK, US and other country.
But as it is single database replicated at both the ends. can i create a colum with date and time in UTC format and when i update any column in the same row it will update the UTC-COLUMN with the latest time stamp.
1 - PrimaryKey
2 - First Name
3 - Last Name
4 - UTCDatetime
at the same time on other member someone updated the First Name as John and Last name as wick in the same primary key.
also we have updated the timestamp in the UTCDatetime.
Can i achieve this using the conflict resolver?
Any option to check how much data is replicated everyday in merge replication?
When I want to see publication properties through replication monitor (Right click on the publication and Properties), following error appears. I'm getting this error after I upgraded my SQL Server management studio to version 17.8.1, before it worked.
SQL Server 2016 SP1
SSMS version 17.8.1
When I try to remove the conflict in the conflict viewer I'm getting following error. One of my published article has computed column with persisted ON, need for index.
SQL Server 2016 (SP1)
How can I solve this?
We have transactional replication setup in our environment. With <g class="gr_ gr_118 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" data-gr-id="118" id="118">lot</g> of deletes replicating this to <g class="gr_ gr_117 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins doubleReplace replaceWithoutSep" data-gr-id="117" id="117">subscriber</g> and where we are running reports on the subscribers. Because of the deletes replicating it is blocking the tables and suspended the Report sessions causing the reports not to run.
These deletes happen <g class="gr_ gr_357 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="357" id="357">atleast</g> for 10 to 20thousands rows
Do you think of any other idea?
Is it okay if we set the reporting stored procedure to have snapshot isolation level enabled and try it?
I upgraded sql server from 2008r2 enterprise edition to 2016 enterprise edition, on same server. I detached, uninstalled 2008, installed sql 2016, reattached. Replication issues occuring...I now see I probably was suppose to drop all replication prior to starting upgrade process. I searched for what to do when upgrading the server but found no guidance on this. So now things are broke. Doesn't seem to recognize distributor/distribution db. I do have scripts for dropping and recreating all replication but when I tried to run the initial scripts to begin dropping replication (first item was drop a subscription), I get this error:
OLE DB provider "SQLNCLI11" for linked server "repl_distributor" returned message "Login timeout expired".
OLE DB provider "SQLNCLI11" for linked server "repl_distributor" returned message "A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check
if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.".
Msg 53, Level 16, State 1, Line 2
Named Pipes Provider: Could not open a connection to SQL Server .
I am not sure if this is simply a issue because I do not know the password for the distributor_admin. A part of my upgrade plan included recreating all the logins and linked servers
from saved scripts. I did not know the password for repl_distributor. I set it to a guessed password. When I realized there were issues after completing migration steps I tried to access distributor properties in replication but they aren't
available. I went to publication properties and changed password there to new password.
What step do I need to take to get replication going again? Will it require dropping it all, like I am thinking. If so, how do I get around issues I am seeing trying to drop replication items?
I am looking to upgrade my merge replication topology servers and am a little confused by the document https://blogs.msdn.microsoft.com/sql_server_team/upgrading-a-replication-topology-to-sql-server-2016/
It states that:
A Subscriber to a merge publication can be any version less than or equal to the Publisher version.
But further down in the merge replication matrix, it shows that 2016 publisher will support only 2016, 2014 & 2012 subscriber.
Can anyone confirm if a 2016 publisher/distributor <->2008 R2 subscriber is supported?
recently joined one org... already replication setup is done by some one ... i need to take care of it further.
what are the things get it from that guy (KT).
We have a 2014 environment that we want to upgrade to 2016. The OLTP box replicates a 2 TB DB to 6 other reporting servers with transaction replication.
Our new 2016 environment is going to use new hardware. The plan was to simply backup/ restore from 2014 to 2016, then rebuild replication in the new environment. However, I came up w a new idea that may save us some time:
I tried this in a DEV environment but am having issues configuring a Publication in 2016 (not yet adding a Subscription, so I know it's not version related).
Before I get too far in the weeds here I thought I'd ask if this is even possible due to version differences?
Thanks in advance! ChrisRDBA
We have two servers that have SQL SERVER 2014 and there is Peer to Peer replication set up between them. There are 15 publications on each server and all of them on each server are using the same server as local distributor. In one of these publications we have one large article (more than 2 billion records ) . On all publications, 'Allow peer to peer conflict detection' and also 'Continue replication after conflictid detection' are set to true .One of developers deploy and run a job that massively start to delete rows from that large article independently on both servers. This job rans for 8-9 hours and created a massive backlog in transaction log(around 100GB) This caused all publication on each server show a very high latency and large back log in transaction log. The Error log is filled with lots of below error on both servers.
A conflict of type 'Delete-Delete' was detected at peer 81 between peer 181 (incoming), transaction ...).
After two days the transaction log(on both server ) become empty and all other publications caught up, but still that particular publication that delete operation has happened, shows there is latency for 2 days and also still the error is being flooded by 'A conflict of type 'Delete-Delete' was detected at peer 81 between peer 181 (incoming), transaction ...).' error message.
I was thinking after trying to run delete statement on each server , if there is a conflict sql server will not try to run it again. So I am not sure why still the errorlog is being filled with above error message. Will restarting Distribution agent help?
How can I eliminate that latency on that particular publication? Is there any way to fix the issue without resetting up the peer to peer?
I have one publisher DB database where are moving data to DB1 by transnational replication and to DB2 by merge replication .data not moving to DB1 WHEN DML operations occurred on DB database