> sql数据文件中的索引碎片,包括聚簇索引(表)碎片.使用DBCC SHOWCONTIG(在sql 2000中)或sys.dm_ db_ index_ physical_ stats(在2005中)来识别它.
> VLF Fragmentation里面的sql日志文件.运行DBCC LOGINFO以查看每个sql日志文件中有多少个VLF.
>硬盘驱动器上数据库文件的物理文件碎片.使用Windows中的“磁盘碎片整理程序”实用程序进行诊断. (灵感来自this excellent blog post)

索引碎片受到了很多关注(见Paul Randall的this excellent Serverfault answer),所以这不是我的问题的焦点.

我知道在最初通过规划合理的预期数据文件和日志大小来创建数据库时,我可以防止物理碎片(和VLF碎片),因为这种碎片最常发生在频繁增长和缩小的情况下,但我对如何修复有一些疑问物理碎片一旦被识别：

>首先,物理碎片甚至与企业SAN相关吗？我可以/应该在SAN驱动器上使用Windows碎片整理程序,还是SAN团队应该使用内部碎片整理实用程序？在SAN驱动器上运行时,我从Windows工具获得的碎片分析是否准确？
> sql性能的物理碎片有多大？ (让我们假设一个内部驱动器阵列,等待先前问题的结果.)这是一个比内部索引碎片更大的交易吗？或者它真的是同一类问题(驱动器必须进行随机读取而不是顺序读取)
>如果驱动器在物理上碎片化,那么碎片整理(或重建)索引会浪费时间吗？在我解决另一个问题之前,我是否需要修复一个？
>在生产sql框上修复物理文件碎片的最佳方法是什么？我知道我可以关闭sql服务并运行Windows碎片整理程序,但我也听说过一种技术,您可以执行完整备份,删除数据库,然后从备份还原到空驱动器.是推荐后一种技术吗？从这样的备份恢复是否也从头开始构建索引,消除内部索引碎片？或者它只是将页面顺序返回到与备份时相同的页面顺序？ (如果重要的话,我们正在使用带压缩的Quest Lightspeed备份.)

更新：到目前为止,关于是否对SAN驱动器进行碎片整理(NO)以及是否在物理碎片驱动器上进行索引碎片整理仍然是一个很好的答案(是).

其他人都在关注实际进行碎片整理的最佳方法吗？
或者估计你需要对一个大型碎片驱动器进行碎片整理所需的时间长度,比如500GB左右？显然是相关的,因为那是我的sql服务器崩溃的时候！

此外,如果任何人有关于通过修复物理碎片所做的sql性能改进的任何轶事信息,那也会很棒. Mike’s blog post讨论了发现问题的方法,但并未具体说明它所取得的改进.