I am dealing with an issue reagrding transactional replication, I am taking a backup from the publisher and restoring it onto the subscriber, when I try to enable the transactional replication between the two O got the error stating The process could not execute 'sp_MSadd_replcmds' on 'MY_DB' can anyone tell me whats wrong here?

The process could not execute 'sp_MSadd_replcmds' on 'HK-DB-PROD'. (Source: MSSQLServer, Error number: 1007) Get help: help/1007 · The transactions required for synchronizing the nosync subscription created from the specified backup are unavailable at the Distributor. Retry the operation again with a more up-to-date log, differential, or full database backup. (Source: MSSQLServer, Error number: 1007) Get help: help/1007 · Batches were not committed to the Distributor. (Source: MSSQL_REPL, Error number: MSSQL_REPL22020) G help/MSSQL_REPL22020

Is there anyway to identify by how much time we can get a deadlock when we enable Snapshot replication for our subscriber, we have a subscriber considered as Azure SQL Database, and we have 8 databases one of them consists of 200GB in size. Is there any way to identify the downtime for genereating snapshots?

iam using sql server 2016 and i have followed MSDN tutorial in order to configure replication between two nodes the first one is the publisher and distributor

while the second one is the subscriber

as mentioned in this link https://docs.microsoft.com/en-us/sql/relational-databases/replication/tutorial-replicating-data-between-continuously-connected-servers?view=sql-server-2017

but when i issue View Synchronization status the job hangs

and in order to know the reason i tried to run launch replication monitor and inserted a token which showsthat

publisher to distributor takes one second while it hangs as pending from distributor to subscriber

and showsthe following error Agent 'Node1-ReplicatedDataBase-PublicationName-Node2' is retrying after an error. 18 retries attempted. See agent job history in the Jobs folder for more details.

so I issued the following query to know the exact reason

SELECT J.[name] 
       ,[step_name]
      ,[message]
      ,[run_status]
      ,[run_date]
      ,[run_time]
      ,[run_duration]
  FROM [msdb].[dbo].[sysjobhistory] JH
  JOIN [msdb].[dbo].[sysjobs] J
  ON JH.job_id= J.job_id
  order by run_date desc ,run_time desc

and it shows the following error

  Unable to start execution of step 2 (reason: Error authenticating proxy Node1\repl_distribution, system error: The user name or password is incorrect.)

even though i have configured distributor in subscriber with this account with the right password

i noticed also that after restarting sql server agent on Node1 the job Replication monitoring refresher for distribution has x mark which refers that it doesn't work

any ideas please to what could be the reason ?

I get the following error in Replication Monitor:

The row was not found at the Subscriber when applying the replicated UPDATE command for Table '[dgv].[POSCustomer]' with Primary Key =

The error is actually not about the missing row, but that the table's schema says dgv.

The publication that generated the error is supposed to only replicate to [ppv].[POSCustomer], and should not even be aware of [dgv].[POSCustomer]. And only rows created AFTER the initial snapshot is delivered are affected.

The background:

I'm setting up transactional replication for 3 on-premises databases PPV, DGV, and PAC to a single Azure SQL database.

The three databases belong to different legal entities, on two separate servers (PPV on one, DGV and PAC on another), and have identical schemas.

Tables with the same names from each dbs are set up to be replicated.

To differentiate them in the target db, I put them in three different schemas using the name of their source dbs, i.e ppv.POSCustomer, dgv.POSCustomer, pac.POSCustomer.

This is done by changing the setting in Publication properties -> Articles -> Article properties -> Destination object owner.

The initial snapshots are delivered without problems; however, after some time, the row was not found started showing up in the replication monitor.

I tried re-initializing the subscriptions several times, but the error keeps showing up after the snapshot is delivered.

All rows created after the snapshots are delivered are affected.

The databases are totally isolated from each other, there are no cross database queries, no stored procedures, no triggers that says a record from PPV.dbo.POSCustomer should be updated in DGV.dbo.POSCustomer, so I'm at a loss as why this error happened.

I used sp_browsereplcmd to trace the command that generated the error, which leads me to:

{CALL [sp_MSupd_dboPOSCustomer] (,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,2019-05-14 00:00:00.000,,27280000.0000,10,,,,,,,,,,,,2019-05-14 18:30:04.000,,,,,,,,,,,,,,,,,,,,N'vinhn4-00001395',0x00000000d000080000)}

which I don't understand, and the sp is not part of our POS app.

How can I make this error go away? Manually inserting missing rows will not work, as all new rows are affected. Turning on -skiperrors is not an option. Replicating to different target databases have been done successfully before, but setting up cross database query is such a pain with Azure SQL that I'd prefer to avoid \if possible.

I have used transnational replication feature in SQL server to replicate some of the tables (not all) in the master database to three replicas(subscribers). The purpose of having this architecture is that the application(.Net application) which uses this database has reports which use massive amount of data to produce those reports. Application's performances degrades if reports use one single database as its' source.

I am using a separate connection string wherever the application reads data for the reports. This connection string points to a Nginx server which balance the load of the three replicas which I mentioned above.

Even though this solution works perfectly, Now I am looking for a way to get rid the Nginx server and get done the load balancing work from SQL Server itself.Is there any possibility to achieve this with Tran-Replication?

I'm having a lot of trouble with doing a replication between a SQL Server 2014 and Azure.

I use a remote desktop to connect to the SQL Server machine and there, I start doing all the replication steps. I already made the SQL Server the distributor and then I created a publication. The problem is when I finish the subscription configuration, when I look to the replication monitor, everything is fine (snapshot and log agents) except the subscription job. When I look at the history, the following message description shows:

2019-06-04 20:40:36.303 Connecting to Subscriber 'MYSERVER.DATABASE.WINDOWS.NET' 2019-06-04 20:40:36.744 Agent message code 20084. The process could not connect to Subscriber 'MYSERVER.DATABASE.WINDOWS.NET'. 2019-06-04 20:40:36.839 Category:NULL Source: Microsoft SQL Server Native Client 11.0 Number: 40532 Message: Cannot open server "WIN2K8SQL" requested by the login. The login failed.

MYSERVER.DATABASE.WINDOWS.NET is Azure and WIN2K8SQL is my SQL Server

We have transactional replication setup between an SQL Server 2012 box and a SQL Server 2016 box.

Every half an hour the source table articles are altered by DELETE then INSERT sequence. This sequence comes from a stored procedure executed by an SSIS packgage. Sometimes the DELETE has been replicated to the subscriber, but the INSERT hasn't made it there yet.

The result is interim missing data at the subscriber. This interim state can last several minutes as the commands get replicated out to all the articles under replication. These table articles are used as the basis for SSRS reports at the subscriber, which become inaccurate due to this issue.

Inside the stored procedures that house the DELETE - INSERT statements we tried wrapping both commands in BEGIN TRAN - COMMIT TRAN, but this didn't appear to help.

Ideally the delete - insert would be combined to happen at once (kind of like MERGE) using a different SQL command, or wrapping the commands in something akin to BEGIN TRAN - COMMIT TRAN

In transactional replication is there a way to find out how much data was pushed to subscriber in time period, lets say a day?

I am about to start working on a project that requires one Oracle 11g database instance replicate data to an identically configured 11g database in the Cloud (AWS). The cloud database is expected to work as a disaster recovery /backup site for on-prem instance. I will appreciate if you can answer the following questions.

1. Is there a build in feature in Oracle 11g that will allow one time copy of the data elements from on-prem to the Cloud db instance ?

2. Is there a built in features in Oracle 11g which will allow additional /delta real-time data replication from on-prem to the Cloud db instance ? In this scenario the on-prem is continuously getting updated.

If there above mentioned features are not available in 11g can you suggest an oracle or 3rd party utility that will provide this functionality.

Regards

SJ

I have setup transactional replication in SQL Server and I am using PULL to retrieve the data from the subscriber.

Recently, I noticed that the data in my subscriber is not synced up with the database on the publisher server.

Also, I found the following issues:

1. The replication monitor on the publisher indicates that the performance is critical and the latency is 00:04:25
2. The replication monitor also indicates there are 56000 undistributed commands. (This has not changed, seems to be stuck)
3. The "Distributor to Subscriber History" indicates there are 4 running sessions of the distribution agent.

I've setup verbose logging on the distribution agent job, and I am seeing this error message:

Raised events that occur when an agent's reader thread waits longer than the agent's -messageinterval time. (By default, the time is 60 seconds.) If you notice State 2 events that are recorded for an agent, this indicates that the agent is taking a long time to write changes to the destination.

I have tried restarting the distribution agent job, but this doesn't seem to fix the issue. I am not really sure where to troubleshoot next.

Also, it is worth mentioning that the subscriber is running on a secondary SQL Server instance, on the same physical server as the publisher, so I would think latency should be low.

I have been tasked with migrating a database, size being up to 15Gb, from a SQL Server 2008 database in a 3rd party cloud VM, to SQL Azure. On go-live day, when we switch from the old host, the Azure, we have a 1 hr downtime allowance.

Unfortunately, the link speed is 1Mbps. So that would take around 30 hours to transfer. What I would like to do is create a Azure VM, with SQL Server 2008R2. Then, using either transaction replication, mirroring or log shipping, allow the database to replicate to my new VM from the source. I have no time limit for this, as the application migration is at my discretion. Could be a day, could be a few months.

My question is - how can I achieve this? I think transaction replication would be best, so that the database is basically up to date all the time. I need to demonstrate that it's possible, so I have created two VMs in Azure (ClientSourceVM and ClientStagingVM) in separate vnets (Trying to simulate across the internet replication).

The initial snap shot would take up to two days to transfer. Would this cause any adverse effect on the source database? Locking?

And is it possible to do replication across the internet? It seems I need to share folders and setup permissions, but not sure how that works with servers in separate domains across the internet. Is it possible?

With SQL Server 2008R2 - is there any better option that can serve my needs?

Note, once the database gets to 2008R2, I'll then hopefully migrate that to it's Azure SQL destination on go-live day. The replication is purely to allow an up to date database be available on the go-live day without waiting nearly 2 days for the backup file to copy.

Any advice and ideas would be greatly appreciated.

I could do on-prem SQL 2008 directly to Azure? And then on go live - simply stop the replication? I’d need to do more to the source database to make it a stand-alone? Or do I just remove replication - setup users and I’m good to go? I’d obviously do dry runs on a separate test environment - but the idea is do-able? We don’t have huge data spikes at all. It’s a database with only a few concurrent users. Less than 10.

I am using AWS DMS to replicate ongoing changes with SQL Server as a source and target endpoint. The tasks are running and replicating data with low latency. However, I need the tasks configured not to replicate DELETE operations from the source database.

I did read the whole documentation of the tool and I wasn't able to find such a configuration option to exclude DELETE statements for replicating. There is only one place in the whole user guide where it states that if one is performing a Full Load plus CDC or a CDC-only task, it is recommended the migration to be paused and secondary indexes to be created that will support filtering for update and delete statements. But no more, no further explanation.

Any help or experience is highly appreciated, please.

I have regions and every region has 5 locations. currently we have an application which is pushing and pulling data on the logged in user branch on which user has permission. Every location is maintaining its own database where application is centralized.

My requirement is that a query module can retrieve information from any location within region so i dont understand how to do that. should I consolidate the transactions from all locations into one database or what. Need guidance from design perspective. I am asking from architectural perspective.

i'm trying a pull type subscription transactional replication

but i get this error from the replication job history, the error: : Error authenticating proxy DEVELOPMENT1\USER, system error: The user name or password is incorrect.). do i compulsorily need a shared folder for the snapshot between the publisher and subscription because i didn't. i set the distribution agent connection as the windows account of the machine the subscription and database owner login to connect to the distributor agent

I am looking to migrate two on-prem SQL Servers into Azure Hyperscale. Both 28 cores, 1.5 TB of RAM with 10TB data disks.

I can NOT afford any downtime during the migration and have heard transaction replication method might do the trick.

Has anyone had a scenario like this where they used this process?

There really isn't a quiet time. It's a cell phone sub carrier with roughly 2,000,000 users. There is roughly 30GB of data updated twice per minute. Currently on SQL Server 2014 Enterprise Edition.

I'm using SQL Server 2014 SP3CU2 Enterprise Edition.

I have a transaction replication on a DB with some very large tables. I needed to change the structure of a column on one of the tables that were replicated (1.8B rows), so I did the following:

1. Created a duplicated table with the new structure.
2. Removed the table (article) from the publication

EXEC sp_dropsubscription @publication = N'PubName', @article = N'TableName', @subscriber = N'SubscriberName', @destination_db = N'DB';

EXEC sp_droparticle @publication = N'PubName', @ article = N'TableName'

3. Switched the tables (old/new)
4. Added the table (article) to the publication

EXEC sp_addarticle @publication = N'PubName', > @article = N'TableName', @source_owner = N'SchemaName', @source_object = N'TableName', @type = N'logbased', @description = N'', @creation_script = N'' ,@pre_creation_cmd = N'drop', @schema_option = 0x000000000803509F, @identityrangemanagementoption = N'manual', @destination_table = N'TableName', @destination_owner = N'SchameName', @status = 24, @vertical_partition = N'false', @ins_cmd = N'CALL [sp_MSins_SchemaNameTableName]', @del_cmd = N'CALL [sp_MSdel_SchemaNameTableName], @upd_cmd = N'SCALL [sp_MSupd_SchemaNameTableName]'

exec sp_addsubscription @publication = N'PubName', @subscriber = N'SubscriberName@destination_db = N'DB', @subscription_type = N'Push', @sync_type = N'automatic', @article = N'all', @update_mode = N'read only', @subscriber_type = 0

5. Started the Snapshot agent.

I did it in the ACC environment with no issues (that env is much smaller though).

In prod, the snapshot agent took 2.5h to generate the 1 article (as expected, as it's a large table), but once it was done, the distribution agent just filled the gap - the missing rows on the subscriber and continued the sync - the table WASN'T dropped on the subscriber side.

I'm puzzled and can't understand why was it acting this way.

I'm planning to do this again in a few weeks - to re-initialized the replication (because I need to coordinate it with other people) but I can't explain what happened and/or what I need to do in order to avoid it from happening again.

Any help will be appreciated.

Thanks in advance, Roni.

I have a source DB MSSQL Server and deploy transactional-replication to a cluster with 2 Node(A&B). The subscriber was added using SQL IP of Cluster and using "sa" account. It run fine when server A active and server B passive. When i shutdow the server A the replication stop and show error:

The process could not connect to Subscriber 'AHTDWHSQL'. (Source: 
 MSSQL_REPL, Error number: MSSQL_REPL0)
Get help: http://help/MSSQL_REPL0
Named Pipes Provider: Could not open a connection to SQL Server [1326].  
(Source: MSSQLServer, Error number: 1326)
Get help: http://help/1326
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. (Source: MSSQLServer, Error number: 1326)
Get help: http://help/1326
Login timeout expired (Source: MSSQLServer, Error number: HYT00)
Get help: http://help/HYT00

Due to limited size of distribution db I wish to shift or copy data from there to another database using script.Is there any script that copies data from distribution database(System Database) to another user created database using a job at specific interval but newly copied data should append to previously copied data?

I have tried to copy data using insert script that select values from source db and copies into destination db where my source is system db table and destination is user defined db table.But it showed me this error: Msg 8101, Level 16, State 1, Line 6 An explicit value for the identity column in table 'classicmodels.dbo.MStracer_tokens' can only be specified when a column list is used and IDENTITY_INSERT is ON.

SET IDENTITY_INSERT classicmodels.[dbo].MStracer_tokens ON

INSERT INTO classicmodels.[dbo].MStracer_tokens

SELECT *
FROM   [distribution].[dbo].MStracer_tokens

SET IDENTITY_INSERT classicmodels.[dbo].MStracer_tokens OFF 

I want the same data from source to be copied on to destination.Destination only stores this copied data.

We are in the process of creating a reporting functionality for one of our applications with an SQL Server database.

And based on my research, I've concluded that Transactional Replication is the way to go for my case:

• Want changes to occur in real-time from Publisher to Subscriber
• Low latency
• High volume of insert and updates

However, the table indexes in my Publisher database are not tailored for reporting. And because of this, I plan to change the indexes in my Subscriber database.

I have read quite a few articles already but none haven't really answered the questions I have in mind.

My questions are:

• Can I change the table indexes of my Subscriber database without affecting anything in the Publisher database?
• If yes, will this impact the speed of the replication in any way?
• Will this impact the performance of my Publisher database?
• Are there prerequisites for doing this? For example, do I need to "break" the replication relationship between my Publisher and Subscriber databases before I am able to do this?
• When adding an index to the Subscriber database, can I do it like how I normally would in the Query Editor, using the command "CREATE INDEX"? Or is there a special way to do this that is specific to replication?

I have a specific requirement in Transactional Replication, but I am not sure whether it is achievable or not. Could you please help me out if there is any possible way to achieve the same.

Requirement:

As per the requirement, there will be two databases. One is the publication database and another is subscription database.

I want to replicate some of the tables (articles) of the publication database to the subscription database. But what I want is to replicate data only. Because I want to keep those tables (replicating tables) to always present in the subscription database, they may be the empty table initially and when replication starts, these tables may get their data from publication database.

But I don't want the replication to create these tables for me in subscription database. I want to use already created tables. They will have the same schema as publication database tables.