我知道缩小数据库是有风险的.在这种情况下,我删除了这么多数据,我再也不会使用它了.
>我如何缩小数据库？我缩小了哪些文件？
>这样做时我应该考虑什么？
>之后我该怎么办？
>如果它是一个大型数据库怎么办？我可以以较小的增量缩小它吗？
解决方法
>通常称为缩小生产数据库或数据文件的最差做法(日志文件是另一个问题,如this question所述).我建议人们不要在blog posts like this缩小他们的数据库,在那里我谈论“正确的规模”和良好的规划.我并不孤单(Paul Randal,Brent Ozar,只是为了提供更多链接).缩小数据文件或数据库碎片索引,对您的资源来说既缓慢又费力,可能会耗尽您的系统并且只是一件坏事,通常
>在这种情况下,我们都知道存在风险,我们已准备好应对它,但我们释放了许多空间,我们知道我们永远不会再需要它.所以在这种特殊类型的情况下 – 收缩作为我们的选择之一很有意义.
如果您已经阅读了关注和风险,并且您仍然需要这样做,因为您释放了大量空间,希望这个答案的其余部分可以帮助您.但要考虑风险.
这里有两种主要方法：
1.)收缩是的,实际收缩 – 考虑使用DBCC SHRINKFILE而不是DBCC SHRINKDATABASE,您可以更好地控制缩小的内容和方式.这肯定会导致性能下降 – 这是一项执行大量IO操作的大型操作.您可以通过重复缩小到目标尺寸逐渐变小来逃避.
这是上面DBCC SHRINKFILE链接中的“A.)”示例.在此示例中,数据文件正在缩小到7MB目标大小.这种格式是一种在停机时间允许的情况下反复缩小的好方法.我会在开发测试中执行此操作,以了解性能的外观以及增量的低/高程度以及确定生产中的预期时间.这是一个在线操作 – 您可以在访问数据库的系统中的用户运行它,但是几乎可以保证性能下降.因此,理想情况下,监控并观察并查看您对服务器的操作,选择停机时间窗口或较轻的活动时段.
USE YourDatabase; GO DBCC SHRINKFILE (DataFile1,7); GO
永远记住： – 每次缩小时,您都会对索引进行分段,并且如果要在较长时间内缩小块,则应该进行索引重建.如果您无法在一个窗口中完成所有操作,那么您现在每次都要承担这笔费用.
2.)新数据库 – 您可以创建新数据库并将数据迁移到该数据库.您必须将空数据库及其所有密钥,索引,对象,过程,函数等编写脚本,然后将数据迁移到该数据库.您可以为此编写脚本,也可以使用Red Gate或其他具有类似工具的供应商的sql Data Compare等工具.这是更多的设置工作,更多的开发和测试,并且根据您的环境也可能会破坏您的停机时间窗口,但可以考虑.
当我被迫缩小数据库时如果这是我的环境,我会在数据文件中留下相当大量的空白区域,因为我喜欢成为一个磁盘猪,并希望为未来/意外增长做好准备.如果我们只是删除大部分空间,我会好好给予空间,但我永远不会相信那些说“但它永远不会再增长”但仍留有一些空白的人.如果我有更小的停机时间窗口并且不想产生创建空DB并将数据迁移到它的复杂性,那么我可能会选择(叹气)的路线就是收缩方法.所以我会逐渐缩小它(根据我认为需要多少次基于我在开发中的测试和所需的大小.逐步选择较小的文件大小)然后重建索引..然后我’我永远不会告诉任何人我缩减了我的数据库;-)
