Sql Server Merge Replication Vs. Sql Server Transactional With Updatable Subscribtion
Jun 12, 2006
Hi,
Transactional replication allows updatable subscriptions where changes at the subscriber are replicated up to the publisher, this can happen via Immediate Updating subscriptions, Queue subscriptions and P2P (new in SQL 2005), all forms of Transactional replication.
Any compared document between merge replication and Transactional with updatable subscribtion ?
I am looking for bidirectional transactional replication using updatable subscribers (queued or immediate) . Is it possible to replicate the image data from the updatable subscribers to the publisher. I understood that the Image data can't be replicated to the publisher from the updatable subscriber. I am not using the WRITETEXT or UPDATETEXT. I am using just INSERT and UPDATE for image data type transactions.
So, Microsoft decided that they were deprecating Transactional Replication with Updatable subscriptions. In that case, you have 2 options (if I am correct): Pay for Enterprise (if you are already not) and use peer-to-peer or use bidirectional transactional replication which is basically setting up a transactional from db1 to db2 and also transactional from db2 to db1.
The issue I see in both cases is conflict resolution. With updatable subscriptions, you could specify how to handle the conflict. With either of these 2 options (from what I can tell) you cannot allow the engine to handle this for you.
Any thoughts? Seems like a slap in the face to those who have been using MS for years and a damn good reason for companies that rely on updatable subscriptions to not upgrade to 2012.
I have just started getting the following error from the queue reader but I can't see why.
The Queue Reader Agent has encountered the error ''Row handle is invalid.'' when connecting to ''Database'' on ''ServerName''. Ensure that the publication and subscription are defined properly and that both servers are running.
Does anybody know what it means / how I can fix the problem?
Subscription to "Transactional Publication with Updateable Subscriptions" works only one way. Changes take effect on subscriber, but the subcriber is unable to update data on publisher.
I have Sanpshot Agent process running under SQL Server Agent service account with login 'sa.' All agents are running at the Distributor (Publishing Server.)
The subscriber is unable to connect to the Distributor using the SQL Server login.
Following is the error message I get:
Creating Subscription(s)...
- Creating subscription for 'SQL3' (Warning)
Messages
Unable to set the Publisher login for the updatable subscription. You may have to set this up directly on the Subscriber machine using sp_link_publication. (New Subscription Wizard)
I have a publisher running SQL 2005 and subscribers running SQL EXPRESS in a merge replication. The subscriptions are pull subscriptions using web synchronization. Every time I do a new release of the database schema on publisher and drop/recreate replication I seem to have a problem.
When a subscriber tries to synchronize first time after this (the datbase on subscriber is dropped/re-create prior to this syncronization) it always results in a error saying something about "unrecognized or invalid response" after sitting there for some time. Several subsequesnt tries give "another job for this subscriber is already running on publisher", and finaly after a few minutes it synchronizes correctly and from this point on everything works perfectly until the next release. This happens with every single subscriber.
As far as I understand, what is happening is that when the merge agent connects to the publisher from the subscriber via web replication the publisher kicks off a job to generate initial dynamic snapshot for this subscriber. This is taking long time. During this time the web request times out, which results in the first error I see. When I try to connect several mre times, the job is still running, which gets me the subsequesnt errors. And finally when creating of the initial dynamic snapshot is finished, I can run the synchronization successfully.
The question is: Is there anything I can do on the publisher in automated manner prior to the first synchroniztion that would help me top resolve this problem? My guess would be that if I run jobs dyn_PUBLISHER-DATABASE-PUBLICATION-num__SUBSCRIBER_anothernum for each subscriber and wait until they've finished before starting sinchronization from the subscriber, it would solve my problem. How ever I'm not sure how to run these jobs in automateed manner (because their name may differ) and how can I make sure that all the jobs are finished.
There may be other way to achive what I want also, please let me know what you think.
EDIT: Also using this method http://technet.microsoft.com/en-us/library/ms151260.aspx I guess underneath, it starts all the same jobs that I mentioned above, but then again, this is neither automatic nor there is an apparent way to tell when all theses job are finished. What I want to do is to run a script and be sure that once the script has finished all the snapshots are there and I can start synchronizing from the subscribers without fear of failure.
I'm still pretty new when it comes to SQL server and I'd like to get some opinions about replication. I need to set up replication between 10 sites. The database is about 2 GB and at each size about 10 users are entering data. The databases need to be synchronized at least 3 times a day. Now our application developer told us to use transactional replication while I'm thinking of using merge replication.
Can anyone give me some more advice about the pro and cons of either replication type. TIA
We have 3 sites & would like to do replication btw the 3 sites. 1 publisher & 2 subscribers. All 3 sites should be able to do updates. Subscribers should be able to operate even if publisher is down. Any advice will be appreciated.
Hi This is my problem 1. I have been requested to implement either merge or transactional replication at my site.The replication will be over a wan 2. The problem i have encountered is that the tables have been denormalized to such an extent that they do not have primary keys ,this is because all the logic has been programmed into the application.I do not want to interfere with the table schema as this will create major problems in the application transactional replication requires that tables participating in this type of replication must have primary keys .IS THERE A WORK AROUND? 3. The second issue is that if i try to implement merge replication i am sitting with a problem that merge replication requires that all timestamp fields be removed to participate in merge replication.This application also has all the logic built into it.Almost all tables have the timestamp datatype in the rowstamp field. IS THERE A WORK AROUND FOR THIS PROBLEM
I am investigating the feasibility of a configuration with 3 databases on SQL2005
DB_A is an OLTP database and serves up transactional publication pub_txn - with updateable subscriptions
DB_B is a subscriber database which subscribes to pub_txn
DB_B is also a publisher which serves up merge publication pub_merge
DB_C is a subscriber database which pulls pub_merge
===============================
Updates on DB_A are successfully replicated to DB_B
Howvever, when DB_C pulls updates, it doesn't find the update sent to DB_B
===============================
Updates on DB_B are successfully replicated to both DB_A and DB_C
===============================
Updates on DB_C initially failed with the error
Msg 916, Level 14, State 1, Procedure trg_MSsync_upd_course_type, Line 0 The server principal "repllinkproxy" is not able to access the database "DB_C" under the current security context.
I then changed the login repllinkproxy to be a db_owner in DB_C
I now get the error
Msg 208, Level 16, State 1, Procedure sp_check_sync_trigger, Line 23 Invalid object name 'dbo.MSreplication_objects'.
=================================
I have three questions as a result 1) Is there anything fundamentally wrong with what I am trying to achieve?
I need to come up with a solution to my replication issue. The solution that I come up with involves using one publisher to push transactional and merge replication. The database that is published is the same.
Would this cause any issues?? Can this be done?? I would think that if a table is needed for both, I would have to create a separate publication for each type right??
Is there any documentation anywhere to help prove if this is possible??
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??
Hi to evebody. I'm working with the transactional publication with updatable subscriptions provided by SQL Server 2005. The replication works pretty good from the publisher to the subscriber, but I'm having some problems when the data must go from the subscriber to the publisher.
When I do an update in a subscriptor's table, the database engine shows the following error:
21064 - 16 - The subscription is unavailable for immediate updating because it is marked for reinitialization. Try again after the reinitialization completes.
And rollbacks the transaction.
Does anybody knows what to do to solve this problems.
The publisher is a Windows XP with the SQL Server 2005 Developer edition with SP2 The subscriber is a Windows 2003 Server with SQL Server 2005 Developer edition without SP2 I'm using also the inmediate updating subscriptions. Both operative systems have the MSDTC runing.
Thank you in advance.
Sebastian.-
PS: Sorry about my english, it's been a long time without using it.
I am trying to test simple replication (only tables) of a database that resides on a SQL Server 2005 instance to a SQL Server 2000 instance. The Publisher and Distributer are set up on the SQL Server 2005 instance for Transactional replication. The subscriber is set up on in the 2000 instance. Replication Monitor shows the following error after applying a few scripts: "Category: SQLSERVER Source SQLSERVER2000 Number: 170 Message: Line 6: Incorrect syntax near 'max'."
Here SQLSERVER2000 is the name of my 2000 instance, as should be obvious.
Beyond this point, replication fails. Any pointers as to where the problem could lie? Is this a known backward compatibility issue? I've checked all tables in the database and none contain any datatype that is new to 2005 (the database was actually created in and for SQL Server 2000.
Replication from 2000 to 2005 works fine, but the other way round is failing as described above. Any clues?
Our database has grown to the point where our current server is struggeling with the query load. One option is to get a 4 processor machine with 16GB of RAM, but I'm also looking at transactional replication as a solution. Currently we run dual Xeon with 4GB of ram (using the /3GB switch in the OS) We have SQL 2000 Enterprise. The idea is to setup a secondary server with transactional replication pushed from the main server, so that some SELECT-only queries can be executed on the secondary server - thus taking load of the main one. We should be able to add PKs to the small number of tables that currently don't have them, and we should be able to run all updates / inserts on the main server.I'll setup a push-subscription for the entire DB (maybe excluding some log tables) and then for ceratain stored procedures I'll direct our applications to use the backup instead of the main server. So: Is this a good idea? Is it easy to backup the server using transactional replication? How much extra overhead will this mean for the main server?
We are attempting to rollout a name and address system to 10,000 users who will use an application connected to an MSDE database.
We are using transactional replication to distribute data updates to them. Clients are connecting via the On-Idle feature of Synchronization Manager to grab transactions.
Server spec: Network card: 1GB Processors: 2* Xeon 3.2Ghz Server spec: DL380 2Gb memory Concurrent connections set to: 600 Disc: RAID 10 with 6400 controller
We are not using hyper-threading.
So far we have rolled the system out to 3500 subscribers, 500 per day.
Each day a subsciber will receive at least 400 transactions and 5000 commands.
Latency is 6 seconds, delivery rate 180 commands per second at less busy times. Latency is 14 seconds, delivery rate 127 commands a second at busy times.
I have seen it get as slow as 0.04 commands a seconds at busy times.
The server becomes incredibly slow when there are more than 50 concurrent connections.
We are seeing 100 CPU for most of the day as clients connect to the distributor at various times. Lunchtime is particularly busy when people go to lunch, leaving their machines idle. We see lots of "time-outs" and "unable to connect to distributor" messages on the replication monitor during peak times.
What can we do to improve the performance of the distribution server?
Are we being over-ambitious by selection SQL Replication for this scenario?
How do we know our schema changes will propagate to subscriber without breaking the replication? Is there any t-sql command to find out the option true or false?
I'd appreciate any help i can get here. I'm working with an MS SQL Server 2005 SP2 db on a Windows 2003 OS. I set up replication from an Oracle 10g instance a few months ago, and everything was working until i installed SP2 for SQL Server.
2007-06-06 16:06:22.488 The agent is running. Use Replication Monitor to view the details of this agent session.
2007-06-06 16:06:23.082 Status: 0, code: 1008, text: 'ORA-01008: not all variables bound '.
2007-06-06 16:06:23.082 ORA-01008: not all variables bound
2007-06-06 16:06:23.082 Status: 0, code: 22037, text: 'Heterogeneous Logreader encountered an error in call to LoadReplCmds when processing state 'PROCESSSYNCDONE'.'.
I can get snapshot replication to work just fine, but transactional replication throws up the error above.
We have installed 2014 sql server. We have currently 2008r2. We have to run the real time report. So we need to set up transactional replication b/n those two servers. We need to use 2008r2 as publisher and 2014 as subscriber.
Is it ok to have subscriber higher version than the publisher?
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 created a publication on SQL 2014 SP1/CU1 it is going to a distribution server also a SQL 2014 database. The subscriber is also SQL 2014 SP1/CU1. When I set it up there are no errors. I fire up Replication MGR and it looks good after the snapshot and distribution agent have been started. Again, no errors. When I do a tracer token the information gets to the distributer in 1 - 4 seconds but it never gets to the subscriber, the tracer token monitoring screen only shows pending for distributor to subscriber.
I can upload the scripts used to create the publication and/or the subscription but am a little hesitant because of server names in the scripts.
Is there a script to find which non-clustered indices are replicated? I know i can do this easily through GUI , having a script will make my life much easier ....
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?
We have a large database with a small number of large tables in it (and a larger number of SMALLER tables), and it is a publisher for a transactional replication scenario. When I create a snapshot to initialize a new subscription, I notice with the larger tables that sometimes it generates multiple files in the snapshot folder, usually in multiples of 16, and numbers them like this:
With other tables, I'll get just one LARGE snapshot file, named:
MyOtherTable_4.bcp
In the latter case, the file can be very large (most recent is 38GB).
In both cases, the subscription will eventually be initialized, but the smaller files will generate separate log entries every few minutes in the Replication Monitor, showing 'Bulk Copied data into 'MyTable' (34231221 rows)', whereas the larger table will generate only ONE log entry, showing 'Bulk coping data into table 'MyOtherTable', and it may take a couple of hours before there is anything else showing...except for an entry saying, 'The process is running and is waiting for a response from the server.'
My question is: what would be the difference between the two tables that would result in one generating MULTIPLE snapshot files, the other only a single, much larger one? The only difference I can see in the table definition is that the one generating multiple files has a clustered index, whereas the others do not.
There is a SQL Server 2008 R2 SP3 Clustered Instance that has Transactional Replication. It is by no means a large replication setup in terms of data/article count. SQL Server was recently patched to SP3 and is current on Windows 2008 R2 Patches.
When I added a new article to replication (via 2014 SSMS GUI) it seems to add everything correctly (replication tables/procs show the new article as part of the publication). The Publication is set to allow the snapshot to generate for just new articles (setting immediate_sync & allow_anonymous to false).
When the snapshot agent is run, it runs without error and claims to have generated a snapshot of 1 article. However the snapshot folder only contains a folder for the instance (that does have the modified time of the snapshot agent execution) and none of the regular bcp/schema files.
The tables never make it to the subscribers and replication continues on without error for the existing articles. No agents produce any errors and running the snapshot agent w/ verbose output provides no errors or insight into any possible issues.
I have tried:
- dropping/re-adding the article in question.
- Setting up a new Snapshot Folder
- Validated all the settings and configurations
I'm hesitant to reinitialize a subscriber since I am not confident a snapshot can be generated. Also wondering if this is related to the SP3 Upgrade, every few months new articles are added to the publication and this is the first time since the upgrade to SP3 that it has been done.
