Question

运行重建脚本后，我仍然有相当一部分零散的索引。很难找到关于此的任何信息。

我做了很多测试，我认为我有两个问题。重建在DDL / DML操作中大量使用的表上效果不佳。在断开连接的数据库上，它的工作效率提高了90％。可以在没有服务窗口的情况下解决该问题吗？

我认为剩余的10％是由于磁盘级别的碎片。是否应该将SQL应用程序日志（错误日志等）与数据文件分开？由于跨日志的10000次点击，我找不到任何相关信息。我的提供程序将数据文件放在主实例磁盘上（与tempdb，trans和OS分开）

Answer 1

尽管存在磁盘级碎片，但无法在SSD SAN上解决。

我能找到的最佳解决方案是仅包含index_level = 0。这就是Hallengren的脚本所做的，我想那对我来说已经足够了。

        SELECT
            CASE WHEN MAX(ps.avg_fragmentation_in_percent) > 30 THEN
                'ALTER INDEX [' + i.name + '] ON [' + sc.NAME + '].[' + so.NAME + '] REBUILD  With (maxdop = 1);'
            ELSE
                'ALTER INDEX [' + i.name + '] ON [' + sc.NAME + '].[' + so.NAME + '] REORGANIZE ;'
            END AS [query], max( ps.avg_fragmentation_in_percent)
        FROM
            sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, 'DETAILED') AS ps
            INNER JOIN sys.indexes i
                ON ps.OBJECT_ID = i.OBJECT_ID
                    AND ps.index_id = i.index_id
                    AND ps.database_id = DB_ID()
                    AND i.name is not NULL
                    AND ps.avg_fragmentation_in_percent > 5 -- min % to return
                    AND ps.page_count > 1000 -- otherwise table is to smal.
                    AND ps.index_level = 0
            INNER JOIN sys.objects so
                ON i.OBJECT_ID = so.OBJECT_ID
            INNER JOIN sys.schemas sc
                ON sc.SCHEMA_ID = so.SCHEMA_ID
        GROUP BY sc.NAME, so.NAME, ps.index_id, i.name
        ORDER BY sc.NAME, so.NAME, ps.index_id DESC;

重建索引仍然零散

1 个答案: