Articles on this Page
- 01/14/15--15:42: _Virtualizing a dist...
- 01/14/15--15:58: _'Disabling replicat...
- 01/15/15--00:26: _Creating Replication
- 01/15/15--05:19: _Transactional repli...
- 01/16/15--06:18: _Merge Replication P...
- 01/16/15--08:29: _SQL Server 2008 Fea...
- 01/16/15--20:04: _SQL 2012 Database M...
- 01/17/15--03:07: _A trigger returned ...
- 01/16/15--14:51: _The options to repl...
- 01/19/15--17:38: _SQL Server 2005 - P...
- 01/20/15--01:08: _Data types in Sql S...
- 01/20/15--18:31: _what is the best wa...
- 01/21/15--07:02: _Merge statement cau...
- 10/23/12--10:09: _problem by generati...
- 08/26/13--01:53: _SQL Server 2012 Mer...
- 01/21/15--22:04: _XPREPL.DLL Error
- 01/22/15--01:47: _Merge rep - monitor...
- 01/23/15--02:08: _Merge Repl.: Making...
- 01/23/15--04:24: _Replication between...
- 01/23/15--07:30: _Backup Replication ...
- 01/14/15--15:42: Virtualizing a distribution server
- 01/14/15--15:58: 'Disabling replication' versus removing it
- 01/15/15--00:26: Creating Replication
- 01/16/15--06:18: Merge Replication Primary Table Key Error
- 01/16/15--08:29: SQL Server 2008 Feature Pack Download
- 01/16/15--20:04: SQL 2012 Database Mirroring Issue is stalling
- 01/19/15--17:38: SQL Server 2005 - Possible Replication Related Error
- 01/20/15--01:08: Data types in Sql Server 2012 not supported by replication
- 01/20/15--18:31: what is the best way to copy database from overseas?
- 01/21/15--07:02: Merge statement causing deferred updates
- 10/23/12--10:09: problem by generating replicated between servers SQL 2008
- 01/21/15--22:04: XPREPL.DLL Error
- 01/22/15--01:47: Merge rep - monitor upload size
- 01/23/15--04:24: Replication between two nodes
- 01/23/15--07:30: Backup Replication Scripts using SSIS
We're trying to make a decision on whether to do an in-place virtualization of our distribution server which is running on old-hardware or to take down replication piece by piece and migrate it over to a new VM.
I'm wondering what are the pros-cons of each approach. Specifically I'm wondering if we decide to virtualize the old physical hardware (non SQL related task) will replication have an issue when the new virtual server comes up with a new MAC address (but with the same IP and name). I'm also wondering what would be the steps needing to be taken to validate replication is up and running again. Would we need to reinitialize the subscribers or publishers? I'm still learning replication so please be gentle...
The other approach of standing up a new server and then scripting out the distribution and then piece by piece moving over a replication is my preferred way to go about this. Should I just 'deactivate' a publication and subscription on the old servers, then script out the create publication and subscriptions and run those scripts on the new distribution server? Is it that simple?
I'm wondering how to disable replication w/out completely blowing it away. I'd like to do this piece by piece. Is there a system SPROC which can accomplish this? I'd like to the ability to 're-enable', if possible, using that same SPROC if things go sideways.
I am going to remove my previous transaction replication and creating new one details as follow
-Publisher and distributor on the same server
subscriber is initialized from backup
- there is no snapshot run initially
New Environment which i am going to create
-distributor on subscriber
- pull subscription
- subscriber will initialize from snapshot first time
- snapshot folder on shared folder which is on subscriber server
please let me know if anyone has good idea than it or anything is to change
Note: I do not have separate server for distributor
I have been poking around on Google trying to understand if there are any gotchas in configuring transactional replication on a instance DB of a failover cluster, to a SQL Server Express DB. Also, this client would like to replicate a set of tables between two instances DB's which both reside on nodes of the cluster.
Everything I've read suggests there is no problem using transactional replication on clustered instance as long as you use a shared snapshot folder. I still have some concerns:
1) Should the distributor need to live on a separate instance?
2) What happens in the event of an automatic, or manual failover of a publisher, especially if the distributor does not need to live on a separate instance? I know that when a failover occurs, all jobs in progress are stopped and this seems like a recipe for inconsistency between the publisher and subscriber.
There is a paramount concern, that this particular client won't have staff on hand to troubleshoot replication if there are problems, hence my hesitancy to implement a solution that relies on it.
Thanks in advance.
We have a SQL Server 2008 database that is replicated to Australia. The primary data tables are merge replicated. The replication cycle is 1 hour. We have a situation where a user inserted a row into a table, deleted the row, then reinserted it within an hour. The merge replication failed because of a primary key uniqueness violation on that table. We have been told that merge replication cannot handle this scenario.
From what little I can get from the MS literature, the replication triggers should have handled this. The delete trigger should have removed the insert entry from the replication tables and the second insert should have removed the entry from the delete replication tables, leaving the replication processing to only do the second insert. Can anyone clarify what is really supposed to happen here or if this is in fact a limitation of merge replication?
I've gotten nowhere for the past hour trying to download version 10.0.0.0 of certain DLLs that are supposed to belong to the SQL Server feature pack. All I get are results for newer releases. Is version 10.0.0.0 still available? If it
is, what is the link?
I have a SQL 2012 Enterprise Primary and DR SQL Clusters.
I have a 500 GB TDE Enabled Using HSM SQL DB which I have mirrored across to DR.
I am noticing that my Logs are shipping to DR, but the Unrestored Log size is huge and My restore rate is about 0 - 80KB/Sec. This is Causing the unrestored Log to grow on the DR side.
I also notice at times my Unsent Log is also getting big after any DB Maintenance activities (such as rebuild of indexes).
I have a dedicated connection between my datacenters and the traffic thruput is quite reasonable and I am able to copy out a 2GB File across within a few minutes. I see no packet drops within my links.
How do I ensure that my unsent logs are copied out and also increase my restore rate in DR side.
Any help / Suggestions will be much appreciated.
I have 2 servers connected over a low speed wan and we're running SQL Server 2008 with Merge replication.
At the subscriber, sometimes when attempting to insert new rows, I get this error:
A trigger returned a resultset and/or was running with SET NOCOUNT OFF while another outstanding result set was active.
What I have checked:
There is a big database on remote server. A read-only replicate is required on a local server. The data can only be transferred via FTP, etc. It's ok to replicate it once a day.
Logshipping is an option. However, it need to kill all the connections when doing restoring. What's the other options (pros/cons)? How about merge repl or .Net sync framework?
I was setting up a replication job on a server. I was setting up the publisher end. I used the wizard to create a scheduled job to do a snapshot of one of our databases.
I completed the wizard and clicked Finish. The progress window appeared and it appeared to get hung on step one of the process (Adding articles). I killed the job via Task Manager. This was at 2:11 pm.
At about 3:30 pm, the server started to become very slow. I brought up Performance Monitor and the Pages/sec was maxed out. CPU usage was at 11%. Memory consumption was at about 50% of total memory.
The issue did not clear up and we had to bring the server down and restart it to clear up the issue. This was at 4:00pm.
Looking at the error logs, there is a warning for stopping the replication publisher job and removing it. Then there is an error message regarding a "deactivated schedule 41". Then errors from bringing the server down.
I'm wondering if it is possible for the replication publisher job that I killed to have kept running in the background gobbling up resources. I've done a search of the internet and several forums and I've found nothing conclusive.
screen shot of the error logs but I can't insert it yet until my account is verified.
I am planning to configure replication on SQL server 2012.I need to know what data types are not supported in replication and if there are any other boundations. kindly suggest.
As customer need to migrate their databases(200 databases) to our data center, at this moment, we usually ask customer to send full backup by HDD and then send trn files via FTP, then we restore full backup and apply latest trn files until cutover. However FTP is not stable, trn files are always broken.
The databases size are 3GB~150GB, trn file size are 1MB to 5GB, especially the big trn files are failed every time, we have set transfer mode to Binary in FTP client, but it still fails.
I have VPN access to their database server, so in this case is there a better way to copy/migrate their databases to our server?
Customer using Windows 2003 + SqlServer 2008
We using Windows 2012 R2 + SqlServer 2014
Appreciate your suggestions/advises.
Environment is SQL2012 Enterprise.
We have two tables that are replicated (transactional). The source tables are updated via the MERGE TSQL statement. The columns being updated are not part of any unique or primary key, yet we're seeing the updates replicated as Delete/Insert pairs. We tried setting trace-flag 8207 but this did not help. At this point it seems our only option is to abandon the MERGE statement and insert or update the old fashioned way.
Any insight/assistance is much appreciated!
I have 3 SQL 2008 servers with Windows 2008 R2, 2 of them are in a domain and the other is outside it, one of which is within the domain is as Publisher and the other 2 as subscribers ... which is outside the domain is connected to it through a VPN .... and is the same which does not take data replication
In reference to http://dba.stackexchange.com/questions/29141/why-do-replication-deletes-require-sysadmin-access
I have the same issue as reported in the above link. The immediate issue has been bypassed in that I have granted ALTER TRACE permission to the main Applications account that does DELETE operations on the tables in question but in all honesty I don't want to grant that access just to bypass the error.
Msg 8189, Level 14, State 10,Procedure sp_repl_generateevent, Line 1 You do not have permission to run 'SP_TRACE_GENERATEEVENT'.
Has anyone else ran into this and come up with a better solution other than biting the bullet and giving all accounts that run DELETE operations on the merge Tables ALTER TRACE permission?
I could try some impersonation within the Replication Triggers to overcome this but of course if the replication is recreated then i would need to manually administrate the trigger code to manage the impersonation so that doesn't seem that practical to me.
Does this mean that its now a requirement for all accounts that run delete operations on Merge replication Tables to have Alter Trace Permission? o.O
Some advice would be greatly appreciated.
I got the below error. How to avoid this without reinstalling the server.
Could not load the DLL xprepl.dll, or one of the DLLs it references. Reason: 126(The specified module could not be found.).
Good day all,
Is there any smart way to ascertain the size of data uploaded during a merge replication sync ?
It's possible to see the number of rows per table in the history tables , but I can't find a quick way to know the size of the sync in terms of Mbs...nothing in perfmon either.
Does anyone have any pointers as to how to find this out (in as un-convoluted a fashion as possible).
I have configured a running merge replication with several clients on a SQL Server 2012.
I now have the problem, that when I make a new snapshot and reinitialize the subscriptions there is always a certain schema change script that is causing a replication error.
Reason: An ALTER COLUMN statment fails, because an indexed view is accessing the column (the table and the view are published articles).
I thought, that when I make a new snapshot (manually start the snapshot agent) and reinitialize a subscription, there would be no need for any old schema scripts to run.
Doesn't a new snapshot include the complete schema of all articles?
I have two SQL Server 2014 Standard nodes, and I want to keep them completely replicated both sides (node1 to node2 and node2 to node1) to let my firewall manage load balancing or failover when one of the nodes is offline.
I want to have local storage on both nodes.
Could you help me to understand what is the best way to make this?
Thank you very much!
I need to find a way of generating replication scripts using SSIS and storing these in a folder, this package will be run from a job on a daily basis, I'm using SQL Server 2008 R2, Any ideas would be appreciated.