6
SQL数据库物理文件碎片
我知道有真正的三个种类的碎片，我需要被关心的DBA： SQL数据文件中的索引碎片，包括聚集的索引（表）碎片。使用DBCC SHOWCONTIG（在SQL 2000中）或sys.dm_ db_ index_ physical_ stats（在2005+中）进行识别。 SQL日志文件中的VLF碎片。运行DBCC LOGINFO以查看每个SQL日志文件中有多少个VLF。 硬盘驱动器上数据库文件的物理文件碎片。通过使用Windows中的“磁盘碎片整理程序”实用程序进行诊断。（受到这篇出色的博客文章的启发） 索引碎片引起了很多关注（请参阅Paul Randall的Serverfault出色回答），因此这不是我的问题的重点。 我知道当最初通过计划合理的预期数据文件和日志大小来创建数据库时，可以防止物理碎片（和VLF碎片），因为这种碎片通常发生在频繁的增长和收缩中，但是我有一些有关如何解决的问题物理碎片一旦被识别： 首先，物理碎片是否在企业级SAN上也相关？是否可以在SAN驱动器上使用Windows Defragmenter，或者SAN团队应使用内部碎片整理实用程序？在SAN驱动器上运行时，我从Windows工具获得的碎片分析结果是否准确？ 物理碎片对SQL性能的影响有多大？（让我们假设一个内部驱动器阵列，等待上一个问题的结果。）这比内部索引碎片还大吗？还是真的是同一类型的问题（驱动器必须执行随机读取而不是顺序读取） 如果驱动器物理碎片化，则对碎片整理（或重建）索引是否浪费时间？我需要先解决一个问题吗？ 在生产SQL框中修复物理文件碎片的最佳方法是什么？我知道我可以关闭SQL服务并运行Windows Defrag，但是我也听说过一种技术，您可以进行完全备份，删除数据库，然后从备份还原到空驱动器。是否推荐使用后一种技术？从这样的备份还原是否还会从头开始建立索引，从而消除内部索引碎片？还是只是简单地将页面顺序恢复为执行备份时的页面顺序？（如果需要的话，我们正在使用具有压缩功能的Quest Lightspeed备份。） 更新：关于是否对SAN驱动器进行碎片整理（否），以及在物理碎片驱动器上是否仍然值得进行索引碎片整理（是），到目前为止，已经有了很好的答案。 还有其他人愿意权衡实际进行碎片整理的最佳方法吗？还是对碎片整理大型碎片驱动器（例如500GB左右）所需的时间估计？显然相关，因为那是我的SQL Server停机的时候！ 另外，如果任何人都拥有通过修复物理碎片而获得的有关SQL性能改进的轶事，那也很好。Mike的博客文章讨论了发现问题的方法，但并没有具体说明它做了什么样的改进。