Setup Transactional Replication on Mirrored database

Hi All,
Environment details:
SQL server 2005 SP4 on all servers below.
Server A -- PRINCIPAL
Server B -- MIRROR
Server C -- REPLICATED DB (need to set this up from A to C.)
Database: test
Actions done:
1. DB mirroring (without witness) has been setup from Server A to Server B.
I need to setup replication for a subset of tables (say 3) and only some of the columns of these tables.
Questions:
1. Is this possible?
2. Are there steps which I can follow?
NOTE: In our scenario, it is ok for the replication to break when there is a DB mirror failover from Server A to Server B. Requirement is only to setup replication from Server A to Server C.

1. We can do the replication provided tables has PK.
2. Once added the publisher and subscriber script out the replication which will help you to drop and recreate as and when needed.
3. Keep distribution On C server
4. If tables are large enough create individual publishers for each of them.
Regards, Pradyothana DP. Please Mark This As Answer if it solved your issue. Please Mark This As Helpful if it helps to solve your issue. ========================================================== http://www.dbainhouse.blogspot.in/

Similar Messages

Setup transactional replication with pull subscription using the option @allow_initialize_from_backup

I am trying to setup transactional replication with pull subscription using the option @allow_initialize_from_backup = true and I am a bit confused on steps involved because at teh end of setup it shows ‘uninitialized subscriber’ in replication
monitor.
Publisher, distributor and subscriber are three separte SQL server 2008 R2 servers.
I executed below steps -
On publisher SQL server executed sp_addpublication with options @immediate_sync ='true and @allow_initialize_from_backup = true
On publisher SQL server executed sp_addarticle to add the articles
On distribution SQL server disabled distribution cleanup agent and stopped the distribution cleanup job
On publisher SQL server created full backup of the publication db
On subscriber SQL server restored above backup with recovery
On publisher executed sp_addsubscription using options @subscription_type = N'pull', and @sync_type = N'initialize with backup'
On subscriber executed sp_addpullsubscription using options @independent_agent = N'True',@subscription_type = N'pull',@description = N'',@update_mode = N'read only',@immediate_sync = 1
On distribution SQL server enabled distribution cleanup agent and started the distribution cleanup job
At the end of these steps it shows ‘uninitialized subscriber’ in replication monitor. What am I doing wrong ?
In the above steps what is the difference between sp_addsubscription and sp_addpullsubscription ?
When I setup transactional replication with push subscription using the option @allow_initialize_from_backup = true, I only execute sp_addsubscription on publisher.
Ravi Kumar

After the step 7 did you create the "Pull Subscription Agent" by running the below stored procedure?
EXEC sp_addpullsubscription_agent
http://msdn.microsoft.com/en-us/library/ms147834.aspx - Step 6
"(Optional) For a pull subscription, execute sp_addpullsubscription (Transact-SQL) and
sp_addpullsubscription_agent (Transact-SQL) at the Subscriber on the subscription database. For more information, see
Create a Pull Subscription."
Check this article for step by step with example-
http://www.sqlpassion.at/archive/2012/08/05/initialize-a-transactional-replication-from-a-database-backup/ The only thing in this article is it uses immediate_sync to be false, where as BOL says to keep it true when allow_initilize_from_backup is true.
Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

How the transactional replication work for simple recovery database (looking for some internal concept)

How the transactional replication work for simple recovery database (looking for some internal concept)
Rahul

There seems to be a new myth going around recently. I’ve had at least three people tell me, in the last month, that SQL’s transactional replication requires the database to be in full recovery.
This is complete fabrication. Replication (SQL native replication, that is) can work with the databases in any of the recovery models.
Transactional replication does involve the transaction log, as that’s where it picks up changes from. The log reader scans over the transaction log looking for log records marked for replication, copies those to the distribution database and then marks them
as replicated. When the checkpoint (for simple recovery) or log backup (for full or bulk logged) occur, the log will only be truncated up to the oldest inactive, replicated transaction.
Because transactional replication has its own way of ensuring log records aren’t discarded before been picked up by the log reader, there’s no requirement for a specific recovery model.
Refer this link
http://sqlinthewild.co.za/index.php/2008/12/05/a-new-sql-myth/
--Prashanth

Error while setting up Transactional Replication

Hi Team,
I am getting below error while configuring Transactional Replication.
Specifically, when I started configuring the distributor that when I am getting below error. I am getting this in GUI as well TSQL script as well.
SQL Server could not configure 'TEST-PC\SQL2K8' as a Distributor.
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Destination path D:\SQL2K8DATA is not valid. Unable to list directory contents. Specify a valid destination path.
Changed database context to 'master'. (Microsoft SQL Server, Error: 14430)
Background of the error.
========================
I installed 3 sql instances of "SQL Server 2008 Developer edition, SP3 (x64)".
I started configuring a remote distributor using one of the instance and error started popping up.
Initially I had the replication running fine and I removed it and tried to reconfigure distributor thats when the error starting popping up.
The folder physically exists and the service account has full permissions and I have logged in as service account and trying to setup Transactional Replication.
He is local administrator on the box and also sysadmin login at sql server level.
Not sure why this error is popping up.....
After wasting a lot of time. I tried to install 3 new fresh instances with same service pack level i.e. sp3, but still the error remains the same.
Appreciate if anyone can guide me resolving this issue.
Thank you.

Hi Brandon,
I generated the script and tried again. No Luck. It is throwing error at creation of distribution database itself i.e. exec sp_adddistributiondb .
/****** Scripting replication configuration. Script Date: 2/25/2014 11:43:31 AM ******/
/****** Please Note: For security reasons, all password parameters were scripted with either NULL or an empty string. ******/
/****** Installing the server as a Distributor. Script Date: 2/25/2014 11:43:31 AM ******/
use master
go
exec sp_adddistributor
@distributor = N'TEST-PC\S2',
@password = N'123'
GO
exec sp_adddistributiondb
@database = N'distribution',
@data_folder = N'C:\Program Files\Microsoft SQL Server\MSSQL10.S2\MSSQL\Data',
@log_folder = N'C:\Program Files\Microsoft SQL Server\MSSQL10.S2\MSSQL\Data',
@log_file_size = 2,
@min_distretention = 0,
@max_distretention = 72,
@history_retention = 48,
@security_mode = 1
GO
Error Message :
Msg 14430, Level 16, State 1, Procedure sp_adddistributiondb, Line 227
Destination path C:\Program Files\Microsoft SQL Server\MSSQL10.S2\MSSQL\Data is not valid. Unable to list directory contents. Specify a valid destination path.
use [distribution]
if (not exists (select * from sysobjects where name = 'UIProperties' and type = 'U '))
   create table UIProperties(id int)
if (exists (select * from ::fn_listextendedproperty('SnapshotFolder', 'user', 'dbo', 'table', 'UIProperties', null, null)))
   EXEC sp_updateextendedproperty N'SnapshotFolder', N'\\TEST-PC\repldata', 'user', dbo, 'table', 'UIProperties'
else
   EXEC sp_addextendedproperty N'SnapshotFolder', N'\\TEST-PC\repldata', 'user', dbo, 'table', 'UIProperties'
GO
exec sp_adddistpublisher @publisher = N'TEST-pc\s1',
@distribution_db = N'distribution',
@security_mode = 1,
@working_directory = N'\\TEST-PC\repldata',
@trusted = N'false',
@thirdparty_flag = 0,
@publisher_type = N'MSSQLSERVER'
GO

Transactional replication very slow with indexes on Subscriber table

I have setup Transactional Replication for one of our databases where one table with about 5mln records is replicated to a Subsriber database. With every replication about 500-600.000 changed records are send to the Subscriber.
Since one month I see very strange behaviour when I add about 10 indexes to the Subscriber table. As soon as I have added the indexes replication speed becomes extremely slow (almost 3 hours for 600k records). As soon as I remove the indexes the replication
is again very fast, about 3 minutes for the same amount of records.
I've searched a lot on the internet to solve this issue but can't find any explaination for this strange behaviour after adding the indexes. As far as I know it doesn't have to be a problem to add indexes to a Subscriber table, and it hasn't been before on
another replication configuration we use.
Some information from the Replication Log:
With indexes on the Subscriber table
Total Run Time (ms) : 9589938 Total Work Time : 9586782
Total Num Trans : 3 Num Trans/Sec : 0.00
Total Num Cmds : 616245 Num Cmds/Sec : 64.28
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 9580752
Time Spent on Commits (ms): 2687 Commits/Sec : 0.00
Time to Apply Cmds (ms) : 9586782 Cmds/Sec : 64.28
Time Cmd Queue Empty (ms) : 5499 Empty Q Waits > 10ms: 172
Total Time Request Blk(ms): 5499
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 10378 Cmds/Sec : 59379.94
Time Cmd Queue Full (ms) : 9577919 Full Q Waits > 10ms : 6072
Without indexes on the Subscriber table
Total Run Time (ms) : 89282 Total Work Time : 88891
Total Num Trans : 3 Num Trans/Sec : 0.03
Total Num Cmds : 437324 Num Cmds/Sec : 4919.78
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 86298
Time Spent on Commits (ms): 282 Commits/Sec : 0.03
Time to Apply Cmds (ms) : 88891 Cmds/Sec : 4919.78
Time Cmd Queue Empty (ms) : 1827 Empty Q Waits > 10ms: 113
Total Time Request Blk(ms): 1827
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 2812 Cmds/Sec : 155520.63
Time Cmd Queue Full (ms) : 86032 Full Q Waits > 10ms : 4026
Can someone please help me with this issue? Any ideas?
Pim

Hi Megens:
Insert statement might be slow with not only indexes and few others things too
0) SQL DB Blocking during inserts
1) If any insert triggers are existed
2) Constraints - if any
3) Index fragmentation
4) Page splits / fill factor
Without indexes inserts will be fast because, each time when new row going to insert to the table, SQL Server will do
1) it will check for the room, if no room page splits will happen and record will placed at right place
2) Once the record updated all the index should be update
3) all these extra update work will cause can make insert statement bit slow
Its better to have index maintenance jobs frequently to avoid fragmentation.
If every thing is clear on SQL Server Side, you need look up on DISK IO, N/W Latency between the servers and so on
Thanks,
Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue :)

Transactional Replication - SQL Server 2012

Newbie to Replication.
Configured transactional replication on a database and everything run's fine, but out of all the tables one of the table with couple of columns as VARCHAR(MAX) and with about 3 million records takes 80% of replication duration.
on bit of research and recommendations, I did configured the server with following
EXEC sp_configure 'max text repl size', -1 ;
but still the table take around 80% of the replication time.
Can someone point me to other areas / best practices / articles to improve Replication performance?
Sreedhar

You need to determine why it is taking so long to replicate.
If it during snapshot application? If so use the initialize from backup option. Is it after the snapshot has been deployed?
Then you need to use tracer tokens to see if it is the log reader agent or the distribution agent. There is not a lot you can do with the log reader agent and it is not normally the bottleneck. It is likely with the distribution agent.
If so, I would first try to factor out the network. Replicate this table locally and see if you still have the same latency. if you don't it is the network and you need to try to minimize the network impact. Use a pull subscription and use a WAN accelerator.
These will have more impact than setting the network packet size.
looking for a book on SQL Server 2008 Administration?
http://www.amazon.com/Microsoft-Server-2008-Management-Administration/dp/067233044X looking for a book on SQL Server 2008 Full-Text Search?
http://www.amazon.com/Pro-Full-Text-Search-Server-2008/dp/1430215941

Transactional Replication - Not replicating

Hello,
I've recently set up transactional replication from one database in Server 1 to another database in server 2.
I've checked the Replication Monitor and they stay green with Latency 0.02 sec and not showing any issues.
However when I inserted a row on the database on Server 1 and waiting 1 minute it's not replicating on Server 2 database.
Could anyone advise what and where to check for issues?
Best regards,
Mohan

What is the latency now? Does it show higher latency?
Could you confirm if the table in which you inserted the row is part of replication?
Could you also try inserting a "tracer token" and see if it replicates and how much time it takes?
http://technet.microsoft.com/en-us/library/ms151846(v=sql.105).aspx
Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

Cannot see Transaction replication with updatable subscription in new publication wizard-sqlserver 2005 standard edition

Folks,
I am planning to implement transactional replication with updatable subscription between two sql2005 Instance .I am surprised that i cold see this type of replication in the new publication wizard in the source server instead i see peer-to-peer replication.
Could you please help me in understanding how to setup transactional replication with updatable subscription in sqlserver 2005 standard edition.
Thanks.

Hi soories,
In addition to Ashwin’s post, peer-to-peer replication is available only in SQL Server 2005 Enterprise Edition. Please
execute ‘Select @@version’ in SQL Server to verify the version and edition of your SQL Server instance.
Also if you cannot see the option “Transaction replication with updatable subscription” in New Publication Wizard, you can use T-SQL to achieve this requirement.
How to: Create an Updatable Subscription to a Transactional Publication (Replication Transact-SQL Programming)
https://technet.microsoft.com/en-us/library/ms146922(v=sql.90).aspx
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support

Transactional Replication: Alter view changes are not reflect on Subscription database

Hi All,
we are configured transactional replication in our environment on sql server 2008 R2 , Yesterday I made a view alter on publisher database the view also present in replicated articles but unfortunately the changes not reflect in subscription, I already have
checked the : Replicate Schema change option in Subscription option its also true, there is not latency exist in replication monitor , i have checked the blocking on subscription and publication. one more thing I tested the changes on replicated table its
working fine
Please help me to fix the issue.
Regards,
Pawan Singh
Thanks

Hi Pawan,
According to your description, the alter on the view in publication doesn't be reflected in subscription database. As my analysis, the issue could be caused by that the distribution agent job doesn’t run after altering the view.
I make a test on my computer, and set up transactional replication to replicate tables and views. Firstly, when creating subscription, I set the distribution agent job ‘Run continuously’(as the screenshot below), and alter the view in publication database,
then the change is successfully reflected to the corresponding view in subscription database.
However, I also make another test with setting the distribution agent job ‘Run on demand only’(It is determined by you), and find that it is not reflected to subscription database unless I run the distribute agent job manually.
The distribution agent is used to read the updated transactions written to the distribution database and applies the change to the subscription database, so please check if your distribution agent job runs after you alter the view. If not, please run the
job and check if the issue still occurs.
Regards,
Michelle Li

Transactional Replication and Database Snapshots

Hi,
I have a database that is a publisher in transactional replication.
I create a database snapshot on that database and then let transactions replicate to the subscriber(s).
I revert the database back to the snapshot.
What happens to replication?
Dan Jameson
Associate Director of IT/DBA
Children's Oncology Group
http://www.ChildrensOncologyGroup.org

Your Log Reader Agent could fail if the publication database LSN is less than the value of the transaction sequence number (max xact_seqno) at the distribution database. In which case you could execute
sp_replrestart to resynchronize the Publisher metadata with the Distributor metadata.
Afterwards it would wise to run a data validation to see how out of sync you are with the Subscriber and use
tablediff utility or SQL Data Compare to bring the Publisher and Subscriber back into convergence. Reinitialization is an option as well. It depends on exactly what you are trying to achieve.
Brandon Williams (blog |
linkedin)

Unable to drop publication database from publisher server in transactional replication

Dear All,
we are getting one issue when the time of dropping publication database on publisher server in transactional replication in sql server 2008 r2.
TITLE: Microsoft SQL Server Management Studio
Could not delete publication 'dbname_Pubs'.
For help, click:
http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1600.1&EvtSrc=Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.Replication.ReplicationMenuItem&EvtID=CantDeletePublication&LinkId=20476
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Could not find stored procedure ''. (Microsoft SQL Server, Error: 2812)
For help, click:
http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.4000&EvtSrc=MSSQLServer&EvtID=2812&LinkId=20476
BUTTONS:
OK
mastanvali shaik

try this..
exec sp_removedbreplication N'<dbname>'
exec sp_droppublication @publication = N'<dbname>'
Raju Rasagounder Sr MSSQL DBA

Peer-to-Peer Transactional Replication (three or more participating databases): What if all the nodes are working at the same time

In the topologies that have three or more participating databases.
What if all nodes are working at the same time? "The topology is not partitioned by time.".
location 1 will do insert/update/delete/read in the same time location 2 also will do insert/update/delete/read .......
**Data that will be added by each location is different(each location has its own primary key ranges).
Is it recomended to use Peer-to-Peer Transactional Replication in such scinarios?

Read these
https://msdn.microsoft.com/en-us/library/ms151196.aspx
http://www.brentozar.com/archive/2012/01/highly-available-local-replication/
The only problem that you have to tackle is what happens when the same data is being updated in multiple locations at the same time. If that is not a possibility with you then p2p is a good choice. Check the above links you will have a better understanding.
Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

Problems starting Replication on large databases - SQL 2012

Hi all,
I have been battling SQL Server for a week trying to get replication up and running, now I realize that most probably I am doing something wrong and I hope that one of you can help pointing me in the right direction.
I want to start replication of a big (180GB) database in my lab environment and every time the end result is errors of the type "The row was not found at the Subscriber when applying the replicated command. (Source: MSSQLServer, Error number: 20598)".
There are more than one database to be replicated and the smaller ones (<= 4GB) have started without problems, a medium database of 21GB had one similar error and has been running for a few days since I found and inserted the missing data in the subscriber
DB.
A couple of facts:
- I have set up the distributor as a remote distributor since the publishers are mirrored databases.
- I assume the distributor setup is OK since all the replicated databases are taking the same 'path' and the smaller ones are working.
- The distributor and the subscriber are set up on the same server.
- All in all the following procedure takes about 3.5-4 hours.
- The database is running in Full Recovery mode
- All log backups on the publisher are turned off for the duration.
Here's what I do:
On the publisher
Create the publication and add all the articles
use [Zaragoza]
exec sp_replicationdboption @dbname = N'Zaragoza',
@optname = N'publish',
@value = N'true'
GO
exec [Zaragoza].sys.sp_addlogreader_agent @job_login = N'NS-LAB-DB-40\SqlServiceUser',
@job_password = N'********', -- Modify Here
@publisher_security_mode = 1,
@job_name = null
GO
-- Adding the transactional publication
exec sp_addpublication @publication = N'Zaragoza_Full',
@description = N'Transactional publication of database ''Zaragoza'' from Publisher ''NS-LAB-DB-38''.',
@sync_method = N'concurrent',
@retention = 0,
@allow_push = N'true',
@allow_pull = N'true',
@allow_anonymous = N'false',
@enabled_for_internet = N'false',
@snapshot_in_defaultfolder = N'true',
@compress_snapshot = N'false',
@ftp_port = 21,
@allow_subscription_copy = N'false',
@add_to_active_directory = N'false',
@repl_freq = N'continuous',
@status = N'active',
@independent_agent = N'true',
@immediate_sync = N'true', -- Needs TRUE
@allow_sync_tran = N'false',
@allow_queued_tran = N'false',
@allow_dts = N'false',
@replicate_ddl = 1,
@allow_initialize_from_backup = N'true', -- Modify Here
@enabled_for_p2p = N'false',
@enabled_for_het_sub = N'false'
GO
/* SHOULD not need this since no snapshots will be generated
exec sp_addpublication_snapshot @publication = N'Zaragoza_Full',
@frequency_type = 1,
@frequency_interval = 1,
@frequency_relative_interval = 1,
@frequency_recurrence_factor = 0,
@frequency_subday = 8,
@frequency_subday_interval = 1,
@active_start_time_of_day = 0,
@active_end_time_of_day = 235959,
@active_start_date = 0,
@active_end_date = 0,
@job_login = N'NS-LAB-DB-40\SqlServiceUser',
@job_password = N'********',
@publisher_security_mode = 1
exec sp_addarticle @publication = N'Zaragoza_Full',
@article = N'__MigrationLog',
@source_owner = N'dbo',
@source_object = N'__MigrationLog',
@type = N'logbased',
@description = null,
@creation_script = null,
@pre_creation_cmd = N'drop',
@schema_option = 0x000000000803509F,
@identityrangemanagementoption = N'manual',
@destination_table = N'__MigrationLog',
@destination_owner = N'dbo',
@vertical_partition = N'false',
@ins_cmd = N'CALL sp_MSins_dbo__MigrationLog',
@del_cmd = N'CALL sp_MSdel_dbo__MigrationLog',
@upd_cmd = N'SCALL sp_MSupd_dbo__MigrationLog'
GO
-- MANY more "EXEC sp_addarticle"....
On the publisher
I recompile the subscription SPs since I had problems with them once.
I use the output from the following statement:
USE Zaragoza;
EXEC sp_scriptpublicationcustomprocs @publication=N'Zaragoza_Full';
On the publisher
I backup the database & log
BACKUP DATABASE Zaragoza TO DISK = 'E:\Backup\Zaragoza_FULL.bkp' WITH INIT, STATS=5;
BACKUP LOG Zaragoza TO DISK = 'E:\Backup\Zaragoza_LOG.bkp' WITH INIT, STATS=5;
On the subscriber
Copy the backups from the publisher
CD /D E:\Backup
COPY /Y \\NS-LAB-DB-38-mirror\Backup\Zaragoza_FULL.bkp .
COPY /Y \\NS-LAB-DB-38-mirror\Backup\Zaragoza_LOG.bkp .
On the subscriber
Restore the database and log backups
USE [master]
GO
RESTORE DATABASE Zaragoza_Sub
FROM DISK = 'E:\Backup\Zaragoza_FULL.bkp'
WITH NORECOVERY, REPLACE, STATS=5,
MOVE 'Zaragoza' TO 'I:\mssql_repl\Zaragoza_Sub\Zaragoza_Sub.mdf',
MOVE 'Zaragoza_log' TO 'I:\mssql_repl\Zaragoza_Sub\Zaragoza_Sub_log.ldf';
GO
RESTORE LOG Zaragoza_Sub
FROM DISK = 'E:\Backup\Zaragoza_LOG.bkp'
WITH RECOVERY, STATS=25;
GO
On the subscriber
Remove all triggers since I noticed that they interfered with the replication SPs
USE Zaragoza_Sub;
DECLARE @Trigger nvarchar(100),
@SQL nvarchar(2000);
DECLARE curTriggers CURSOR
LOCAL FAST_FORWARD FOR
SELECT DISTINCT tr.name TriggerName--, te.type_desc TriggerType, ob.name TableName, tr.is_disabled, c.text
FROM sys.triggers tr INNER JOIN
sys.trigger_events te ON tr.object_id = te.object_id INNER JOIN
sys.objects ob ON tr.parent_id = ob.object_id;
OPEN curTriggers;
FETCH NEXT FROM curTriggers INTO @Trigger;
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @SQL = 'DROP TRIGGER dbo.' + @Trigger + ';';
EXEC sp_executesql @SQL;
FETCH NEXT FROM curTriggers INTO @Trigger;
END;
CLOSE curTriggers;
DEALLOCATE curTriggers;
On the publisher
Add the subscription and the push agent
-----------------BEGIN: Script to be run at Publisher 'NS-LAB-DB-38'-----------------
use [Zaragoza]
exec sp_addsubscription @publication = N'Zaragoza_Full',
@subscriber = N'NS-LAB-DB-40',
@destination_db = N'Zaragoza_Sub',
@subscription_type = N'Push',
@sync_type = N'initialize with backup', --@sync_type = N'replication support only',
@status = N'active', -- ADD this line
@article = N'all',
@update_mode = N'read only',
@subscriber_type = 0,
@backupdevicetype=N'disk',
@backupdevicename=N'E:\backup\Zaragoza_LOG.bkp';
exec sp_addpushsubscription_agent @publication = N'Zaragoza_Full',
@subscriber = N'NS-LAB-DB-40',
@subscriber_db = N'Zaragoza_Sub',
@job_login = N'NS-LAB-DB-40\SqlServiceUser',
@job_password = N'********', -- Modify Here
@subscriber_security_mode = 1,
@frequency_type = 64,
@frequency_interval = 0,
@frequency_relative_interval = 0,
@frequency_recurrence_factor = 0,
@frequency_subday = 0,
@frequency_subday_interval = 0,
@active_start_time_of_day = 0,
@active_end_time_of_day = 235959,
@active_start_date = 20140618,
@active_end_date = 99991231,
@enabled_for_syncmgr = N'False',
@dts_package_location = N'Distributor';
GO
-----------------END: Script to be run at Publisher 'NS-LAB-DB-38'-----------------
The worst part is that this is only a LAB system, when I apply this to Live I will have to deal with a 24/7 environment with 10,000+ transactions a day, so downtime is a total No-No.
If you are missing any details do not hesitate to ask, I will gladly provide all the details I have.
Have a great day
DS

Hi Ashwin,
I have tried a few things these last couple of days and here's where I'm at.
I looked through the publisher database for the missing row so I could just copy it over but the row was nowhere to be found. After talking to the developers I found out that the table in question has a clean-up job that deletes records when they are finished
- OK, no problem, the replication should take care of that.
When I then look at the trace from the Distributor I find a bunch of records where the ID of the missing row is used. However, I find it peculiar that the replication first does updates to a record, then deletes it only to continue doing updates afterwards.
A sample from the Trace will explain better:
The SPs are
sp_MSupd_dboMessageDialog => This SP tries to do the failing UPDATE on the table, the second to last parameter is the RowId in the table (1075152)
sp_MSdel_dboMessageDialog => This SP tries to DELETE from the table, the only parameter is the RowId in the table (1075152)
There is one other SP in the replication of this article (table) and it is called sp_MSins_dboMessageDialog and it should be used for inserting records into the table. However it is never called.
RowNumber
EventClassName
TextData
EventSequence
StartTime
EndTime
2899078
RPC:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74255940
2014-08-13 14:22:15.763
NULL
2899372
SP:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74256234
2014-08-13 14:22:16.270
NULL
2899446
SP:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74256312
2014-08-13 14:22:16.270
2014-08-13 14:22:17.923
2899447
RPC:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74256313
2014-08-13 14:22:15.763
2014-08-13 14:22:17.923
2899462
RPC:Starting
exec [sp_MSdel_dboMessageDialog] 1075152
74256328
2014-08-13 14:22:17.927
NULL
2899558
SP:Starting
exec [sp_MSdel_dboMessageDialog] 1075152
74256420
2014-08-13 14:22:17.940
NULL
2899606
SP:Completed
exec [sp_MSdel_dboMessageDialog] 1075152
74256468
2014-08-13 14:22:17.940
2014-08-13 14:22:17.940
2899607
RPC:Completed
exec [sp_MSdel_dboMessageDialog] 1075152
74256469
2014-08-13 14:22:17.927
2014-08-13 14:22:17.940
2915054
RPC:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74272198
2014-08-13 14:22:56.577
NULL
2915118
SP:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74272262
2014-08-13 14:22:56.587
NULL
2915353
SP:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74272497
2014-08-13 14:22:56.587
2014-08-13 14:22:56.597
2915354
RPC:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74272498
2014-08-13 14:22:56.577
2014-08-13 14:22:56.597
2994616
RPC:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74352996
2014-08-13 14:26:13.227
NULL
2994701
SP:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74353159
2014-08-13 14:26:13.647
NULL
2994749
SP:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74353266
2014-08-13 14:26:13.647
2014-08-13 14:26:13.647
2994750
RPC:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74353267
2014-08-13 14:26:13.227
2014-08-13 14:26:15.163
2995292
RPC:Starting
exec [sp_MSdel_dboMessageDialog] 1075152
74353810
2014-08-13 14:26:15.240
NULL
2995331
SP:Starting
exec [sp_MSdel_dboMessageDialog] 1075152
74353849
2014-08-13 14:26:15.250
NULL
2995389
SP:Completed
exec [sp_MSdel_dboMessageDialog] 1075152
74353911
2014-08-13 14:26:15.250
2014-08-13 14:26:15.603
2995390
RPC:Completed
exec [sp_MSdel_dboMessageDialog] 1075152
74353912
2014-08-13 14:26:15.240
2014-08-13 14:26:15.603
3000727
RPC:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74359306
2014-08-13 14:26:29.413
NULL
3000795
SP:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74359374
2014-08-13 14:26:29.423
NULL
3000843
SP:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74359422
2014-08-13 14:26:29.423
2014-08-13 14:26:29.427
3000844
RPC:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74359423
2014-08-13 14:26:29.413
2014-08-13 14:26:29.427
3081879
RPC:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74441576
2014-08-13 14:29:56.223
NULL
3082017
SP:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74441868
2014-08-13 14:29:58.060
NULL
3082209
SP:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74442059
2014-08-13 14:29:58.060
2014-08-13 14:29:58.067
3082210
RPC:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74442060
2014-08-13 14:29:56.223
2014-08-13 14:29:58.070
3082470
RPC:Starting
exec [sp_MSdel_dboMessageDialog] 1075152
74442320
2014-08-13 14:29:58.097
NULL
3082471
SP:Starting
exec [sp_MSdel_dboMessageDialog] 1075152
74442321
2014-08-13 14:29:58.100
NULL
3082519
SP:Completed
exec [sp_MSdel_dboMessageDialog] 1075152
74442369
2014-08-13 14:29:58.100
2014-08-13 14:29:58.100
3082520
RPC:Completed
exec [sp_MSdel_dboMessageDialog] 1075152
74442378
2014-08-13 14:29:58.097
2014-08-13 14:29:58.400
3090751
RPC:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74450665
2014-08-13 14:30:17.940
NULL
3090796
SP:Starting
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74450712
2014-08-13 14:30:17.953
NULL
3090844
SP:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74450760
2014-08-13 14:30:17.953
2014-08-13 14:30:17.957
3090845
RPC:Completed
exec [sp_MSupd_dboMessageDialog] default,default,default,default,0,default,'2014-08-13 12:10:56.503',1075152,0x50
74450761
2014-08-13 14:30:17.940
2014-08-13 14:30:17.953
Correct me if I'm wrong but this seems a bit weird. Why don't I see any INSERT to create the row again after the DELETE?
For the time being, and since this is a test system, I added the parameter "-SkipErrors 20598" to the Distribution Agent and restarted the agent. The replication started by skipping 20 records with that error and then continuing to work fine, as
suspected. I will have to verify with the developers and testers to see if all the data is still available.
Hopefully you will have some great insight into this matter and be able to explain what is happening.
Cheers!
DS

Transactional replication with 1 publisher 2 subscribers in SQL 2012 SE

I have a setup of transaction replication between one publisher and subscriber in the Same server.Now, I need to add a new subscriber to the existing publisher. So publisher database name is DB_A and Subscriber 1 name is DB_B. So the new subscriber will
be DB_C.
Is this kind of setup possible on one server?
If yes then at the time of reinitialization is it going to apply the snapshot on DB_B as well as DB_C?
Also let say if due to disk error DB_B gets corrupted then will data be still replicated between DB_A and DB_C? (Assuming publisher, subscriber 1 and 2 are sitting on individual disks)
Need your valuable thoughts experts.
Thanks a ton.

For that you have to setup replication with backups. Assuming you had a failure and the only option now is to reinitialize, then instead you basically drop the subscription, change the publication property to
allow_initialize_from_backup to true. Now you can follow the article below to create the subscription. Instead of using the backup from publisher you can use the old backup of subscriber. In this case, you need to confirm that
all the data that is in the publisher (which needs to be replicated) is already there in subscriber.
http://msdn.microsoft.com/en-us/library/ms147834.aspx
Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

Transactional Replication To 2014

Hi All,
In our environment we are planning to move the subscriber and distributor to 2014 with publisher on 2008. So am doing some work around on this,
Since
Publisher can be assigned to only a single Distributor instance, can i perform the new setting only through downtime as already a replication is running?
Can I perform this replication without disturbing the current setup.?
Do I need to look into any scenario/conditions except load balancing before setting up this replication?
Thanks
Moug
Best Regards Moug

Thanks for the link. Yes the current setup is in 2008, am planning to move only distributor and subscriber. I read the article which you suggested, as per the I need to upgrade the Sql to 2014 in the current server whereas my requirement is to different
new server. So do i need to stop all the jobs in old server and setup a replication to new server or i can perform while replication is online.?
Thanks.
Best Regards Moug
Hi Moug,
According to your description, you had configured transactional replication on Servers, and now you want to upgrade distributor and subscribers.
As other post, before upgrading distributor and subscribers, usually, we need to make sure that all committed transactions have been completely processed by the Log reader agent, in addition, generate scripts for the entire replication topology
and store them in a safe place. These scripts will help to recreate replication if needed or the upgrade breaks replication.
After performing the SQL Server 2014 upgrade on the Server, although you can restore the a backup of a replicated database from an earlier version to a server and make sure that database have the same names as the original server and preserved
replication setting, it is rarely used as an upgrade process. Personally, after you upgrading distributor and subscribers on the servers,
I recommend you recreating the database and replication configuration from the above scripts, then restart SQL Server Agent and the Log Reader Agent.
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

Setup Transactional Replication on Mirrored database

Similar Messages

Maybe you are looking for