sql-server – 何时可以缩小数据库？

我知道缩小是魔鬼：它颠倒了页面顺序,并导致皮肤癌,数据碎片和全球变暖.列表继续……话虽如此,说我有一个100 GB的数据库,我删除50 GB的数据 – 不是在一张桌子上,而是在数据库范围内对旧数据进行一般修剪,覆盖90％的数据表 – 这是否构成缩小数据库的适当用例？

如果没有,从数据库中删除如此高比例的数据后,采取什么样的措施来清理房屋？我可以想到两个：重建索引和更新统计.还有什么？

解决方法

如果您可以使数据库脱机服务的应用程序,您可以通过在收缩之前删除所有索引和主/外键约束来加快进程并减少索引碎片(这意味着只有少量数据可以移动数据页面将被洗牌而不是现在不存在的索引页面,从而加快了进程)然后重新创建所有索引和键.

在缩小之后重新创建索引意味着它们不应该显着碎片化,并且在缩小期间使它们消失意味着重建它们不会在文件中的页面分配中留下许多小的“漏洞”,这可能会在以后引起碎片.

如果可以使应用程序脱机,另一个选项是将所有数据迁移到具有相同结构的新数据库.如果您的构建过程是可靠的,您应该能够快速构建该空白数据库,如果没有从当前数据库创建一个空白数据库(恢复当前数据库的备份,截断/删除表中的所有内容并执行完全收缩).

您可能仍希望删除目标中的所有索引并在之后重新创建它们,因为在更改大量索引数据(在这种情况下为100％)时,这可以更有效.要加快复制过程,请将目标数据库的数据文件放在与源不同的物理驱动器上(除非您使用的是SSD,在这种情况下您不需要关心减少磁头移动),您可以移动它们完成后到源位置.

此外,如果将目标创建为新的(而不是通过消隐源的副本)创建它的初始大小将包含所有当前数据加上几个月的增长 – 这将使数据复制再次更快在整个过程中,它不会一次又一次地分配新的空间.

这可能比使用shrink更好,因为将数据迁移到新数据库会复制收缩操作的预期操作,但可能会有更少的碎片(这是重组和收缩的意外后果).收缩只是从文件末尾附近获取块,并将它们放在靠近开头的第一个空间中,而不用将相关数据保存在一起.

我怀疑结果在空间方面也会更有效,因为事后可能会有更少的部分用过的页面.缩小只会移动部分使用的页面,移动数据更有可能导致整页,特别是如果按照表的聚簇键/索引(表中有一个)的顺序插入目标并创建其他索引数据全部迁移后.

当然,如果您根本无法使应用程序脱机,只需执行缩小即可,因此如果您确实需要回收空间,请执行此操作.根据您的数据,访问模式,常用工作集大小,服务器具有多少RAM等等,额外的内部碎片最终可能并不那么重要.

对于复制操作,SSIS或基本T-SQL也可以正常工作(SSIS选项可能效率较低,但以后可能更容易维护).如果您在结尾处创建FK关系以及索引,则可以在任何一种情况下为每个表执行简单的“复制”.当然,对于一次性,缩小重组可能也很好但我只是想吓唬人们从不考虑经常收缩！ (我知道人们每天安排他们).

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!