Replication--查看未分发命令和预估所需时间
摘要：当复制有延迟时，我们可以使用复制监视器来查看各订阅的未分发命令书和预估所需时间，如下图：但是当分发和订阅数比较多的时候，依次查看比较费时，我们可以使用sys.sp_replmonitorsubscriptionpendingcmds来查看，但是该命令需要输入多个参数，也比较累人，后从菠萝兄哪找寻得一...
阅读全文
posted @ 2014-06-18 21:58
随笔分类 - SQL Server--Replication
Replication--复制事务和复制命令
摘要：--===============================================对复制一直属于一知半解浑浑噩噩的状态，仅知道一些皮毛，对很多细节没有深入学习过，如果不对之处，请各位大神批评指正。*以下讨论的基于事务复制，不考虑同步存储过程的情况--===============================================当发布数据库上发生数据修改（增删改）时，会将相关操作写入日志，以保证数据一致性，而对发布表上聚集索引的修改的日志会被标记为‘REPLICATE’。（PS:从上图中不难看出，在checkpoint时会记录复制相关的信息）标记为‘REPLICA
阅读全文
posted @ 2014-03-20 15:06
Replication--复制延迟的诊断和解决
摘要：要解决复制延迟问题，需要首先定位复制延迟发生点，再找出复制延迟的原因，再做相应处理。 复制延迟发生点：1. 发布服务器2. 分发服务器3. 订阅服务器4. 发布服务器与分发服务器和分发服务器与订阅服务器之间的网络 延迟测试方式：1. 使用复制token参考：http://www.cnblogs.co
阅读全文
posted @ 2014-03-19 14:21
Replication--对发布修改的一些小总结
摘要：--====================================================--在华丽分割线下，是我对肖磊--大菠萝的崇高地敬意和婶婶地感谢，本文乃肖兄表述我执笔而来--====================================================1.增加(删除)发布表的字段对发布表添加和删除字段后，无需设置，MS SQL SERVER 会自动将该操作同步到订阅上。ps：要修改已发布的表，必须将复制架构修改设置为true(默认为true)2. 移除发布article对于SQL SERVER 2008R2(包含)以下版本，必须先停止对该发
阅读全文
posted @ 2014-03-17 13:17
Replication--复制与CDC和镜像
摘要：复制和CDC 都是使用logreader来从日志中读取数据的变更，然后写入到分发库(复制)或变更表中。1> 单独创建复制发布在该情况下，会在分发服务器上创建日志读取代理作业(ServerName_DBName_logreaderID)2> 单独使用CDC在该情况下，会在当前实例的代理上创建两个作业‘cdc.DBName_capture’(调用sys.sp_MScdc_capture_job来读取日志)和‘cdc.DemoDB3_cleanup’（调用sys.sp_MScdc_cleanup_job来清理过期的变更历史记录）3>先创建复制发布，再使用CDC创建复制时在分发服务器
阅读全文
posted @ 2014-02-10 22:35
Replication--复制相关的作业
摘要：复制使用下列作业来执行计划维护和按需维护作业名称 说明 默认调度 代理历史记录清除：分发从分发数据库中删除复制代理历史记录。 每十分钟运行一次 分发清除：分发 从分发数据库中删除复制的事务。停用在最大分发保持期内尚未同步的订阅。每十分钟运行一次 过期订阅清除 从发布数据库检测和删除过期的订阅。 每天凌晨 1:00 运行 重新初始化数据验证失败的订阅 检测所有未通过数据验证的订阅并标记它们以进行重新初始化。下次合并代理或分发代理运行时，订阅服务器上将应用新快照。无默认调度（默认情况下未启用）。 复制代理检查 检测未积极记录历史信息的复制代理。 如果作业步骤失败，它将写入 Microsoft Wi
阅读全文
posted @ 2014-02-07 23:04
Replication--如何使用快照来初始化化请求订阅
摘要：1>使用"默认位置"来初始化，简单易用，无须额外配置，但是适用场景有限。
2>使用"备用文件夹"来初始化，略微复杂，但可操作行强，可以使用多种方式将快照复制到订阅服务器，缺点是以后每次初始化都需要拷贝。
3>使用"FTP 文件夹"来初始化,相对复杂，如果FTP 用户的根目录配置不当，就会失败，优点是配置成功后，以后每次重新无须再做修改。
4>由于快照使用BCP文件来存放某一点的数据，因此数据较大时，快照文件会特别大，使用FTP方式不能压缩快照文件，因此会耗时较长，推荐将快照压缩后传递到订阅服务器，再使用"备用文件夹"来初始化。
阅读全文
posted @ 2014-01-22 20:38
Replication--备份初始化需要还原备份么？
摘要：测试场景：发布服务器：SQLVM6\SQL2订阅服务器：SQLVM5\SQL2分发服务器：SQLVM3\SQL2发布数据库：RepDB2订阅数据库：RepDB2发布：RepDB2_TB1测试步骤：1>停止发布库上的日志备份2>备份发布服务器上数据库"RepDB2" 至"E:\REPDB2.BAK"3>将备份复制到订阅服务器，还原出数据库RepDB2_Temp4>在订阅服务器上将 RepDB2_Temp 订阅相关的数据导入到 RepDB2（INSERT SELECT）5>将发布RepDB2_TB1的属性"允许从备份文
阅读全文
posted @ 2014-01-22 10:56
Replication--数据库镜像阻塞复制日志读取器的解决的办法
摘要：问题描述：
在同一数据库上使用镜像和复制，为保证镜像切换后，复制还能继续，因此当镜像断开或暂停时，复制日志读取器会被阻塞直到日志被同步到镜像从服务器端(无论异步还是同步)。
日志状态显示：复制的事务正等待下一次日志备份或等待镜像伙伴更新
解决办法：打开Trace flag 1448，在高性能和高安全下同样有效
DBCC TRACEON(1448，-1)
1448 甚至在异步辅助数据库不确认接受更改的情况下，也使复制日志读取器前移。 甚至在此跟踪标志启用的情况下，日志读取器也始终等待同步辅助数据库。 日志读取器将不会超过同步辅助数据库的最小确认。 此跟踪标志应用于SQL Server 的实例，而不仅是可用性组、可用性数据库或日志读取器实例。 应用会立即生效，无需重新启动。 此跟踪标志可提前激活或在同步辅助数据库失败时激活。
阅读全文
posted @ 2014-01-15 17:44
Replication--复制笔记1
摘要：1.快照复制和事务复制使用分发代理传递文件，而合并复制使用合并代理来传递文件
2.快照代理在分发服务器上运行
3.在创建快照是，根据复制的类型对发布表的加锁方式而不同
a)对应合并发布，快照代理不适用热河锁
b)对应事务发布，默认情况下快照代理只在快照生成的初始阶段使用锁
c)对应快照腹部，整个快照生成过程中使用锁
4. 快照复制发布表中数据，生成BCP文件，存放到快照文件夹中。
5. 快照读取发布表的架构，生成sch文件，其他数据库对象如索引+约束+存储过程+视图+udf等生成脚本文件
6. 日志读取器代理使用内部存储过程sp_replcmds从日志中获取标记为要复制的下一个命令集
7. 自增键在订阅端始终保持自增值(IDENT_CURRENT)不变，当订阅端被切换成读写后，需要手动执行DBCC CHECKIDENT ( table_name)
阅读全文
posted @ 2014-01-15 17:36
Replication--将LSN转换成16进制
摘要：在复制中经常会使用到16进制的LSN,但在日志fn_dblog中的LSN是数字形式，于是从网上找到以下转换函数
CREATE FUNCTION dbo.fn_convertnumericlsntobinary
阅读全文
posted @ 2014-01-15 17:30
Replication--使用备份初始化订阅--推送订阅
摘要：使用备份初始化订阅--推送订阅
阅读全文
posted @ 2014-01-15 17:25
Replication--使用备份初始化订阅--请求订阅
摘要：使用备份初始化订阅--请求订阅
阅读全文
posted @ 2014-01-15 17:23
Replication--发布属性immediate_sync
摘要：发布属性immediate_sync相关基础
阅读全文
posted @ 2014-01-15 17:20
Replication--Alwayson+复制发布
摘要：Alwayson+复制发布
阅读全文
posted @ 2014-01-15 17:17
Replication--修改复制代理配置来查看代理运行情况
摘要：正常情况下，复制代理运行不会记录详细信息，需要手动修改。
阅读全文
posted @ 2014-01-15 17:12
