客户的一套系统从凌晨开始出现运行缓慢，重启SQLServer服务后一个主要的数据库一直处在正在恢复的状态，多次重启SQLServer服务和服务器无果后请我们协助处理。启动SQLServer服务时数据库恢复要经过分析、重做和撤销3个阶段，在阶段2完成后数据库才能提供访问。通过日志记录看到阶段3的时间非常长，说明在停止SQLServer服务时有特别大的事务在运行。大的INSERT事务执行期间造成了大量的阻塞，影响了系统的其它功能，客户接到故障报警后没有仔细分析原因就直接重启了SQLServer服务。另外，从SQLServer2016开始，增加了数据库恢复进度的扩展事件，可以分析的更详细。大事务导致的回滚时间长或者异常终止后重启SQLServer服务时数据库恢复时间长是一个非常困扰的问题。在SQLServer2019新推出的“加速数据库恢复”功能就是解决这个痛点的，但是不成熟，开启这个功能又导致了数据文件增长过大等其它的问题，在SQLServer2022版本中进行了改进。微软数据平台合作伙伴，卫宁健康数据平台战略合作伙伴。

刚好看到这个参数{relaylogrecovery}测试一下

很多人认为AlwaysOn在同步提交模式下数据是实时同步的，也就是说在主副本写入数据后可以在辅助副本立即查询到。因此期望实现一个彻底的读写分离策略，即所有的写语句在主副本上，所有的只读语句分离到辅助副本上。这是一个认知误区，本文通过原理和测试进行解释。从下图可以看到，在同步提交模式下，主副本产生的日志被同步并固化到辅助副本的日志文件后，主副本的事务就会提交。要强调的是，这种实现原理是为了对主副本上的写入操作的性能影响最小化，并不会导致数据丢失。因此不会丢失数据，只是稍微增加了一点故障转移的时间。创建一个AlwaysOn可用性组，2个同步提交的副本，Node1为主副本，Node2为辅助副本。北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业，成立于2008年，创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴。