Transactional Replication From SQL 2005 To SQL 2000 Affects Performance Of Database.
Sep 21, 2007
Hello,
We previously having two servers A and B. Server A is used for updation of data and the data then replicated to server B. Server B is used for
Server A :
purpose : used for database updation/ modification
SQL Server version : SQL Server 2000 SP 2
Server Z :
purpose : used for Reporting
SQL Server version : SQL Server 2000 SP 2
We were doing Transactional replication from Server A to Server B.
Last month we have broght another server (Server B) with same hardware configuration but having SQL SERVER 2005 installed. This is to speed up our database update process. We have moved some of the database on this new server so that we can achieve our deadlines.
Server B :
purpose : used for database updation/ modification
SQL Server version : SQL Server 2005
I have set up the transactional replication from Server B to Server Z and replication works fine.
However, the issue is after it is started replicating from this new server (Server B) performance of all the queries reduced a lot.(making my life harder)
I didnt expected this as our reporting server is still SQL server 2000.
I have restored the backup of database which was replicated from server A (sql server 2000) and compared execution plan for one of our common query (which is used in most of the reports and which is now taking longer time to provide results)
I found that database which is replicated from Server B (Sql server 2005) is having primary keys. which was not present in the database which replicated from server A(Sql server 2000).
I have then removed the primary key and make the indexes same as previous copy of database(which was replicated from server A) But still the query takes long time.
Execution plan now shows "Table Spool" which was not present in previous copy of database.
Almost every query for this database is taking longer time now.
Can someone suggest me what is wrong and what should I need to fix.
I have just upgraded from 2000 to 2005 and my transactional replication is running very slow, I already have a latency of 10 mins and its getting worse. I'm just using the default agent profile, is there anything I need to change?
I setup transactional replication between 2005-> 2000 database for only one table. It works fine no problem. I checked replication monitor everything works well. My Subscription was Push Subscription on Publisher.
This morning I restored main database at publication server, I saw all my publication configuration were gone.
I then went to create a publication and push subscription again..and did it, But when I went to replication monitor. I checked that Snapshot are being created, but from distributor to Subscriber is saying below message?
"The concurrent snapshot for publication is not available because it has not been fully generated.....lONG CHPPPED off meassage"
I have a publication on 2000 machine, replicating by pull subscription to a 2005 machine. I added a table to the Articles in the publication. Reinitialized the subscription, and also restarted both the snapshot and log reader agent. I was kind of assuming the publication would automatically create the table on the subscriber, but after a very long wait it is still not there. Am I missing anything?
PS. Distination Object setting : "Action if name is in use" is set to drop and create new, not that that should make any difference since name is not in use anyway.
We have a SQL2000 database (Publisher) replicating inserts and updates across a 10Mb link to a SQL 2005 database (Subscriber). The Publisher has two tables we are interested in, 1 with 50 columns and 1 with 15. Both tables have 6 insert/update triggers that fire when a change is made to update columns on the publisher database. We have set up a pull transactional replication from the Subscriber to occur against the Publisher every minute. We have limited the subscription/replication configuration to Publsih 6 columns from table 1 and 4 from table 2. Any change occuring on any other columns in the Publisher are of no interest. The SQL 2005 database has a trigger on table 1 and table 2 to insert values into a third table. There are around 7,000 insert/updates on table 1 and 28,000 on table 2 per day. All fields in the tables are text. We are seeing "excessive" network traffic occuring of approximately 1MB per minute (approx 2GB per 24 hrs). We also see that the Distributor databases are getting very large -- upto around 30GB and growing until they get culled. We have reduced the culling intrval from 72 hrs to 24 hours to reduce the size. Does anyone have any suggestions as to how this "excessive" network traffic can be minimised and how the distributor database size can be minimised. I think that maybe they are both related?
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 am keen to hear peoples perspectives on how much additional load Transactional Replication will have on a server. Obviously this will depend greatly on the level of transactions in the database, but a general indication would be great (eg 10% increase in overheads).
I am thinking of encorperating this into a new server structure which we are going to be setting up and am unsure as to whether to make the primary server BOTH the publisher and distributor; or make the secondary server the distributor to reduce the load on the primary to only being the publisher.
Basically the secondary server will simply be a 'hot swap' of the primary - so i/o load on the secondary is not going to be an issue. There may be 2 primary's (if that makes sense) replicating to the hot swap so that if either primary is dropped the hot swap could take over either servers load/responsibilities - not sure if this will make a difference on where to put the roles?
I have sucessfully set up transactional replication, allowing the subscriber to update the publisher. All works well for a while, but after a couple of weeks or so it fails, but always for a different reason !
My question is, is there anything that can be done to help replication stay healthy. I had thought of doing regular backups of the database and the transaction log, and then truncating the transaction log.
Any advice, or links to other troubleshooting resource much appreciated.
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?
I doing a transactional replication with two servers. Server A, the Publisher and Distributor. Server B, the Subcriber. I did the replication using a dummy DB for practice purpose and it works fine. When I try to implement the replication in original DB, I found that some tables don't have primary keys and to be able to implement transactinal replication all the replicated tables need to have a primary key. I want to add the primary keys to those tables and also implement the replication but the problem is those tables have data in it. I'm thinking in create the new table and do a DTS to import the data to the new table or it's fine just to modify the table in design to add the primary key "Those table have record in it".
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 have tried setting up transactional push replication using stored procedures and using wizards. I have two Publishers that are their own Distributors, and 1 Subscriber. All servers are running SQL 2000 SP4 build 2187. Replication appears to be working correctly, but on the Subscriber, under Replication > Subscriptions, the replication type is showing as 'Snapshot' instead of transactional for both subscriptions.
SQL Server 2005 Books Online provides an article entitled, "Initializing a Transactional Subscription without a Snapshot". Is it possible in SQL Server 2000 to initialize transactional replication without a snapshot?
So far, I have been unable to find a similar procedure mentioned in the SQL 2000 Books Online. I was able to follow the 2005 procedure using SQL 2000 until I got to the step that says to enable the "Allow initialization from backup files" option on the "Subscription Options" tab of the "Publication Properties" dialog. But that option does not appear in the SQL 2000 version of the specified dialog box.
I have used skiperrors parameter for 2601,2627 and 20598 errors in my Transaction replication setup. When transactions with above error are encountered, its skipped but I€™m not getting sql command that is skipped in MSrepl_errors table. Since SQL server 2000 is not saving transaction sequence number in the MSrepl_errors we are not getting the command, which have the errors.
Is there any way to track the commands those are skipped in transactional replication.
I am trying to configure Transactional replication with updatable subscription sql server 2005 with service pack 2.
Creating distributor and publisher on the same box, but subscriber on a different server.
Distributor and publisher are configured without any problem but when I try configuring subscriber, it throws below warning.
TITLE: New Subscription Wizard ------------------------------
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.
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------
The operation could not be performed because OLE DB provider "SQLNCLI" for linked server "REPLLINK_QA-WIN2K3-1413475264_ADVENTUREW1643387368_WELLCORE-542849619_ADVENTUREW1643387368" was unable to begin a distributed transaction. Changed database context to 'AdventureWorks'. OLE DB provider "SQLNCLI" for linked server "REPLLINK_QA-WIN2K3-1413475264_ADVENTUREW1643387368_WELLCORE-542849619_ADVENTUREW1643387368" returned message "The transaction manager has disabled its support for remote/network transactions.". (Microsoft SQL Server, Error: 7391)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.3152&EvtSrc=MSSQLServer&EvtID=7391&LinkId=20476
------------------------------ BUTTONS:
OK ------------------------------
I tried setting this up directly on the Subscriber machine using sp_link_publication but the same error.
Any help or suggestion are welcome.
Thanks Sachin
Don't sit back because of failure. It will come back to check if you still available. -- Binu
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.
WHen creating publciations under 2005 i saw a very interesting option under stament delivery, for inserts , updates , deletes there is an option that simply says insert/update/delete statement.
I could find very little in BOL about this under "Article Properties", is this what it soudns like ? FOr example if you say :
update Table set Cloumn = 'whatever', this will not trigger the update sp for each row at the subscriber , will it actually deliver the update statements and literally do the update/insert/delete statement at the subscriber?
I have one Oracle Server (Version 10g) with some simple tables which should be replicated to an SQL 2005 Enterprise Server.
i got this error:
Error messages: The process could not bulk copy into table '"dbo"."S_AGRZ"'. (Source: MSSQL_REPL, Error number: MSSQL_REPL20037) Get help: http://help/MSSQL_REPL20037 Batch send failed Violation of PRIMARY KEY constraint 'MSHREPL_38_PK'. Cannot insert duplicate key in object 'dbo.S_AGRZ'. (Source: MSSQLServer, Error number: 2627) Get help: http://help/2627 To obtain an error file with details on the errors encountered when initializing the subscribing table, execute the bcp command that appears below. Consult the BOL for more information on the bcp utility and its supported options. (Source: MSSQLServer, Error number: 20253) Get help: http://help/20253 bcp "RS"."dbo"."S_AGRZ" in "F:Microsoft SQL ServerMSSQL.2MSSQLReplDatauncACPRS2_DISTRIBUTION_S_AGRZ20070518023422S_AGRZ_2.bcp" -e "errorfile" -t"<x$3>" -r"<,@g>" -m10000 -SSVIESQL04RS2 -T -w (Source: MSSQLServer, Error number: 20253)
i set the publisher to drop the table and create a new one when i reinitialize with a new snapshot. it only works when i remove the unique key constraint. but after that the data in the replicated table has wrong entries. a select count ... will show the exacly same number as an select count ... on the original table direktly on the oracle server. i reinitialzied the replication multiple times with new snapshots. but the problem does not resolve. first i got a unique key constraint. then i typed truncate table ..., after that i removed the the unique constraint and than all data will be imported but there are some entries that are not existing in oracle.
my server is patched with the newest updates for sql 2005 (Version 9.0.3159).
for exempla the following statement will show the same results on oracle and sql 2005:
Oracle: SELECT COUNT(*) FROM S_AGRZ Result: 471.066
MS-SQL: SELECT COUNT(*) FROM S_AGRZ Result: 471.066
but, for example this will show differences:
Oracle: SELECT * FROM S_AGRZ WHERE art_nr='C7972A' Result:
I'm a newbie to Replication and recently setup the following.
Publisher and Distributor on the same SQL2005 server, then I've got 7 subscribers(SQL2000 servers) and I'm using push subscriptions. I'm replicating 5 SQl tables which don't have too many changes and these are scheduled to run every 3 hours. In a few days a large one off SQL update with add an additional 10,000 rows to one of the replicated tables. I was wondering what impact this would have on the above setup i.e are there any sort of limitations here. I'm assuming not but thought I would check. I'm thinking it will just cause additional overhead on the server, but the update is being applied when no users will be using the database.
We are Using Transactional Replication with Updatable Subscription in SQL Server 2005 SP1.
Subscription Type : Pull Subscription
Mode : Continuous Running Mode
Conflict Resolution Policy : Publisher Wins.
I have a table "Sample" (which is part of replication) and it has got 3 triggers. All the triggers are set NOT FOR REPLICATION.
The first trigger Updates a column of the "Sample" table in which i inserted a record. The second trigger inserts record in to another database table and also updates a column of the table "Sample". The third trigger does not affect any tables, it is written for some manipulations with variables.
In this scenario when I insert a record in the Sample table of the subscription database, that record is visible in the table. But during replication, it shows conflict in the Conflict Viewer and removes the record from the Sample table of the subscription database. The record is not replicated to the publisher and the other Subscriber also.
But when I comment any one update in either the first or second trigger, the insert works fine without any conflict.
Is there any issue with firing two triggers in replication which is updating the same table? I also suspect the Order of Commands moving to the Publisher from the MSReplication_Queue table, becoz the conflict viewer shows the subscriber as the Conflict loser. Is there any issue with msrepl_tran_version, Since the conflict is decided based on this id??
Hi,I am trying to set up a Updatable Subscriptions for TransactionalReplication with SQL 2005 (queued updating).I have a stored procedure "SYS_spShellTest" which is replicated to thesubscriber viathe replication option "Execution of the stored procedure":-------------------------------------------------------------ALTER procedure [dbo].[SYS_spShellTest] @cmd varchar(1000)WITH EXECUTE AS ownerasBEGINEXEC @result = master..xp_cmdshell @cmd, NO_OUTPUTReturn (@result)END-------------------------------------------------------------1) If I call "exec SYS_spShellTest" on the publisher the call is alsoexecuted on the subscriber.2) If I call "exec SYS_spShellTest" on the subscriber the call is NOTexecuted on the publisher.How can I make 2) work so that it is also executed on the publisherplease?Thanks a lot,Patrick
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'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 at my work place some of the users migrated to another domain even thought with new domain name they can access SQL Server but user who are part of sysadmin(part of some group) on the box unable to execute a job. it means at operating system level newdomainuser credentials are get resolved that's why users are able to access box but why not able to execute jobs. why sysadmin Privilege not get resolved at SQL Server level very confused............
We are developing a system which will have to support more than 3000 subscribers. We will have to support both Transactional replication and Merge replication.
I checked the following document about SQL 2005 replication <http:// www.microsoft.com/technet/prodtechnol/sql/2005/mergrepl.mspx>. The document does not clearly specify what is the maximum number of subscribers supported without a significant performance degradation.
The questions i have are: 1. Given the fact that there will be more than 3000 subscribers, there will be more than 500-1000 subscribers trying to replicate at the same time. Will be there be a performance degradtion in such a scenario
2. Has anyone used SQL Server 2005 in a scenario involving more than 3000 subscribers?
3. Will it be better if we develop our own system to perform replication activity instead of relying on SQL Server 2005?
- Ngm
Mail me atnarasimha (DOT) gm (AT) gmail (DOT) com )
Wondering if anyone has any experience with SQL Server Express Edition (SSEXP). We're looking at a mobile sales force type model, so a local database on a laptop with no real time network connection. So the users would collect data locally, then connect up to the network every few days to replicate the data to a central server. So questions.. Has anyone tried anything similar? How stable/mature is SSEXP? Any other thoughts, alternatives or gotchas anyone can think of?
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.
I have sql 2000 running with a client database that is about 200 people per day. A VB front end runs it. I have some problems with performance. Would upgrading to Sql 2005 improve my database performance?
We are in the process of upgrading a sql 2000 database over to 2005 and have noticed some substancial performance drops with scalar udfs in 2005.
I have already read the following post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=491984&SiteID=1 and recognise that udfs are not the most performant option in the first place, but was surprised how much slower these have become on 2005.
Has anyone else had this sort of issue, we really don't want to go away from the udf's but would like to know if there is a design issue within a udf that might be causing this (or even a usage issue). What I am getting as is: Is there certain types of queries, or keywords that should be avoided in udfs on 2005?
A simple example we have is a udf that returns an exchange rate stored in the db, this has parameters of "from currency", "to currency", and date.
SET @ret = ( SELECT TOP 1 TELE_TRANSFER_RATE
FROM dbo.EXCHANGE_RATES
WHERE EXCH_CURRENCY_NO = @from
AND CURRENCY_NO = @to
AND RATE_DATE <= @date
ORDER BY RATE_DATE DESC )
RETURN @ret
And then this is called from a script that returns financials, standard select statement, with udf call in select clause.
