相关疑难解决方法(0)

我们有几个数据库，其中创建和删除了大量表。据我们所知，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 …

我们的企业标准之一是为用户表/索引使用单独的文件组/文件。这被设置为默认值，因此无需限定 CREATE TABLE 语句。

所以它看起来像这样

• fileid 1 = 系统表，MDF
• 文件 ID 2 = t-log = LDF
• fileid 3 = 用户资料 = NDF

这里的任何人都可以帮助我理解为什么强制执行此操作的原始理由吗？

我会坦白说我认为这是巫毒教。上午我错了......？

编辑：我知道如何使用文件组来分离索引/分区/存档，以及如何逐步恢复。这个问题是关于在同一卷上为系统表使用单独的文件组。