Transactional Replication: Commands Are Not Applying To Subscriber
Oct 30, 2006
Hi!
The distributor was down for a long time (neer the week) and after that the commands stop applying to subscriber, while they successfully collected from publisher and stored into distributor.
Replication agent on distributor reports that initial snapshot is not available. It seems subscription is expired. But all commands from the point distributor down I have. How can I make distr agent to resume activity without reinitialize snapshot?
I have a transactional replication environment that creates subscribers on another server as a staging area for an ETL process to a data warehouse application on a 3rd server which is the report repository. Currently the ETL process runs every 10 minutes and performs it's function across approx 150+ subscriber databases and consolidates it to the data warehouse.
I have an SLA of 2 minutes. I'd like to rework the ETL process (which run as SSIS job at the moment) to be specific to a single database and fire that one ETL proces when changes have been applied to that subscriber database only. Of these 150+ databases generally only about 8-10 are updating the subscriber at any given time per Repl Monitor. I'm thinking that if I only have a few transactions to apply to a single db the ETL would run in seconds dynamically as the subscriber is update.
The issue is how to fire the ETL process upon completion of updates to the subscriber DB? I'm thinking of using SP_Start_job passing the DBID to update the warehouse but unsure whether this is possible but if so where to trigger it.
I have a publisher set up to transactionally replicate just one table which has about 19000 rows. The snapshot agent finished and everything was OK the first day. Now (day 2) the replication monitor estimates that latency to the subscriber = 10 hours and undistributed commands>600,000 and growing each minute. How could this be when data is only inserted into this table and it has <20,000 records? Please advise...thanks!
We have a filtered publisher (SQL Server 2012) with several pull and push subscriptions that have been functioning fine for years.
We have just added a new pull subscriber from a remote server. We configured an alternate folder location on the subscriber (pointing to existing path on a remote server). We generated new snapshot and partitioned snapshot, and moved to subscribing server at alternate path.We're seeing a problem we've never seen before:
When the merge agent runs, it applies the schema and performs a few hundred bulk inserts, but then proceeds to 'download changes to subscriber' as though the snapshot is old (it is brand new and should have all transactions). We have never seen this before, i.e. all data is usually applied in bulk when creating a new or reinitializing an existing subscriber.
we marked the subscriber for re-initialization (from both the publishing and subscribing server) with a fresh set of snapshots. The same problem occurred.We have also tried in our test environment (which mirrors production) and the snapshot applies as expected (via bulk inserts).
(It might be relevant to note the publisher was recently upgraded in-place from 2005 to 2012.)
Hi, I am trying to setup bi-directional transactional replication between 2 SQL Servers, I add the subscription on both the servers using the code below.
I have defined 'AnyServer' on both the servers using cliconfg (Server1's AnyServer pointed towards Server2 and Server2's AnyServer pointed towards Server1, I need to do that because there is a restriction to run the same code on both the servers),
After inserting a record on server1 in the 'test' database, the changes successfully transfers to the server2, then server2 sends it back to server1 and server1 generates the error of
"Violation of PRIMARY KEY constraint 'PK_Table1'. Cannot insert duplicate key in object 'Table1'."
It seems as if loop detection is failing if I keep the same subscriber name on both sides.
It runs fine when I change the subscriber name in the subscription (@subscriber = 'Server2' for server1 and @subscriber = 'Server1' for server2).
I am trying to setup mirrored subcriber in Transactional Replication in SQL 2005. I am not able to do so as it don't work after failover.However I am able to setup mirrored publisher with distribution property "PublisherFailoverPartner" for snapshot and log reader agent profiles and it works even after failover.
However I need to know, do we have something called "Subscriberfailoverproperty" or any other method to set up mirrored subscriber in Transactional Replication in SQL 2005.
Greetings All, I was hoping that a replication sage might be able toanswer a question for me.I want to have one subscriber subscribing to N publishers. Iessentially have a company that has a main headquarters and threesatellite offices. I want each of the satellite offices to push theirdata up to the master database. From what I have read it seems likethis should not be a problem. Some questions that come to mind are:1.)Does the master need to be read only or can it be configured to beupdateable as well?2.)Can the distribution agent on all the publishers be set tocontinuously distribute or should it be staggered so as not to cause aproblem when another distribution agent is running?3.)If the distribution is set to "delay distribution" will this causechanges on the subscriber to be pushed out to the publishers?In this database guid's are used as pk's so the issue of pk collisionsis not a problem.I hope that this question is not too vague. My experience thus farwith replication has been simple one way transactional and simplemerge replication.Regards, Louis Frolio
Any experience of success or failure setting up CDC on the subscriber end of transactional replication?
Also for a bonus answer, why are explicit index operations not permitted (I'm assuming this is even on the publisher?) From BOL:
• Explicitly adding, dropping, or altering indexes is not supported. Indexes created implicitly for constraints (such as a primary key constraint) are supported.
I have taken over a transactional replication setup that is being usedfor fault tolerance (I know, I know...).The scenario I am concerned with is where the publisher goes down due tofailure, so we need to point our application at the subscriber and startupdating the data there. We are not using the immediate updating option.How do I go about re-syncing the publisher with the data that been addedto, or changed on the subscriber, when the publisher comes back online?Thanks,TGru*** Sent via Developersdex http://www.developersdex.com ***Don't just participate in USENET...get rewarded for it!
i have setup default transactional replication using locat distributor scheme. I need to create triggers on tables at subscriber side. Can this be done using transaction replication?
I have a primary and secondary servers both running Windows 2000 SP3 with SQL 2000 SP3. I have set up transactional replication with the primary server as publisher and the secondary server has the distributor and subscriber DB. I am testing the scenerio where my primary server goes down and I have to make updates to the secondary server until my primary server comes back up. I am able to update my subscriber database and the transactions go into the MSreplication_queue table to be pushed back to the primary when it comes back up. When I bring the primary server back up and start the queue agent job it starts pushing the transactions over and then stops after 4 or 5 transactions with the error "Failed while applying queued message to publisher". I have attached part of the log file for the agent below
In the sql server logs I am getting this message: Replication-Replication Transaction Queue Reader Subsystem: agent Repl Queue Reader failed. Failed while applying queued message to publisher. Error: 14151, Severity: 18, State: 1
We have a database which is (a subset of tables are) replicated to another via transactional replication. Whilst most changes made at the published database reach the subscriber within a matter of seconds, we have a SQL Agent job which performs a calculation in the published database and then immediately exports data from the subscriber using log shipping. The result is that the calculated changes do not make it through to the exported transaction logs in time.
Is there a way to manually "refresh" the subscriber databases using T-SQL?
I am getting the error The transaction log for database 'ReplicationDB' is full due to 'LOG_BACKUP'.log_reuse_wait_desc from sys.databases is showing logbackup
The database is subscribed database. We configured transactional replication. But the transactional replication is getting errors and failed. Is there relation b/n this replication failures and log growth in subscriber db?
Are there any requirements that dictate the SQL Server version for the distribution agent for a SQL 2000 publisher with a transactional push subscription to a SQL 2005 subscriber?
I have a unusual problem with a snapshot publication that I am having a hard time troubleshooting. The servers in question are all SQL 05 Enterprise. Here is the scenario:
Staging Server - This server acts as the publisher of the snapshot Production Server - This server is the subscriber of the staging snapshot Cascade Servers - These servers receive transactional updates from the production server
The staging server applies the snapshot to production successfully. From there the production server has a transactional publication which the subscribers are the cascade servers.
This model worked for a long time where we would generate the snapshot apply it to production and the updates would be sent to the cascade servers. All of a sudden there is a problem with the transactional publication from production -> cascade. There are 7-10 tables that do not receive the updates and all data in the problematic tables is truncated. The other remaining tables in the subscription receive the updates as needed. Looking at replication monitor and all other logs shows that the transactions are being replicated, but yet the 7-10 problematic tables do not contain any data. The only solution I have found for this is to recreate the entire replication model from scratch.
Any advice on how to handle this scenario? Is my model for using a transactional publication to cascade changes to a subset of servers incorrect?
We have transactional one-way replication running, and suddenly today started getting this error :
The DELETE statement conflicted with the REFERENCE constraint "FK_BranchDetail_Branch".
The conflict occurred in database "LocationDB", table "dbo.BranchDetail", column 'BranchNumber'.
Message: The row was not found at the Subscriber when applying the replicated command.
Violation of PRIMARY KEY constraint 'PK_Branch'. Cannot insert duplicate key in object 'dbo.Branch'. The duplicate key value is (23456)
Disconnecting from Subscriber 'SQLDB03'Publisher - SQLDB02.LocationDB Subscriber - SQLDB03.LocationDB
Tables on both servers: Branch (BranchNumber PrimaryKey) BranchDetail (BranchNumber ForeignKey references previous table)
select * from SQLDB02.LocationDB.Branch -- contains : 23456,'Texas',... select * from SQLDB03.LocationDB.Branch -- contains : 23456,'NULL',...The problem is - the BranchNumber in question '23456' exists in all 4 tables (Publisher..Branch, Publisher..BranchDetail, Subscriber..Branch, Subscriber..BranchDetail). Yet, when I ran a trace on Subscriber, I see repeated commands like:
exec [sp_MSdel_dboBranch] 23456 -- which throws FK violation exec [sp_MSins_dboBranch] 23456,'NULL',... -- which throws PK violationI'm guessing it's trying to Update the record on subscriber by doing a Delete + Insert. But it's unable to..
Users do not have access to modify Subscriber table. But they can modify Publisher table through UI, and have been doing so for long time without issue. There is also job that updates Publisher table once every night. We started getting this error around noon today.
Our last resort is to reinitialize subscription off-hours.
We need to apply the transactional log for business hours (9-5) everyday to a oracle instance which will be seeded with SQL Data for once. And then every day the transactional log would be applied.
We need to do this as eventually this server is moving to oracle.
At this point if somebody could help me to read the transactional log that would be great.
I'm interested in combining the Peer-to-Peer Transactional Replication and Standard Transactional Replication to provide a scale out solution of SQL Server 2005. The condition is as follows:
We may have 10 SQL Server 2005 (1 Publisher + 9 Subscriber) running transactional replication in the production environment and allow updates in subscribers. To offload the loading of the publisher, we plan to have 2 Publisher (PubNode1 and PubNode2) using Peer-to-Peer Transaction Replication and the rest 8 subscribers will be divided into 2 groups. The subscribers 1-4 (SubNode1, SubNode2, SubNode3, and SubNode4) will be set to be standard transactional replication subscribers of PubNode1, and the rest 4 subscribers (SubNode5, ..., SubNode8) will be set to be standard transactional replication subscribers of PubNode2.
Is it possible to setup above 2 Publisher + 8 Subscriber topology? Also, could we set the 8 subscribers with updatable subscriptions to achieve each node is updatable?
We do not plan to set all the 10 nodes using Peer-to-Peer Transactional Replication as it is necessary to make sure n*(n-1)/2 (i.e. 45) peer-to-peer connections is reliable. It seems that the maintenance cost is high if the servers are not in a LAN and the topology is very high coupling. So we prefer to divide the 10 nodes into 2 groups and reduce the cost of each node to maintain the connections to all other sites.
Hi,I have transactional replication set up on on of our MS SQL 2000 (SP4)Std Edition database serverBecause of an unfortunate scenario, I had to restore one of thepublication databases. I scripted the replication module and droppedthe publication first. Then did a full restore.When I try to set up the replication thru the script, it created thepublication with the following error messageServer: Msg 2714, Level 16, State 5, Procedure SYNC_FCR ToGPRPTS_GL00100, Line 1There is already an object named 'SYNC_FCR To GPRPTS_GL00100' in thedatabase.It seems the previous replication has set up these system viewsSYNC_FCR To GPRPTS_GL00100. And I have tried dropping the replicationmodule again to see if it drops the views but it didn't.The replication fails with some wired error & complains about thisviews when I try to run the synch..I even tried running the sp_removedbreplication to drop thereplication module, but the views do not seem to disappear.My question is how do I remove these system views or how do I make thereplication work without using these views or create new views.. Whyis this creating those system views in the first place?I would appreciate if anyone can help me fix this issue. Please feelfree to let me know if any additional information or scripts needed.Thanks in advance..Regards,Aravin Rajendra.
i am getting the below error while applying running the Synchronization agent for the Subscriber. I have created replication topology with one central server and one subscriber. Here central server has windows server 2003 and subscriber has windows XP. Both are having SQL server 2005. After creating the merge subscriber, i am runnnig the Synchronization agent manually for the first time. While running that i am getting below error. Anybody aware of this error.
2006-06-24 00:26:00.175 Applying the snapshot to the Subscriber 2006-06-24 00:26:02.722 The schema script 'D_NUM_7.sch' could not be propagated to the subscriber. 2006-06-24 00:26:02.784 Category:NULL Source: Merge Replication Provider Number: -2147201001 Message: The schema script 'D_NUM_7.sch' could not be propagated to the subscriber. 2006-06-24 00:26:02.816 Category:AGENT Source: WMBT-07 Number: 0 Message: The process could not read file '\WMBT-01 epldatauncLTR-IN001_TEST_PUB20060624034804D_NUM_7.sch' due to OS error 1265. 2006-06-24 00:26:02.831 Category:OS Source: Number: 1265 Message: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
I have been researching on the proper steps or sequence to follow to completely remove SQL Server 2012 Transactional Replication. Â I have read articles about using SSMS as well as using replication stored procedures and some procedures use SQLCMD or just regular TSQL executed in SSMS. Â I have also read articles where people said all you really need is connect to the Publisher instance, find the publication you want to remove and choose "Delete" and everything will be taken care of behind the scene. I have three SQL servers that participate in transactional replication. Â SQL-P (publisher),Â
SQL-D (distributor) and SQL-S (subscriber). Â Do I need to connect to the distributor instance and the subscriber instance when removing transactional replication or is it just really connecting to the publisher and click delete on the publication? I want everything gone including any metadata, systems tables, distributions db and any other replication objects created during the initial configuration.
We're testen a simple lan SQL 2005 SP2 one way transactional replication config. Data is replicated ok, but in the Replication Monitor we found some strange issues:
- The subscription is giving a latency warning. When we insert a tracer tocken the total latency is 5 secs. Is there a way to alter the warning level for a subscription??
- Undistributed Commands tab Changes do arrive at the client, but the distributed commands counter shows an increase in value for every (as far as we can tel succesfull) change
If we do insert a tracer token -wich arrives within 5secs.- the the counter is reset to zero.
Replication is failing while applying the snapshot as the stored procs are out of sync ( the objects referenced in the stored procedures are no more exists in the database) . Is there any easy way to identify the out of sync procedures so that I can exclude these stored procedures from the articles list. I am having around 1000 procs and is not possible to test them by executing.
I am about to apply DBCC DBREINDEX to a large database that is part of transactional replication and synchronised every 3 minutes. What are the likely implication and what precautions I must take.
I am working on bringing our disaster recovery site to be a live site. Currently we replicate to one of out servers (server B) with merge replication (from server A). Server A also does one way transactional replication form some table to several other servers including servers at the DR site.
This setup is not going to be fast enough for what we need so I am wondering if a table is receiving merge replication will the merge updates also replicate down the transaction path??
Example... Server B update a row and merges to Server A. With this update them replicate (via transactional) to Server C??
I am using the "Pull Subscription Wizard" to set up merge replication. I go through all the steps of the wizard and then I hit "Finish" at the end. When it gets to the third step (Creating the Subscription), I get the old:
__________________________________________________ _________ mmc.exe has generated errors and will by closed by Windows. You will need to restart the program.
An error log is being created. __________________________________________________ _________
This happens whether I try to do this from my PC or from the actual server I am creating the subscription on.
Has anyone else had this issue? Is there a hotfix I need?
I hope anyone here can help me with this tough problem:
I have a replication enviroment with several subscribers. Publisher:MSSQL 2000, SP3 Subscribers: MSSQL200, SP3 and MSDE2000, SP3
Since a few weeks, one of the subscribers fails when synchronizing with the message "This process could not enumerate changes at the subscriber"
The erroroutput with verboselevel 3 doesn't help me much, I append it to the end of this posting. (unfortunately german)
I heard that this error can be caused by a "blank" in an image column or different Service Pack Versions - definitely not possible in this case! The only strange detail is that the SQL Server Versionnumber of this MSDE shown via EM is not the same as the number shown in controlpanel->software. By the way, is it ok that here are two lines for the MSDE? SP3 is definitely installed on all machines!
Any help would be greatly appreciated - i'm already losing hope... Best Regards, Gert
Microsoft SQL Server-Merge-Agent 7.00.623 Copyright (c) 1998 Microsoft Corporation
Percent Complete: 0 Verbindung mit Abonnent 'MyServerAT074' Connecting to Abonnent 'MyServerAT074.MyDB' MyServerAT074.MyDB: {call sp_MSgetversion } Percent Complete: 0 Verbindung mit Verteiler 'MyServer1s' Connecting to Verteiler 'MyServer1s.' MyServer1s.: {call sp_MSgetversion } MyServer1s.: {call sp_helpdistpublisher (N'MyServer1s') } MyServer1s.distribution: select datasource, srvid from master..sysservers where srvname = N'MyServer1s' MyServer1s.distribution: select datasource, srvid from master..sysservers where srvname = N'MyServerAT074' MyServer1s.distribution: {call sp_MShelp_merge_agentid (0, N'MyDB', N'MyDB', 9, N'MyDB')} Percent Complete: 0 Initialisiert MyServer1s.distribution: {call sp_MShelp_profile (19, 4, N'')} Percent Complete: 1 Verbindung mit Verleger 'MyServer1s' Connecting to Verleger 'MyServer1s.MyDB' Connecting to Verleger 'MyServer1s.MyDB' MyServer1s.MyDB: {call sp_MSgetversion } Percent Complete: 3 Ruft Publikationsinformationen ab Percent Complete: 4 Ruft Abonnementinformationen ab Connecting to Abonnent 'MyServerAT074.MyDB' Disconnecting from Abonnent 'MyServerAT074' Percent Complete: 4 Uploadet Datenänderungen zum Verleger Percent Complete: 5 Ruft die Liste der Löschungen von MyServer1s.MyDB ab Percent Complete: 5 Verarbeitet Artikel 'First'
...... SNIP .... Percent Complete: 5 Verarbeitet Artikel 'LastTable' Percent Complete: 0 Der Prozess konnte die Änderungen auf dem Abonnenten nicht aufzählen. Percent Complete: 0 Category:SQLSERVER Source: MyServerAT074 Number: 0 Message: Attributverletzung eingeschränkter Datentypen Attributverletzung eingeschränkter Datentypen Disconnecting from Abonnent 'MyServerAT074' Disconnecting from Verleger 'MyServer1s' Disconnecting from Verleger 'MyServer1s' Disconnecting from Verteiler 'MyServer1s'
I want to call a stored procedure to do the insert into my published arcticle/table. Is this possible? I know you can call a stored procedure to insert into the subscriber arctiles.
The problem is the published database has a generated primary key (max +1 )that is calculated via a stored procedure during all inserts. I would bring the stored procedure over to the subscriber but that would not help since the values in the target table will not be 'current' because the subscriber database is only updated nightly.
I am tring to use SQL Server Mobile 2005 to subscribe to a SQL Server 2005 publication from a pocketPC. In my code I have a SqlCeReplication object. One of the properties that must be set is: Subscriber, but I have no idea what that should be set to. When I was setting up the publication I don't remember specifying anything like that, and the class description of this property doesn't help: "Specifies the name of the Subscriber". Any help will be appreciated.
I have tried backing up the replication from Primary Server (Publisher) A and copying over to Subscriber B. When I sync. I am missing the data. I don't know what step I am missing or it is bug on SQL 2K SP3.
I don't know what i am doing wrong.
Can anybody give me a step by step detail how to backup the publisher database and copy to a subscriber and sync by saying the schema and data already available. As we have WAN problem all the times, and when I try the full snapshot of 20 gig it was taking more than 24 hrs and also if the connection fails my snapshot also fails
