Mol*_*pad 4 sql-server shrink sql-server-2012
我有一个包含 850GB MDF 文件的数据库。在 20 个月的过程中，应用程序中的日志记录机制创建了各种巨大的表。原本只应该在任何时候保留一周数据的维护脚本没有正确执行（现在是），所以我们不得不手动清理。
我们实际上清除了大约 600GB 的数据。我想释放一些空间，因为它所在的驱动器接近极限。数据文件永远不会再变得这么大，所以它只是浪费了空间。
我打算使用 SHRINK-FILE 来处理这个问题。我已经对数据库的克隆进行了测试，大约需要 3 个小时。数据库上似乎没有任何性能下降。是的，之后索引非常碎片化，但我可以对它们进行排序。
我的问题是这样的：
应用程序需要在整个过程中保持“正常运行”，因为它至关重要。我知道 SHRINKFILE 操作是一个完全在线的操作，还是我错了？
数据库几乎每秒都会发生大量写入活动。
SHRINKFILE 操作导致的 I/O 增加会影响这些写入吗？
反过来说，连续写入是否会影响 SHRINKFILE 操作，即使其完成更慢？
最后，有没有更好的方法来做到这一点？
更新
仅供阅读本文的任何人使用 - 我运行 SHRINKFILE 并监控 I/O 和 CPU。我的高每秒写入数的数据库在这两个方面都略有上升，但完全没有延迟问题。在 1.5 小时的 SHRINK 操作过程中，它一直保持正常运行、稳定且无故障。
之后索引非常碎片化，这让应用程序的报告端有点难过（图形在客户端应用程序上呈现速度很慢），但稍后重建在线索引，一切都恢复正常。
我们无法知道它是否会影响应用程序，您也很难确定。即使使用 100% 同类系统和分布式重放客户端，您也不会注意到磁盘 IO 的毫秒影响，并且您无法判断应用程序本身对此很敏感。
唯一可以确定的是，如果供应商自己为您提供一种解决方案来证明它的一种或另一种方式（即应用程序本身可以进行自己的负载测试），恕我直言，很少有供应商有这样的东西。
现在到其余部分。
数据文件上的收缩文件正在执行大量 IO，这可能会影响对延迟非常敏感的应用程序 - 但我从未见过它。如果您的备份没有杀死您，那么这也不太可能杀死您。你必须已经生活在公差的边缘。
作为一名 DBA，您应该始终通过让人们知道正在发生的事情来掩饰自己（通过更改票正式或通过其他方式非正式地）。让他们知道没有已知或预期的影响，但您可以在万一发生任何事情的情况下立即阻止它。如果您取消收缩文件，它会立即停止。
但除此之外，对我来说，这是一种照常营业的变化，没有任何影响。我不是金融或医疗保健，所以你的标准可能更高。
不过，您需要了解以下内容：
您将生成大量日志记录。这意味着您最好处于简单模式，或非常频繁（每隔几分钟）日志备份的完整模式，以确保您不会开始填满您的磁盘。
如果您处于完整模式，您将拥有大量 DIFF 备份（如果您这样做），直到下一次完整备份。
在周末，或者每当您的索引维护时段到来时，您都会遇到大量日志备份和 DIFF 备份的相同情况。如果您的维护是重建而不仅仅是重组，这可能是一个问题；重建可能会将您置于维护窗口之外，在运行时会占用大量日志或临时数据库空间，并且会爆炸到数百 GB。如果他们只是在进行重组（即没有中断），那么您只会看到大日志和 DIFF 备份。
现在所有这些后面的事情肯定会导致中断。但是，如果您有足够的备份空间和磁盘空间来存储数据和日志文件，并且每隔几分钟进行一次日志备份，并且只进行重组，并且设置了合理的非基于百分比的小型日志增长大小，那么您就是不太可能遇到任何麻烦。