可以对SQL Server系统表进行碎片整理吗？

我们有几个数据库，在其中创建和删除了大量表。据我们所知，SQL Server不会对系统基表进行任何内部维护，这意味着它们随着时间的流逝会变得非常零散，并且大小会膨胀。这给缓冲池造成了不必要的压力，并且还负面影响了操作的性能，例如计算数据库中所有表的大小。

有没有人建议尽量减少这些核心内部表上的碎片？一个显而易见的解决方案可以避免创建太多表（或在tempdb中创建所有临时表），但是出于这个问题的目的，我们可以说应用程序没有这种灵活性。

编辑：进一步的研究显示了这个悬而未决的问题，该问题看起来密切相关，并且表明可以选择某种形式的手动维护ALTER INDEX...REORGANIZE。

初步研究

有关这些表的元数据可以在以下位置查看sys.dm_db_partition_stats：

-- The system base table that contains one row for every column in the system
SELECT row_count,
    (reserved_page_count * 8 * 1024.0) / row_count AS bytes_per_row, 
    reserved_page_count/128. AS space_mb
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID('sys.syscolpars')
    AND index_id = 1
-- row_count:       15,600,859
-- bytes_per_row:   278.08
-- space_mb:        4,136

但是，sys.dm_db_index_physical_stats似乎不支持查看这些表的碎片：

-- No fragmentation data is returned by sys.dm_db_index_physical_stats
SELECT *
FROM sys.dm_db_index_physical_stats(
    DB_ID(),
    OBJECT_ID('sys.syscolpars'),
    NULL,
    NULL,
    'DETAILED'
)

Ola Hallengren的脚本还包含一个用于考虑is_ms_shipped = 1对象碎片整理的参数，但是即使启用了此参数，该过程也会默默地忽略系统基表。奥拉澄清说，这是预期的行为。仅msdb.dbo.backupset考虑ms_shipped的用户表（而不是系统表）（例如）。

-- Returns code 0 (successful), but does not do any work for system base tables.
-- Instead of the expected commands to update statistics and reorganize indexes,
-- no commands are generated. The script seems to assume the target tables will
-- appear in sys.tables, but this does not appear to be a valid assumption for
-- system tables like sys.sysrowsets or sys.syscolpars.
DECLARE @result int;
EXEC @result = IndexOptimize @Databases = 'Test',
        @FragmentationLow = 'INDEX_REORGANIZE',
        @FragmentationMedium = 'INDEX_REORGANIZE',
        @FragmentationHigh = 'INDEX_REORGANIZE',
        @PageCountLevel = 0,
        @UpdateStatistics = 'ALL',
        @Indexes = '%Test.sys.sysrowsets.%',
        -- Proc works properly if targeting a non-system table instead
        --@Indexes = '%Test.dbo.Numbers.%',
        @MSShippedObjects = 'Y',
        @Execute = 'N';
PRINT(@result);

其他要求的信息

我在检查系统表缓冲池使用情况下使用了Aaron查询的一种改编形式，发现在缓冲池中只有一个数据库有数十GB的系统表，在某些情况下，约80％的空间是可用空间。

-- Compute buffer pool usage by system table
SELECT OBJECT_NAME(p.object_id),
    COUNT(b.page_id) pages,
    SUM(b.free_space_in_bytes/8192.0) free_pages
FROM sys.dm_os_buffer_descriptors b
JOIN sys.allocation_units a
    ON a.allocation_unit_id = b.allocation_unit_id
JOIN sys.partitions p
    ON p.partition_id = a.container_id
    AND p.object_id < 1000 -- A loose proxy for system tables
WHERE b.database_id = DB_ID()
GROUP BY p.object_id
ORDER BY pages DESC

您确定肯定并准确地将此系统表确定为“不必要的缓冲池压力，并且对诸如计算数据库中所有表的大小等操作的性能产生负面影响”的唯一来源吗？您确定该系统表不是通过以下方式自我管理的：（a）最小化碎片或秘密检查碎片，或者（b）有效地在内存中进行管理，以使碎片整理级别确实不会产生太大影响？

你可以看到多少页都在使用，你可以看到有多少可用空间是在内存中的页面（page_free_space_percent始终NULL在分配DMF，但是这是可以从缓冲区DMV） -这应该给你一些想法如果您担心的是真的，您应该担心的是：

SELECT 
  Number_of_Pages = COUNT(*), 
  Number_of_Pages_In_Memory = COUNT(b.page_id),
  Avg_Free_Space = AVG(b.free_space_in_bytes/8192.0) 
FROM sys.dm_db_database_page_allocations
(
  DB_ID(),
  OBJECT_ID(N'sys.syscolpars'),
  NULL,NULL,'DETAILED'
) AS p
LEFT OUTER JOIN sys.dm_os_buffer_descriptors AS b
ON b.database_id = DB_ID() 
AND b.page_id = p.allocated_page_page_id 
AND b.file_id = p.allocated_page_file_id;

如果您的页面数很少（例如，系统表的页面数可能少于10000）或可用空间“不足”（不确定重新组织/重建的典型阈值），请关注其他更有趣的，低挂的水果。

如果您的页面数很大并且可用空间为“高”，那么，那么也许我会因为自己的自我维护而对SQL Server给予过多的赞誉。正如您从另一个问题中看到的那样，这可行...

ALTER INDEX ALL ON sys.syscolpars REORGANIZE;

...并确实减少了碎片。虽然它可能需要提升的权限（我没有尝试过作为peon）。

如果您感觉良好和/或有任何证据表明它对您的系统完全有积极影响，也许您可​​以在自己的维护过程中定期进行此操作。

根据Aaron答案的指导以及其他研究，以下是我所采用方法的快速摘要。

据我所知，检查系统基表碎片的选项是有限的。我继续提出了Connect问题，以提供更好的可见性，但是与此同时，这些选项似乎包括检查缓冲池或检查每行平均字节数之类的事情。

然后，我创建了一个在所有系统基本表上执行`ALTER INDEX ... REORGANIZE'的过程。在一些我们最常用（未使用）的dev服务器上执行此过程表明，系统基本表的累积大小最多可减少50GB（系统上有约5MM用户表，因此显然是极端情况）。

我们每晚的维护任务之一是清理大约50分钟的完成时间，该任务有助于清理由各种单元测试和开发创建的许多用户表。的组合sp_whoisactive，sys.dm_os_waiting_tasks和DBCC PAGE显示，等待通过对系统基本表的I / O控制。

重组所有系统基表后，维护任务减少到15分钟左右。仍然有一些I / O等待，但是它们大大减少了，这也许是由于缓存中保留了更多的数据和/或由于碎片减少而导致了更多的预读。

因此，我的结论是，考虑将ALTER INDEX...REORGANIZE系统基表添加到维护计划中可能是一件有用的事情，但是只有当您存在在数据库上创建异常数量的对象的情况下才可能考虑。