SQL源代码控制需要数小时才能同步

Question

情况:

我们在笔记本电脑上使用本地SQL Server实例,并使用Red-Gate的SQL源代码控制将这些实例绑定到我们的SVN存储库.最初,当我被发布时,这台笔记本电脑执行"获取最新"和"提交"同步的速度相对较快(1/4到4/4时间为2分钟).几个星期之后,很明显这个过程已经显着减慢,现在这个过程大约需要20分钟进行一次同步.

此时我已经开始尝试针对此问题的每个基本故障排除策略,使用SQL Source Control执行从卸载到重新安装的所有操作; 将版本升级到最新版本甚至降级到各种旧版本.我使用本地存储库测试SSC以排除网络,并使用"工作文件夹",甚至使用"正在评估"的lite存储库.他们都很慢; 与每个其他选项一样慢,至少需要20分钟才能执行单个同步.

如果没有纠正这个问题,我通过我们的支持合同联系了红门.长话短说,这无处可去.经过几个月的不同情景,我们似乎没有更接近解决方案.

最终我发现,如果没有链接到存储库的静态数据,我可以更快地(大约5分钟)同步数据库.但问题是数据必须链接(SSIS配置数据或RI静态数据),所以这不是一个可行的选择,但它确实有助于更准确地指出真正的问题.

现在,对于单个同步,同步的时间已达到约2小时.还有其他几个开发人员也在处理这个问题,其中一个必须等​​待长达6个小时才能完成最新版本.

其他信息:

•此笔记本电脑上没有其他应用程序运行缓慢

•驱动器是加密的SSD,已配置为使用1GB的RAM进行缓存

•我们已经对禁用的防病毒/防御软件进行了测试,但没有任何区别

这可能是什么原因？

Answer 1

问题主要在于Red-Gate的SQL Compare\Data Compare.

症状:SQL Source Control在将数据同步到存储库时调用SC和SDC,这是一个需要很长时间才能完成的过程.

根本原因:在比较瞬态和工作基础文件夹期间,SC和SDC在"%USERPROFILE%\ AppData\Local\Temp\Red Gate"文件夹中创建了一个过多的(每秒几千个)临时文件,无论出于何种原因这些应用程序并不总是删除旧文件.随着时间的推移,孤立文件的数量会累积,结果是一个碎片文件夹,访问速度很慢.在这个问题上与Red Gate合作数月后,他们终于能够在他们的实验室中重现这个问题,并且已经被正式接受为SC-7647下的一个错误.

在我的情况下,我在这个临时文件夹中发现了超过100,000个文件.清除文件后,即使使用静态数据,同步到SVN所需的时间也会缩短到大约2分钟.

在Red-Gate发布针对此问题的修复程序之前,解决方法是使用进程(计划任务或其他)来清除早于一段时间的文件.原因是我设法通过杀死临时文件夹中的一些当前文件来搞乱链接数据库,因此不建议任意删除.

以下命令行语句将尝试删除超过1天的所有文件.

forfiles -p “C:\Users\<your username>\AppData\Local\Temp\Red Gate” /s /m *.* /d -1 /c “cmd /c del @path”

有关更多信息,请访问http://artofsql.net/guides/improving-sql-source-control-and-sql-data-compare-performance/,查看我关于此主题的博客文章.