У нас є кілька баз даних, в яких створюється і випадає велика кількість таблиць. З того, що ми можемо сказати, 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'
)Сценарії Ола Галленгрена також містять параметр, який враховує дефрагментацію 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);
Додаткова запитувана інформація
Я використав адаптацію запиту Аарона під використанням буфера пулів системної таблиці перевірити, і це виявило, що в буферному пулі є десятки ГБ системних таблиць лише для однієї бази даних, причому ~ 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