情况：
我们在笔记本电脑上使用本地SQL Server实例，并使用Red-Gate的SQL源代码控制将这些实例绑定到我们的SVN存储库。最初，当我被发行时，执行“获取最新”和“提交”同步的笔记本电脑相对较快（对于1/4到4/4，<2分钟）。几周之后，很明显这个过程已经显着放缓，现在这个过程大约需要20分钟进行一次同步。
此时我已经开始尝试针对此问题的每个基本故障排除策略，SQL Source Control执行从卸载到重新安装的所有操作;将版本升级到最新版本甚至降级到各种旧版本。我使用本地存储库测试SSC以排除网络，并使用“工作文件夹”，甚至使用“正在评估”的lite存储库。他们都很慢;与其他每个选项一样慢，至少需要20分钟才能执行单个同步。
如果没有解决问题，我通过我们的支持合同联系了Red Gate。长话短说，这无处不快。经过几个月的不同情景，我们似乎没有更接近决议。
最终我发现，如果没有链接到存储库的静态数据，我可以更快地（大约5分钟）同步数据库。但问题是数据必须链接（SSIS配置数据或RI静态数据），所以这不是一个可行的选择，但它确实有助于更准确地指出真正的问题。
现在，对于单个同步，同步的时间大约为2小时。还有其他几个开发人员也在处理这个问题，其中一个必须等待长达6个小时才能完成最新版本。
其他信息：
•此笔记本电脑上没有其他应用程序运行缓慢
•驱动器是加密的SSD，已配置为使用1GB的RAM进行缓存
•我们已经对禁用的防病毒/防御软件进行了测试，但没有任何区别
这可能是什么原因？
答案 0 :(得分：5)
问题主要在于Red-Gate的SQL Compare \ Data Compare。
症状：SQL源代码控制调用SC＆amp; 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/
上关于此主题的博客文章