sqlserver关于发布订阅replication_subscription的总结

官方文档https://docs.microsoft.com/zh-cn/sql/relational-databases/replication/subscribe-to-publications?view=sql-server-2017

Replicaiton的报错代码说明及解决方法说明的官方文档
https://docs.microsoft.com/en-us/sql/relational-databases/replication/errors-and-events-reference-replication?view=sql-server-ver15
https://docs.microsoft.com/zh-cn/sql/relational-databases/replication/errors-and-events-reference-replication?view=sql-server-2017

同步数据是指在订阅服务器上应用初始快照后，在发布服务器和订阅服务器之间传播数据和架构更改的过程。 同步可按下列方式发生：
连续，这是事务复制的典型方式。
按需，这是合并复制的典型方式。
根据计划，这是快照复制的典型方式。

同步订阅时，根据您所使用的复制类型的不同，将发生不同的过程。
快照复制。 同步是指分发代理在订阅服务器上重新应用快照，以便订阅数据库与发布数据库上的架构和数据一致。
如果在发布服务器上修改了数据或架构，则必须生成一个新快照，以便将修改传播到订阅服务器。
事务复制。 同步是指分发代理将更新、插入、删除及其他更改从分发数据库传输到订阅服务器。
合并复制。 同步是指合并代理从订阅服务器向发布服务器上载更改，然后再从发布服务器向订阅服务器下载更改。 将检测并解决冲突（如果有）。 数据被收敛，发布服务器和所有订阅服务器将最终达到相同的数据值。 如果检测到冲突并解决了冲突，则一些用户已提交的工作将更改为根据您定义的策略来解决冲突。

事务复制的工作机制
事务复制是由 SQL Server 快照代理、日志读取器代理和分发代理实现的。
快照代理准备快照文件（其中包含了已发布表和数据库对象的架构和数据），然后将这些文件存储在快照文件夹中，并在分发服务器中的分发数据库中记录同步作业。
日志读取器代理监视为事务复制配置的每个数据库的事务日志，并将标记为要复制的事务从事务日志复制到分发数据库中，分发数据库的作用相当于一个可靠的存储-转发队列。
分发代理将快照文件夹中的初始快照文件和分发数据库表中的事务复制到订阅服务器中。
在发布服务器中所做的增量更改根据分发代理的计划流向订阅服务器，分发代理可以连续运行以尽量减少滞后时间，也可以按预定的时间间隔运行。

因为日志读取器代理(对应如下3的TESTDB1-replicate2-2)会把发布数据库的事务日志复制一份到分发数据库中， 所以发布数据库并不需要在完整恢复模式下，如果日志读取器没能完成复制就发生发布数据库的事务日志又将要截断时，则发布数据库的事务日志状态sys.databases.log_reuse_wait_desc会显示为Replication以阻止发布数据库的事务日志发生截断

事务复制原理通俗理解：
原始基础数据对应快照(快照代理生成存放在快照目录中)+增量数据对应日志(日志读取器代理捕获存放在分发服务器的distribution数据库中)
快照+日志都是通过分发代理(通俗意义上的订阅job)传送到订阅服务器的，也就是官方文档这句话：分发代理将快照文件夹中的初始快照文件和分发数据库表中的事务复制到订阅服务器中。

快照代理(通俗解释就是生成快照的那个job，每个发布都有一个这样的job)
日志读取器代理(通俗解释就是监视日志并把日志写入到distribution数据库的那个job，同一个数据库下所有的发布共用同一个这样的job，也就是说这个job数量只和发布数据库有多少个有关，和有多少个发布没有关系)
分发代理(通俗解释就是订阅job)：对于推送订阅，分发代理在分发服务器上运行；对于请求订阅，分发代理在订阅服务器上运行。 该代理将事务从分发数据库移动到订阅服务器中。
快照文件和distribution数据库中记录什么时候清理，都是distribution.dbo.sp_MSdistribution_cleanup在做，默认清理3天前的，也就是说一般快照文件会在3天后自动消失
重新生成快照，只会把生成快照前新加入发布的表同步到订阅端，而不会对发布下面的订阅进行初始化，如果发布的表产生的日志很多很频繁的情况下导致分发代理总是很慢从而导致订阅服务器数据总是落后于发布服务器，想通过定期重新生成快照来定期使订阅服务器数据追上发布服务器，这种方式是不可能成功的，只有定期对订阅执行初始化才能实现这一目的

对于事务复制，是否生成快照取决于发布属性 MSpublications.immediate_sync 的设置。 如果该属性设置为 TRUE（使用新建发布向导时的默认设置），则每当运行快照代理时都会生成快照，而且可以随时将其应用到订阅服务器。 如果该属性设置为 FALSE（使用 sp_addpublication 时的默认设置），则仅当自上次快照代理运行以来添加了新订阅时，才会生成快照；订阅服务器必须等待快照代理完成，才能实现同步。

快照复制和事务复制，当发生重新初始化时，订阅服务器上所做的但尚未与发布服务器同步的任何更改都将在应用新快照时被覆盖。
订阅标记为要重新初始化时，可以选择下列选项之一：
使用当前快照：选择此项可以在分发代理或合并代理下一次运行时将当前快照应用于订阅服务器。 如果无法获得有效快照，将无法选定此选项。
使用新快照：选择此项可以用新的快照来重新初始化订阅。 只有在快照代理已经生成新快照之后，才能将其应用于订阅服务器。 如果快照代理设置为按计划运行，则直到下一个计划的快照代理运行后才能重新初始化订阅。 “使用新快照”选项下面还有一个子选项“立即生成新快照”，选择 “立即生成新快照” 可以立即启动快照代理。

问题1：事务复制，一旦发布重新生成快照，是不是就是自动对发布下面的订阅进行初始化了？
现象1.1：发布端发布了A1、A2、A3张表，已经同步到了订阅端，订阅端删除A2表，发布端重新生成这3张表的快照，发现订阅端并没有新增A2表
现象1.2：发布端发布了A1、A2、A3张表，已经同步到了订阅端，订阅端删除A2表，发布端再新增A4表并重新生成这4张表的快照，发现订阅并没有新增A2表但是新增了A4表
结论1：重新生成快照，只会把生成快照前新加入发布的表同步到订阅端，而不会对发布下面的订阅进行初始化
结论2：如果发布的表产生的日志很多很频繁的情况下导致分发代理总是很慢从而导致订阅服务器数据总是落后于发布服务器，想通过定期重新生成快照来定期使订阅服务器数据追上发布服务器，这种方式是不可能成功的
结论3：如果发布的表产生的日志很多很频繁的情况下导致分发代理总是很慢从而导致订阅服务器数据总是落后于发布服务器，如果想定期使订阅服务器数据追上发布服务器，只有定期对订阅执行初始化才能实现这一目的，官方文档有这么一句话：快照复制和事务复制，当发生重新初始化时，订阅服务器上所做的但尚未与发布服务器同步的任何更改都将在应用新快照时被覆盖。

问题2：事务复制，如果发布服务器的快照文件都已经应用到了订阅服务器，订阅服务器已经开始使用发布端产生的日志了，那么发布服务器的快照文件什么时候被清理？
现象1：发布端生成的快照文件会存放在一个目录，发现3天后这些快照文件自动消失了
现象2：发布端生成的快照文件会存放在一个目录，12小时候，执行EXEC distribution.dbo.sp_MSdistribution_cleanup @min_distretention = 0, @max_distretention = 12，发现这些快照文件也消失了
结论1：快照文件的消失时间和distribution.dbo.sp_MSdistribution_cleanup清理事务日志时间一样，也就是说distribution.dbo.sp_MSdistribution_cleanup会同时清理快照文件和清理事务日志一样，快照文件
结论2：右键发布–属性–Subcription Options–snapshot always available，此选项和发布端的快照文件什么时候被清理没有任何关系，此选项只是在创建发布的时候勾选“Create a snapshot immediately and keep the snapshot available to initialize subscription”有关，如果勾选了，则snapshot always available为true，否则false，也就是sp_addpublication.@immediate_sync =ture则发布–属性–Subcription Options–snapshot always available，意思就是每次运行快照代理时创建或重新创建同步文件。

问题3：为什么"Distribution clean up: distribution"作业会报错was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction
解释：清理分发数据库中MSrepl_commands的job作业"Distribution clean up: distribution"和log reader agent日志读取器代理job作业会互相堵塞，两个job一个delete删除MSrepl_commands一个insert写MSrepl_commands，所以如果有事务量过大或复制条目过多的表，因为两个job直接的互相堵塞会造成严重的等待，一旦log reader agent日志读取器代理job被堵塞，这所有的发布都要等待，这样replication延迟越来越严重。

问题4：拿掉一个发布上的表后，不重新生成快照或初始化，对该表进行写入，该表会重新同步到订阅端吗？后面把这个表重新加入发布，需要重新生成快照或初始化吗？
已经实验，不重新生成快照或初始化的情况下，对该表进行写入，新数据不会同步到到订阅端，订阅端的数据也没被删除，订阅端保持该表从发布中拿掉之前的状态
已经实验1：把这个表重新加入发布，在发布端对这张表的写入不会同步到订阅端，而发布端其他表的数据会同步到订阅端
已经实验2：需要重新生成快照或初始化，这张表的数据才会从发布端正常同步到订阅端

问题5：现有一个发布，后面往这个发布中新增一张表，这个新增的表会自动同步到订阅库吗?
已经实验：不会，只有初始化订阅或重新生成快照才会同步到订阅库

问题6：现有发布中有一张表，有10个字段，只发布了3个字段，后面新增一个发布字段，这个新增的发布字段会自动同步到订阅库吗?
已经实验：会，因为一旦在发布里面增加一个字段，就自动提示需要reinitialized subscription初始化订阅，所以新增字段成功的话，该字段就会自动同步到订阅库

问题7：
一个数据库下6个发布订阅，一个发布订阅的同步出现问题，会影响其他5个发布订阅的同步吗？
已经实验：不会

问题8：
一个发布下面有两个订阅，一个订阅出现问题，会影响另一个订阅吗？
已经实验：不会

快照代理、log reader、分发代理的job 查询
查询某个发布对应的snapshot agent快照代理job的名称

select publication,name snapshot_agent_job from distribution.dbo.MSsnapshot_agents 
或
select a.name publication_name,b.name job_name from wondb.dbo.syspublications a inner join msdb.dbo.sysjobs b on a.snapshot_jobid=b.job_id

查询某个发布数据库对应的log reader agent日志读取器代理job的名称

Select name job_name,publisher_db,publication  from distribution.dbo.MSlogreader_agents

备注：同一个数据库下所有的发布共用同一个这样的job，见publication字段值默认是ALL

查询分发代理job的名称，推送订阅，分发代理在分发服务器上运行；对于请求订阅，分发代理在订阅服务器上运行
推送订阅：在分发服务器上分发数据库默认是distribution上执行

Select name,subscriber_job,publisher_db,publication from distribution.dbo.MSdistribution_agents a where a.subscriber_db<>'virtual' and a.local_job=1 and a.subscription_type=0

请求订阅：在订阅服务器上的订阅库上执行

select publisher,publisher_db,publication,subscription_type,distribution_agent distribution_agent_job  from MSreplication_subscriptions 

同步延迟的判断和查找,发布端–>分发端–>订阅端
关键点：[distribution].[dbo].MSlogreader_history需要确定延迟究竟是指历史时刻点的已经发生的延迟，还是历史时刻点开始的延迟？
比如现在是3点，记录消息的时间time是1点，delivery_latency是30分钟，如果是历史时刻点的已经发生的延迟，那么就是说截止1点，已经延迟了30分钟了，也就是从12点30开始就开始延迟了。如果是历史时刻点开始的延迟，那么就是从1点开始延迟，会延迟30分钟，预计到1点30分钟延迟结束。通过launch replication monitor图形界面+sql语句，得出结论是历史时刻点的已经发生的延迟，因为当时通过图形界面已经查看到分发端未传输到订阅端的命令有60万条，预计需要11分钟传递到订阅端了，当时sql语句查询表[distribution].[dbo].MSdistribution_status发现有60万条记录没有传输到订阅端，但是表[distribution].[dbo].MSdistribution_history查询下来发现没有延迟，11分钟后再查，发现表[distribution].[dbo].MSdistribution_history的延迟是11分钟了

监控replication事务复制延迟的过程和系统表

distribution.dbo.sp_replcounters --无须参数
distribution.dbo.sp_replmonitorhelpsubscription  --只需特点参数，比如 @publisher_db ='wondb',@publication_type=0
distribution.dbo.sp_replmonitorsubscriptionpendingcmds --需要提供所有参数
distribution.dbo.MSdistribution_status 
distribution.dbo.MSreplication_monitordata 

监控replication事务复制延迟的图形界面工具
SSMS-右键点击发布–Launch Replication Monitor–Replication Monitor–My Publishers–服务器名称–发布名称–第二列跟踪令牌–插入跟踪器
Tracer Tokens measure latency from Publisher to Distributor,Distributor to Subscriber
每点击一次插入跟踪器就会记录当前的延迟，1点的时候点击一次则记录1点的延迟，2点的时候点击一次则记录2点的延迟

发布端到分发端的延迟，最近2小时内某个历史时刻点已经发生的延迟信息

select delivery_latency/1000 latency_seconds,getdate() now,time, * from [distribution].[dbo].MSlogreader_history(nolock) where [time] >= DATEADD(HOUR, -2, GETDATE()) order by 1 desc

表MSlogreader_history意思：The MSlogreader_history table contains history rows for the Log Reader Agents associated with the local Distributor
字段delivery_latency意思：命令从进入发布数据库到进入分发数据库之间的滞后时间。 以毫秒为单位。
字段time意思：记录消息的时间。

分发端到订阅端的延迟，最近2小时内某个历史时刻点已经发生的延迟信息

select delivery_latency/1000 latency_seconds,current_delivery_latency/1000 current_latency_seconds,
getdate() now,a.time,b.publication,b.publisher_db,b.name,a.*,b.* from [distribution].[dbo].MSdistribution_history(nolock) a 
inner join [distribution].[dbo].MSdistribution_agents(nolock) b on a.agent_id=b.id
and a.[time] >= DATEADD(HOUR, -2, GETDATE()) order by 2 desc

表MSdistribution_history意思：The MSdistribution_history table contains history rows for the Distribution Agents associated with the local Distributor
字段delivery_latency意思：命令从进入分发数据库到应用于订阅服务器之间的滞后时间。 以毫秒为单位。
字段current_delivery_latency意思：自从最后一个历史记录条目后，命令从进入分发数据库到应用于订阅服务器之间的滞后时间。 以毫秒为单位。
字段time意思：记录消息的时间。

发布端到订阅端的延迟

exec Wondadb3.distribution.dbo.sp_replmonitorhelpsubscription @publisher_db ='wondb',@publication_type=0

返回结果的latency字段意思：The highest latency, in seconds, for data changes propagated by the Log Reader or Distribution Agents for a transactional publication.在事务发布中，由日志读取器代理或分发代理传播的数据更改的最长滞后时间，以秒为单位

发布端没有传输到分发端的命令行信息
目前没有找到方法可以查出发布端没有传输到分发端的命令行信息

分发端没有传输到订阅端的命令行信息，记录的是此刻没有传输到订阅端的信息

select b.publication,b.publisher_db,b.name,c.article,a.* from [distribution].[dbo].MSdistribution_status(nolock) a 
inner join [distribution].[dbo].MSdistribution_agents(nolock) b on a.agent_id=b.id
inner join [distribution].[dbo].MSarticles(nolock)  c on a.article_id=c.article_id and b.publisher_db=c.publisher_db order by UndelivCmdsInDistDB desc

视图MSdistribution_status意思：The MSdistribution_status view exposes(公开，披露) additional information on the status commands in the distribution database.
备注：查到了没有传输到订阅端的命令对应的agent_id或article，不代表这些agent_id或article在此刻有延迟，即这些agent_id或article在系统表[distribution].[dbo].MSdistribution_history可能查到delivery_latency=0

关于replication_subscription常用的SQL查询语句

分发库中的MSrepl_commands表的行数

select count(*) from distribution.dbo.MSrepl_commands with (nolock)

分发库中的MSrepl_commands表的行数和表的容量大小

EXEC distribution..sp_spaceused 'MSrepl_commands'

监控发布订阅是否有异常，执行以下5条语句即可

select * from [distribution].[dbo].[MSlogreader_history] WHERE error_id != 0 AND [time] >= DATEADD(HOUR, -1, GETDATE()) 
select * from [distribution].[dbo].[MSdistribution_history] WHERE error_id != 0 AND [time] >= DATEADD(HOUR, -1, GETDATE()) 
select * from [distribution].[dbo].[MSsnapshot_history] WHERE error_id != 0 AND [time] >= DATEADD(HOUR, -1, GETDATE()) 
select * from [distribution].[dbo].MSrepl_errors order by 2 desc
select * from msdb.dbo.sysreplicationalerts order by 7 desc

查询某个发布XX，发布的数据库对象的2种方法
1、发布数据库上执行(数据来源这三张表distribution.dbo.MSpublications、

distribution.dbo.MSarticles、sysarticlecolumns) 
select a.article,a.source_object,a.destination_object,b.colid from 
(select article,article_id,source_object,destination_object 
from [distribution].[dbo].MSarticles where publication_id in 
( select publication_id from 
[distribution].[dbo].MSpublications where publication='XX' 
) 
) a 
inner join 
(select * from replicate1.dbo.sysarticlecolumns) b 
on a.article_id=b.artid order by a.article 

2、订阅数据库上执行

select distinct article from MSreplication_objects where publication='XX'

查询某个发布对象比如表XX，存在那个发布，订阅到哪个数据库中

select a.publisher_db,d.id publisher_database_id,b.publication,a.article,a.article_id,c.subscriber_db,a.destination_object,c.article_id,c.subscription_time 
from [distribution].[dbo].MSarticles(nolock) a 
inner join [distribution].[dbo].MSpublications(nolock) b 
on a.publication_id=b.publication_id 
inner join [distribution].[dbo].MSsubscriptions(nolock) c 
on a.publication_id=c.publication_id and a.article_id=c.article_id
inner join [distribution].[dbo].MSpublisher_databases(nolock) d
on a.publisher_db=d.publisher_db
and a.article='XX'

查询存在订阅中但是不存在发布中的表

select distinct publisher_db,publication,article from dbprod131a.wondb.dbo.MSreplication_objects where publisher_db='wondb'
except 
select a.publisher_db,b.publication,a.article
from dbprod129.[distribution].[dbo].MSarticles a inner join dbprod129.[distribution].[dbo].MSpublications b
on a.publication_id=b.publication_id and a.publisher_db=b.publisher_db and a.publisher_db='wondb'

查询存在发布中但是不存在订阅中的表

select a.publisher_db,b.publication,a.article
from [distribution].[dbo].MSarticles a inner join [distribution].[dbo].MSpublications b
on a.publication_id=b.publication_id and a.publisher_db=b.publisher_db and a.publisher_db='wondb'
except 
select distinct publisher_db,publication,article from dbprod131a.wondb.dbo.MSreplication_objects where publisher_db='wondb'

查询最近哪张表产生了最多的发布事务

select publisher_database_id,article_id,count(*) from [distribution].[dbo].[MSrepl_commands](nolock) group by publisher_database_id,article_id order by count(*) desc
select b.publication,a.publisher_db, a.article,a.article_id
from [distribution].[dbo].MSarticles  a
inner join [distribution].[dbo].MSpublications b
on a.publication_id=b.publication_id
inner join [distribution].[dbo].MSpublisher_databases(nolock) c
on a.publisher_db=c.publisher_db
and c.id=XX and a.article_id=YY

查询发布订阅延迟时，哪些发布命令正在延迟
1、订阅端执行如下

select transaction_timestamp,publisher,publisher_db,publication,subscription_type,distribution_agent distribution_agent_job  from MSreplication_subscriptions

2、分发端执行如下，Xact_seqno条件中使用第一步的transaction_timestamp值

select top 100 Xact_seqno, count(*) as Xcount from distribution..msrepl_commands with (nolock)
where publisher_database_id in (select id From distribution..MSpublisher_databases where publisher_db = 'wondb')
and  Xact_seqno > 0x00E02FAF0001FEC101A3000000000000
group by Xact_seqno
--having count(*)> 1000
order by Xcount desc

3、发布端执行如下，参数xact_seqno_start和xact_seqno_end都使用第二步的Xact_seqno值

sp_browsereplcmds '0x00E02FAF0004BDDC0001','0x00E02FAF0004BDDC0001'

查询没有分发的命令和复制的延迟(感觉还是distribution.dbo.MSdistribution_status和distribution.dbo.sp_replmonitorhelpsubscription两者更简单)
逻辑：一个publication，只要MSrepl_commands里的事务序列号大于MSdistribution_history的事务序列号，就算作是还没分发的commands，即代码中的MSrepl_commands.xact_seqno>MSdistribution_history.maxseq

SELECT
	@@SERVERNAME as server_name,
	mda.publisher_db,
	mp.publication as publication_name,
	mda.name as agent_name,
	mda.subscriber_db,
	CASE
		WHEN mda.subscription_type = '0' THEN '0, Push'
		WHEN mda.subscription_type = '1' THEN '1, Pull'
		WHEN mda.subscription_type = '2' THEN '2, Anonymous'
	END subscription_type,
	CASE
		WHEN de2.runstatus = '1' THEN '1, Start'
		WHEN de2.runstatus = '2' THEN '2, Succeeded'
		WHEN de2.runstatus = '3' THEN '3, In Progress'
		WHEN de2.runstatus = '4' THEN '4, Idle'
		WHEN de2.runstatus = '5' THEN '5, Retry'
		WHEN de2.runstatus = '6' THEN '6, Failed'
	END runstatus,
	ISNULL(und.undelivered_commands,0) as undelivered_commands,
	de2.agent_id,
	de2.start_time,
	de2.time as last_time,
	de2.duration,
	de2.comments,
	de2.current_delivery_rate,
	de2.current_delivery_latency,
	de2.delivered_transactions,
	de2.delivered_commands
FROM
	distribution.dbo.MSpublications mp
LEFT JOIN
	distribution.dbo.MSdistribution_agents mda on mp.publication = mda.publication
	AND mda.subscriber_db <> 'virtual'
LEFT JOIN
	(
	SELECT
		mdh.agent_id,
		mdh.start_time,
		mdh.time,
		mdh.duration,
		mdh.comments,
		mdh.current_delivery_rate,
		mdh.current_delivery_latency,
		mdh.delivered_transactions,
		mdh.delivered_commands,
		mdh.runstatus
	FROM
		distribution.dbo.MSdistribution_history mdh
	INNER JOIN
		(
		SELECT
			agent_id,
			max(time) as last_time
		FROM
			distribution.dbo.MSdistribution_history mdh
		GROUP BY
			agent_id
		) de ON de.agent_id = mdh.agent_id
			AND de.last_time = mdh.[time]
	) de2 on mda.id = de2.agent_id
LEFT JOIN
  (SELECT
		s.agent_id,
		MaxAgentValue.[time],
		SUM(CASE WHEN t.xact_seqno > MaxAgentValue.maxseq THEN 1 ELSE 0 END) AS undelivered_commands
  FROM distribution.dbo.MSrepl_commands t
  INNER JOIN distribution.dbo.MSsubscriptions AS s ON (t.article_id = s.article_id AND t.publisher_database_id=s.publisher_database_id )
  INNER JOIN
    (SELECT hist.agent_id, MAX(hist.[time]) AS [time], h.maxseq
    FROM distribution.dbo.MSdistribution_history hist
    JOIN (SELECT agent_id,ISNULL(MAX(xact_seqno),0x0) AS maxseq
    FROM distribution.dbo.MSdistribution_history
    GROUP BY agent_id) AS h
    ON (hist.agent_id=h.agent_id AND h.maxseq=hist.xact_seqno)
    GROUP BY hist.agent_id, h.maxseq
    ) AS MaxAgentValue
  ON MaxAgentValue.agent_id = s.agent_id
  GROUP BY s.agent_id, MaxAgentValue.[time]
  ) und
ON mda.id = und.agent_id AND und.time = de2.time
WHERE mda.subscriber_db <> 'virtual'
ORDER BY
	mda.publisher_db,
	mp.publication,
	mda.name

发布到订阅的延迟，创建令牌的方式
1、执行如下语句得出创建令牌的语句，把创建令牌的语句拿出来再执行一下创建令牌

SELECT publisher_db+'.sys.sp_posttracertoken @publication = '''+publication+'''' FROM distribution.DBO.MSpublications

2、再执行如下语句，查询延迟，如果dbo.MStracer_tokens表的字段distributor_commit、

publisher_commit、subscriber_commit在当前时间点的结果都是null，说明发布订阅正经历延迟
SELECT dm.publisher_db,dm.publication,t.publisher_commit,t.distributor_commit,h.subscriber_commit,Datediff(s,t.publisher_commit,t.distributor_commit) as 'dist_diff',Datediff(s,t.distributor_commit,h.subscriber_commit) as 'subs_diff' 
FROM (SELECT mt.* FROM distribution.dbo.MStracer_tokens mt JOIN 
(SELECT publication_id,MAX(tracer_id) mtid FROM distribution.dbo.MStracer_tokens GROUP BY publication_id) mtgid
on mt.publication_id=mtgid.publication_id AND mt.tracer_id=mtgid.mtid) t
JOIN distribution.dbo.MStracer_history h
ON t.tracer_id = h.parent_tracer_id
JOIN distribution.dbo.MSpublications dm ON t.publication_id=dm.publication_id
where Datediff(s,t.publisher_commit,t.distributor_commit)+Datediff(s,t.distributor_commit,h.subscriber_commit) > 1200 
or Datediff(s,t.publisher_commit,t.distributor_commit) is null
or Datediff(s,t.distributor_commit,h.subscriber_commit) is NULL
OR t.distributor_commit IS NULL
OR t.publisher_commit IS NULL
OR h.subscriber_commit IS NULL 

1、如果操作发布订阅的客户端SSMS版本比服务器端版本低，会报错，比如service是sqlserver2016，ssms使用sqlserver2014会报错
2、只建立分发时，会新增7个相关job；初次建立发布的同时建立分发，会新增9个相关job
3、后面每新增一个发布名，发布服务器上会新增两个发布的job如下，前一个是不停的生成发布数据，该job不停运行，后一个是初始化发布数据（生成unc目录下的文件和文件），运行一次就可以了
TESTDB1-replicate2-2
TESTDB1-replicate2-pub_replicate2-2
发布实例名–数据库名–发布名的序号
发布实例名–数据库名–发布名–发布名的序号
4、发布服务器-复制-本地发布-发布名-右键-属性-snapshot，选择put files in the following folder，可以把文件放到共享路径
5、订阅，可以在订阅服务器建立，也可以在发布服务器建立，发布服务器-复制-本地发布-发布名，右键选择new subscriptions
6、后面每新增一个订阅，如果是推送订阅，主库增加一个job，如果是请求订阅，从库增加一个job
TESTDB1-replicate2-replicate2-TESTDB2-6（推送订阅，发布实例名-发布数据库名-发布名-订阅实例名-编号）
TESTDB1-replicate1-pub_replicate1-TESTDB2-replicate_01-CD7A365E-2DE7-47A3-B31E-70F785FA71F2（请求订阅）
7、发布job或订阅job，都可以根据需要修改scheduler
8、本地发布或本地订阅下面的订阅图标有小圈圈，表示在当前实例下，是对方主动而不是当前实例主动，订阅的job在对方那边
推送订阅，在主库发布下面的订阅图标没有蓝色小圈圈，在从库订阅下面的订阅图标有蓝色小圈圈
请求订阅，在主库发布下面的订阅图标有蓝色小圈圈，在从库订阅下面的订阅图标没有蓝色小圈圈
–也适用于本地发布又是本地订阅的情况，比如本地一个库信息传输到本地另一个库，则本地发布或本地订阅下面都有订阅，如果是推送订阅，则发布下面的订阅图标没有蓝色小圈圈，订阅下面的订阅图标有蓝色小圈圈，如果是请求订阅，则发布下面的订阅图标有蓝色小圈圈，订阅下面的订阅图标没有蓝色小圈圈
9、订阅的删除，根据推送订阅和请求订阅的不同，有不同操作方式，统一的操作方法就是直接删除主库发布下面的订阅。
推送订阅的情况下，如果只在从库删除订阅，则主库的发布下面的订阅信息还在，主库上的订阅job也还在（但是信息不会同步到订阅库了），还需要在主库再删除一遍
推送订阅的情况下，在主库删除订阅的话，主库上的订阅job也不在了，从库的订阅信息也自动删除了
请求订阅的情况下，在主库删除订阅的话，从库上的订阅job也不在了，从库的订阅信息也自动删除了
请求订阅的情况下，在从库删除订阅的话，从库上的订阅job不在了，主库上的发布下面的订阅信息也不在了
–也适用于本地发布又是本地订阅的情况，比如本地一个库信息传输到本地另一个库，则本地发布或本地订阅下面都有订阅
10、发布的job在msdb.dbo.sysjobs正常记录，但是这些job运行时在sysprocesses.program_name都是显示Microsoft SQL Server，不显示为具体的job名称，如下语句查询job，不适用于订阅复制
select * from msdb.dbo.sysjobs where name=‘jobname’
select a.program_name,a.* from master…sysprocesses a where a.program_name like ‘%0D1CE57E8AC5%’
11、订阅的job在msdb.dbo.sysjobs正常记录，但是这些job运行时在sysprocesses.program_name都是显示为空
12、删除订阅数据库时，出现如下，解决方法是把订阅的job停掉再把订阅数据库offline，再删除
Cannot drop the database ‘XXX’because it is being used for replication
13、删除发布，如果发布下面有订阅，则删除发布的时候，订阅就失效了
请求订阅的情况下，从库的本地订阅下面还有订阅和job，但是失效了，还需要手工删除一下订阅，此时会自动删除job
推送订阅的情况下，主库的发布和job都删除了，从库的本地订阅下面还有订阅，但是失效了，还需要手工删除一下
–也适用于本地发布又是本地订阅的情况，比如本地一个库信息传输到本地另一个库，则本地发布或本地订阅下面都有订阅
14、订阅库，可以执行DML，执行delete不会有什么后遗症，执行update或insert的话，如果后面收到发布库传过来的数据，可能会产生冲突
15、发布订阅相关的存储过程
EXEC distribution.dbo.sp_replmonitorhelppublisher --发布库上执行，检查发布服务器上的本地发布的情况
16、发布建立好后，发布服务器上有一个linked sever指向分发服务器，名称一般为repl_distributor，disable publishing and distribution后，该linked server会自动删除
订阅建立后(不管是请求订阅还是推送订阅)，会在发布服务器上自动建立一个linked server指向订阅服务器。删除发布或disable publishing and distribution，该linked server都不会自动删除
17、如果订阅的job的schedules没有明确指定，只是start automaticaly when SQL Server Agent starts，那么一旦把这个job停止，后面不会再同步了，在Replication Monitor里面的Subscription Watch List看到这个订阅的status就是not running
18、推送订阅：到发布服务器下面的本地发布-发布名称-订阅名，右键选择view Synchronization Status可以看到订阅状态
请求订阅：到订阅服务器下面的本地订阅-订阅名，右键订阅，选择view Synchronization Status可以看到订阅状态，并可以看到订阅job的运行情况
19、复制-本地订阅-订阅名，右键选择view Synchronization Status查看到状态是No replicated transactions are available，则到发布端，复制-本地发布-发布名，右键发布，选择如下两者，查看job状态是否start运行中，如果是，再count(*)主从表数据是否一致，如果一致，说明此时确实没有DML事务产生新的数据
View Snapshot Agent Status查看快照代理状态，对应的job其实是"实例名-发布数据库名-发布名称-发布序号"，一般只运行一次，生成存放在unc中的初始化数据
View Log Reader Agent Status查看日志读取器代理状态，对应的job其实是"实例名-发布数据库名-发布序号"，一般一直运行
20、所谓的分发服务，就是创建一个分发数据库默认是distribution，并创建snapshot目录，如果没有创建分发，初次建立发布的时候，会自动建立分发服务，第二次建立发布的时候，会使用原来的分发服务。创建发布时，必须要先有分发，要不发布的数据存放在哪呢？分发就是存放这些要发布的数据的地方
21、分发服务器是发布服务器与订阅服务器之间的桥梁，起着存储区的作用，负责复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器上的单个数据库（称作分发数据库）相关联。分发数据库从发布服务器获得要发布的数据后将存储复制状态数据和有关发布的元数据，并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在大多数情况下，一个数据库服务器实例充当发布服务器和分发服务器两个角色。当发布服务器和分发服务器在同一个数据库实例中时，称为“本地分发服务器”。当发布服务器和分发服务器按各自的数据库服务器实例配置时，把分发服务器称为“远程分发服务器”
22、没有建立过分发时，右键replication时，有configure distribution，选择configure distribution表示只配置分发，不做其他动作，在此过程中如果在Publishers页面勾选了publisher和distribution database，则右键replication时，没有了configure distribution，取而代之的是publisher properties、distributor properties、disable publishing and distribution；如果在Publishers页面没有勾选publisher和distribution database，则右键replication时，没有了configure distribution，取而代之的是Distributor Properties、Disabled Publishing and Distribution Wizard。其实右键replication选择configure distribution时勾选了publisher和distribution database，就是选择哪些发布服务器可以使用这个分发服务器（enable servers to use this distributor when they become publishers），其中distribution database没得选，就是分发的数据库，默认是distribution
23、右键Replicattion选择Disabled Publishing and Distribution Wizard，禁用订阅发布，所有的订阅发布信息都丢失了包括system databases里的distribution数据库也包括unc目录下的所有目录和文件，所以执行之前需要对订阅发布信息进行备份或截图
24、要初始化订阅，即重新把发布端的数据推送到订阅端，可以选择推送到这个发布的单个订阅（发布端–发布名称–订阅名称–右键–reinitialize），也可以选择推送到这个发布的所有订阅（发布端–发布名称–右键–reinitialize all subscriptions）。再在发布服务器-复制-本地发布-发布名，右键选择View Snapshot Agent Status选择start，或运行job"实例名-发布数据库名-发布名称-发布序号"
25、在订阅端的表里手工先insert一条语句，后面发布端同步一条一样数据过来的时候，订阅端会报错
Violation of PRIMARY KEY constraint ‘PK_XX’. Cannot insert duplicate key in object ‘dbo.TXX’. The duplicate key value is (33583).
26、bug问题：右键Replicattion选择Disabled Publishing and Distribution Wizard后，最后一步会报错，但是确实把发布和分发都删除了
27、导出订阅复制的脚本的方法：右键Replication选择Generate Scripts(导出脚本里面有注释，在发布端执行还是订阅端执行)
以上会导出当前服务器下的分发、发布、订阅，如果在Generate Scripts跳出的界面勾选了distributor properties则会导出分发；勾选了publications in the following data sources则会导出发布；如果勾选了subscriptions in the following data sources则会导出订阅。
28、某个发布XX丢失了，但是请求订阅还在的处理方法
订阅端执行如下，找到发布的数据库对象，再在发布端创建发布，再重建订阅
select distinct article from MSreplication_objects where publication=‘XX’
如下方法不行
把发布数据库恢复到丢失以前看能不能找回发布信息,发现发布数据库执行如下报错
select * from sysarticlecolumns
Invalid object name ‘sysarticlecolumns’.
29、发布订阅需要新增一张表时，只需要右键发布名称选择articles项目在里面勾选需要新增的表即可，再右键发布名称–view snapshot agent status–start即可，在发布端的日志读取job(右键发布名称–view log reader agent status)正常运行的情况下，订阅job(右键订阅名称–view sysnchronization status)也正常运行的情况，订阅数据库上可以马上看到新增的表
30、SSMS图形界面，新建发布到第四步articles项目时或已经存在的发布右键选择articles项目时，界面很慢一直无法正常显示数据库对象比如表视图存储过程等，说明有堵塞，SSMS点开一些界面其实就是一个select的动作，找到堵塞源杀掉后，就可以正常显示了
31、实例–replication–Local Subscriptions–订阅名称–右键–View Synchronization Status报错：An error occurred connecting to server ‘XX’.SQL Server repliaction requires the actual server name to nake a connection to the server.
原因：可能修改了计算机名，SSMS连接的是新的计算机名，但是数据库没有修改Servername，导致这个报错，SSMS连接使用老的计算机名或修改数据库修改Servername为新的计算机名即可
32、A服务器ADB1库的数据做了replication到B服务器的ADB1数据库，A服务器和A1服务器搭建了AG，并把ADB1加入了AG，但是A1上的AG对应的数据库ADB1不正常，右键A服务器ADB1对应的发布名称–View Log Reader Agent Status发现ADB1的发布报错：Replicated transaction are waiting for next log backup or for mirror partner to catch up(复制的事务正等待下一次日志备份或等待镜像伙伴更新)
解决方法
方法1、确保A1的AG中ADB1正常(首选方法)
方法2、在A服务器上把该数据库ADB1从AG中移除
方法3、在A服务器上执行
DBCC TRACEON (1448, -1) --不希望replication受到alwayson 其他node的影响
原因：
我们知道always on的辅助副本secondary是获取了primary的日志信息而进行的redo动作实现了数据库的同步工作。当secondary异常宕机后，为了保证secondary起来时能够继续上次读取日志的地方做redo动作，db的transaction log就不会进行备份，而一直增大，最坏的情况导致磁盘爆满，无法使用。如当前01为primary，02为secondary，为了避免failover后，02切换为主副本，而此节点却没有获取到和01一样新的replication信息，导致异常。所以所有的always on node都要知道同步的情况，否则不继续进行同步。即所有node都获取replication信息后，才允许replication继续进行
33、SSMS对DB1创建发布时报错：this database is not enabled for publication不允许此数据库用于发布。 (Microsoft SQL Server，错误: 14013)
手工执行对DB1创建发布
USE master
EXEC sp_replicationdboption @dbname = ‘DB1’,@optname = ‘publish’,@value = ‘true’
GO
报错
链接服务器"repl_distributor"的 OLE DB 访问接口 “SQLNCLI” 返回了消息 “Login timeout expired”。
链接服务器"repl_distributor"的 OLE DB 访问接口 “SQLNCLI” 返回了消息 “An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.”。
该实例是Enterprise企业版，不是Express开发版，可以创建发布，所以不是版本问题
原因： 发现存在一个名为repl_distributor的linked server，且无法删除该linked server，查询该linked server发现它已经用于发布,即master.sys.servers.is_distributor=1
解决方法：

USE master;  
EXEC sp_serveroption 'repl_distributor', 'dist', 'false'; 

34、错误号：18483
could not connect to server “XX” because ‘distributor_admin’ is not defined as a remote login at the server
未能连接到’XX’服务器，因为distributor_admin未在该服务器上定义为远程登录
Could not connect to server ‘XX’ because ‘YY’ is not defined as a remote server.
未能连接到’XX’服务器，因为’YY’没有定义为远程服务器
原因：hostname和servername不一致导致，hostname是XX，但是servername是YY，这时候不能通过图形界面来完成创建分发服务器的操作
解决方法：使用图形界面向导，最后选择不配置分发，而是生成脚本，使用脚本的代码，修改脚本中代码，把XX修改为YY即可
35、replication到不同的schema，比如A库的dbo.table1可以复制到B库的repl.table1,不过无法使用图形界面来操作，需要使用脚本来操作，当然也可以使用图形界面来操作但是最后不点确定，而是从图形界面导出脚本，再修改脚本中的schema信息，如下案例把dbo这个schema的表base复制到repl这个schema下:

use [PatternRecDB]
exec sp_addarticle @publication = N'PatternRecDB_Base', @article = N'Base', @source_owner = N' dbo', @source_object = N'Base', @type = N'logbased', @description = N'', @creation_script = N'', @pre_creation_cmd = N'truncate', @schema_option = 0x000000000803509F, @identityrangemanagementoption = N'manual', @destination_table = N'Base', @destination_owner = N' repl', @status = 24, @vertical_partition = N'false', @ins_cmd = N'CALL [sp_MSins_dboBase]', @del_cmd = N'CALL [sp_MSdel_dboBase]', @upd_cmd = N'SCALL [sp_MSupd_dboBase]'
GO

36、修改数据库名报错can not rename the database name because it is published or it is a distribution database，解决方法:sp_removedbreplication @dbname=XXX
37、修改servername报错There are still remote logins or linked logins for the server ‘DBMASTER’
解决思路
37.1、查看哪些用户远程连接了DBMASTER服务器

sp_helpremotelogin 'DBMASTER'

server local_user_name remote_user_name options
DBMASTER distributor_admin distributor_admin
37.2、删除远程连接，继续出现的错误表示该服务器是订阅复制的发布服务器

exec sp_dropserver 'DBMASTER', @droplogins = 'droplogins'

继续报错Cannot drop server ‘DBMASTER’ because it is used as a Publisher in replication.
37.3、删除订阅复制的发布信息

sp_dropdistpublisher @publisher ='DBMASTER'

继续报错Cannot drop the local distribution Publisher because there are Subscribers defined.
37.4、删除订阅信息

sp_dropdistributor

继续报错Could not drop the Distributor ‘DBMASTER’. This Distributor has associated distribution databases.
37.5、最后删除订阅信息再重新把DBMASTER修改为DBMASTERNEW，成功

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor = 1
exec sp_dropserver 'DBMASTER', @droplogins = 'droplogins'
sp_addserver 'DBMASTERNEW','local'

38、当我们用SSMS配置分发服务器或用T-SQL执行sp_adddistributor时, 会自动创建一个名称为distributor_admin的登录名，这个登录名不要手工创建。当我们SSMS禁用分发服务器或T-SQL执行sp_dropdistributor会自动删除distributor_admin登录名
39、发布服务器上某个发布已经被删除了，但是发布服务器查询select * from [distribution].[dbo].MSrepl_errors order by 2 desc还是报错说发布找不到The publication ‘XXX’ does not exist.
故障原因：删除发布的时候，没有先删除发布下面的订阅，直接删除的发布，导致订阅服务器上订阅和订阅job都在，而订阅job跑一次，发现访问不到发布，所以分发数据库中表MSrepl_errors就记录访问不到发布的故障
解决方法：直接在订阅服务器上警用或删除订阅job就不会再有报警，当然更稳妥的方式是删除订阅，因为删除订阅的时候会自动删除订阅job
40、always on AG 中搭建replication的限制
40.1、不支持本地分发服务器。 例如，发布服务器和分发服务器必须为不同的 SQL Server 实例。 这些实例可以托管在同一组节点上。 使用自身作为分发服务器（也称为 本地分发服务器）的发布服务器无法支持 AG 中的分发数据库。
40.2、托管分发数据库副本的所有 SQL Server 2017 实例必须是 SQL Server 2017 CU 6 或更高版本。托管分发数据库副本的所有 SQL Server 2016 实例必须是 SQL Server 2016 SP2-CU3 或更高版本。
40.3、在 AG 中设置分发数据库需要是新的复制配置。 不支持将现有分发数据库切换到 AG。 同样，一旦将分发数据库从 AG 中移除，它就不能再作为有效的分发数据库运行，应该将其弃用。
41、同一个发布下面有两个订阅，通过distribution.dbo.sp_replmonitorsubscriptionpendingcmds查到一个订阅正常，一个订阅很慢总是延迟的很严重，如何定位这个慢的订阅
41.1、通过SSMS的图形界面Tracer Tokens跟踪令牌，插入跟踪器来记录信息，查看是发布端到分发端慢还是分发端到订阅端慢，不过这种同一个发布下一个订阅快一个订阅慢的情况，一般都是分发端到订阅端慢
41.2、可以从这个慢的订阅服务器本身的cpu、memory、disk等资源来定位，查看订阅服务器是否有资源瓶颈
41.3、查看这个分发服务器和慢的订阅服务器之间的网络传输是否有瓶颈
42、Replication的结构，wondadb3–>dbprod131a–>idbmmsql
wondadb3：发布端和分发端都是wondadb3，wondadb3是AG主节点，把wondadb3数据同步到了dbprod131a
dbprod131a：是wondadb3的订阅端,又是ibdmmsql的发布端,其中分发端是dbprod129，dbprod131a是AG主节点，dbprod129是单节点，把dbprod131a数据同步了ibdmmsql
idbmmsql:是dbprod131a的订阅端，ibdmmsql是单节点
dbprod129：是发布端dbprod131a–>订阅端idbmmsql，此两者的分发端
在dbprod131a中，添加发布使用图形界面还是下面的语句，都有报错

use [Wondb]
exec sp_addpublication @publication = N'Security', @description = N'Transactional publication of database ''Wondb'' from Publisher ''DBPROD82''.', @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, @ftp_login = N'anonymous', @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'false', @allow_sync_tran = N'false', @autogen_sync_procs = N'false', @allow_queued_tran = N'false', @allow_dts = N'false', @replicate_ddl = 1, @allow_initialize_from_backup = N'false', @enabled_for_p2p = N'false', @enabled_for_het_sub = N'false'
GO

报错：Cannot promote the transaction to a distributed transaction because there is an active save point in this transaction.
原因：是因为dbprod131a的参数 'remote proc trans’每10分钟就会变成1，这样的话我们就无法添加发布、修改发布、在发布下新增订阅、重启快照代理
解决方法:在dbprod131a上执行如下语句，当然执行后，只有10分钟的操作时间，因为10分钟后又会自动设置回去

EXEC sp_configure 'remote proc trans', 0
GO
RECONFIGURE
GO

43、一台服务器上有很多发布，就某一个发布对应的UndelivCmdsInDistDB出现很多没有推送到订阅端的命令，重新对这个发布订阅进行初始化后，发现这个发布对应的UndelivCmdsInDistDB依旧，检查了发布端的快照代理对应的job和日志读取器代理对应的job都正常运行，订阅类型是pull请求订阅，了解到分发代理对应的job是存放在订阅服务器，查到该job失败后一直没运行，重新运行该分发代理对应的job，这个发布对应的UndelivCmdsInDistDB很快变成了0

建立分发
复制-右键-配置分发
1、选择分发服务器
2、选择snapshot目录
3、创建分发数据库(数据库名称默认为distribution、数据库文件目录、数据库日志名称)
4、选择哪些发布服务器可以使用这个分发服务器，enable servers to use this distributor when they become publishers，其中distribution database没得选，就是分发的数据库，默认是distribution
–如果上面第四步勾选了publisher和distribution database，右键Replicattion有Publisher Properties、Distributor Properties、Disabled Publishing and Distribution Wizard。如果不勾选，右键Replicattion则没有Publisher Properties，有Distributor Properties、Disabled Publishing and Distribution Wizard

分发建立好后，有如下job
1、Agent history clean up: distribution
2、Distribution clean up: distribution
3、Expired subscription clean up
4、Monitor and sync replication agent jobs
5、Reinitialize subscriptions having data validation failures
6、Replication agents checkup
7、Replication monitoring refresher for distribution.

建立发布
复制-本地发布-右键-新建发布

建立发布1：还没有分发时，建立发布的同时建立分发（虽然没有了上面"建立分发"的第3、4步，但是也默认创建了数据库distribution）
右键local publications(本地发布)–选择new publication(新的发布)
1、选择分发服务器
2、选择snapshot目录
3、选择要发布的数据库
4、选择发布类型
5、选择要发布的对象，比如表、视图、存储过程
6、选择snapshot代理，snapshot是立即创建还是定期创建，snapshot代理的安全性是使用用户名密码还是使用sqlserver agent服务，snapshot代理怎么连接发布服务器，是OS域帐户还是DB帐户
7、创建发布名称

发布建立好后，有如下job
1、Agent history clean up: distribution
2、Distribution clean up: distribution
3、Expired subscription clean up
4、Monitor and sync replication agent jobs
5、Reinitialize subscriptions having data validation failures
6、Replication agents checkup
7、Replication monitoring refresher for distribution.
8、WONCNTESTDB1-replicate1-1
9、WONCNTESTDB1-replicate1-pub_replicate1-1

建立发布2：已经建立了分发时，只建立发布
1、选择要发布的数据库
2、选择发布类型
3、选择要发布的对象，比如表、视图、存储过程
4、选择snapshot代理，snapshot是立即创建还是定期创建，snapshot代理的安全性是使用用户名密码还是使用sqlserver agent服务，snapshot代理怎么连接发布服务器，是OS域帐户还是DB帐户
5、创建发布名称

发布建立好后，有如下job
1、WONCNTESTDB1-replicate1-1
2、WONCNTESTDB1-replicate1-pub_replicate1-1

建立订阅
1、选择发布服务器，选择发布
2、选择推送订阅还是请求订阅
3、选择订阅服务器，选择订阅数据库
4、选择订阅代理服务器，分发代理使用怎么连接,是OS域帐户还是DB帐户,分发服务器使用怎么连接,是OS域帐户还是DB帐户，订阅服务器使用怎么连接,是OS域帐户还是DB帐户
5、订阅同步是持续性还是按需求
6、是否马上初始化订阅对象

订阅建立好后，有如下job，此job名称的前半段和订阅名称一样即WONCNTESTDB1-replicate1-pub_replicate1
WONCNTESTDB1-replicate1-pub_replicate1-WONCNTESTDB2-replicate_01-CD7A365E-2DE7-47A3-B31E-70F785FA71F2