原文:Replication的犄角旮旯（一）--变更订阅端表名的应用场景
《Replication的犄角旮旯》系列导读
Replication的犄角旮旯（一）--变更订阅端表名的应用场景
Replication的犄角旮旯（二）--寻找订阅端丢失的记录
Replication的犄角旮旯（三）--聊聊@bitmap
Replication的犄角旮旯（四）--关于事务复制的监控
Replication的犄角旮旯（五）--关于复制identity列
Replication的犄角旮旯（六）-- 一个DDL引发的血案(上)（如何近似估算DDL操作进度）
Replication的犄角旮旯（七）-- 一个DDL引发的血案(下)（聊聊logreader的延迟）
Replication的犄角旮旯（八）-- 订阅与发布异构的问题
Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，赋予订阅活力的工具
---------------------------------------华丽丽的分割线--------------------------------------------
接触Replication只有1年多的时间；曾追随JD首席DBR（DB for Replication）陈璟同鞋学习复制，受益匪浅；
关于SQLServer Replication的文章看过不少，大多以原理介绍、如何搭建复制居多。本文旨在从生产环境出发，挖掘Replication中各种犄角旮旯的功能，使其成为运维环节中便于使用的工具；
如无特殊说明，本系列均是基于transaction replication场景；
变更订阅端表名的应用场景
本文以之前我在SQL PASS活动上分享的“翻滚吧 Replication”为背景，相关PPT及demo如下：
http://yun.baidu.com/share/link?shareid=2808657365&uk=120218674
场景描述：一般通过快照或备份初始化，订阅端表名与发布端一致；而我们要研究的是订阅端表名与发布端不一致时的应用场景（发布端 table、订阅端table_new）
用途：适用于在不影响当前复制链路的情况下，实现对同一订阅存在多个副本，以至于延伸到可以满足数据移动、表结构变更等用途；
案例：对于一个较大的且数据表，如果业务方提出要升级表结构（如int类型改为bigint），如何尽量减少停机操作时间？如果这个表参与复制呢？如果被修改的column是主键呢？
操作：
1、按照一般方法创建好一个publication，并添加需要发布的article；
2、编辑项目属性，参照下图，编辑“目标对象名称”、“名称已被使用时的操作”及“语句传递”
注：
a)对于修改表结构（int类型改为bigint类型）的需求，可以先在订阅端创建新结构的新表（如table_new），在通过指定“名称已被使用时的操作”为“现有对象保持不变”，让订阅在应用快照时只写入数据而忽略表结构上不一致；
b)事务复制是通过调用订阅端对应的ins、del、upd存储过程实现复制命令在订阅端的执行，为了不影响原有复制链路，需要自定义新的订阅端存储过程名
3、添加订阅并通过快照初始化，即可生成“更名的订阅”；
4、参照原订阅端旧表，添加对新表的相关权限、索引等；
5、在停机维护窗口，停止发布端的写操作；
6、待复制命令完全应用到订阅端后，拆除全部复制关系，交换订阅端table和table_new的表名，参照旧的复制关系重新添加不初始化的订阅，即可实现订阅端表结构的变更；
至此，我们实现了大数据表升级表结构的业务需求，较之直接在数据表上进行alter table，时间大大缩短，且尽可能的避免长时间架构锁给业务带来的影响；
对于无复制关系的单表而言，同样可以参照此方法创建“更名的订阅”实现表结构的升级，但需要注意的是SQLServer Replication的限制：
1、同一个数据库不能既是发布又是订阅（自己复制到自己是不允许的）；
2、如果增加一个实例，实现A--B--A的链式复制，
你会发现，即使复制链路可以搭建成功，但B--A，是不会应用复制命令的（貌似Replication将此类复制认为是形成了复制环，也是不被允许的）
针对上述限制，就产生了我提出的另一个概念--复制回路；
其实就是欺骗了一下Replication，既然2个实例被认为是复制环，那就再加1个实例：A--B--C--A，这样就实现了复制回路，相当于将A上的table重新复制回A上，并更名为table_new；
关于复制回路2实例和3实例的测试，可以看一下我云盘中“复制回路Demo.flv”的演示；
http://yun.baidu.com/share/link?shareid=2819400848&uk=120218674