Чому моя база даних все ще фрагментована після того, як я відновив і переробив все?

У мене є база даних, яку я спробував дефрагментувати всі таблиці відразу, запустивши цей T-SQL:

SELECT 
        'ALTER INDEX all ON ' + name + ' REORGANIZE;' + CHAR(10) +
        'ALTER INDEX all ON ' + name + ' REBUILD;'
    FROM sys.tables

Потім скопіюйте та вставте висновок у нове вікно запиту та виконайте це. Я не мав помилок, але все ще маю фрагментацію. Я також спробував запустити обидві команди окремо і все ще маю фрагментацію. Примітка. Мені стало відомо, що REORGANIZEAaron не потребує, і я знаю, що можу використовувати динамічний sql для автоматизації цього.

Я запустив це, щоб визначити, що у мене все ще є фрагментація:

SELECT * FROM 
sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, NULL) 
WHERE avg_fragmentation_in_percent > 0

І я отримав:

database_id object_id   index_id    partition_number    index_type_desc alloc_unit_type_desc    index_depth index_level avg_fragmentation_in_percent    fragment_count  avg_fragment_size_in_pages  page_count  avg_page_space_used_in_percent  record_count    ghost_record_count  version_ghost_record_count  min_record_size_in_bytes    max_record_size_in_bytes    avg_record_size_in_bytes    forwarded_record_count  compressed_page_count
85  171147655   1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   36.3636363636364    5   2.2 11  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  421576540   1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   75  7   1.14285714285714    8   NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  965578478   1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   14.7058823529412    6   5.66666666666667    34  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1061578820  1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   40  4   1.25    5   NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1109578991  1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   30.7692307692308    5   2.6 13  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1205579333  2   1   NONCLUSTERED INDEX  IN_ROW_DATA 2   0   50  5   1.6 8   NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1493580359  1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   50  6   1.66666666666667    10  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL

Я знаю, що я пропускаю щось справжнє базове, але не знаю, що.

Столи крихітні. Кількість сторінок у ваших таблицях:

11, 8, 6, 5, 13, 8, 10

Вони займають 480 кб загалом. Дефрагментувати буквально нема чого.

Редагувати: це вимагає трохи більше пояснень.

Нова таблиця або індекс зазвичай виділяються, це перші 8 сторінок із змішаної, а не рівномірної міри. Отже, для кожної з перших 8 сторінок можна виділити різні змішані файли. Отже, таблиця або покажчик, що займає 8 сторінок, може мати 8 фрагментів, по 1 на кожному з 8 різних змішаних розширень.

Більш широко використовувані сценарії дефрагментації (кілька прикладів, приведених нижче), як правило, виключають невеликі таблиці через це. IIRC, <500 сторінок є в одній або обох. При цих розмірах користь для дефрагментації є дуже малою, і цифри фрагментації потенційно перекошені за рахунок змішаних розмірів.

• Ola Hallengren - рішення з обслуговування SQL Server
• SQL Fool - індекс сценарію дефрагментації

Цитата з " Кращі практики дефрагментації індексу Microsoft SQL Server 2000 ":

"Фрагментація впливає на введення / виведення диска. Тому зосередьтеся на більших індексах, оскільки їх сторінки менше кешуються SQL сервером. Використовуйте кількість сторінок, про які повідомляє DBCC SHOWCONTIG, щоб отримати уявлення про розмір індексів (кожна сторінка є 8 КБ). в загальному, ви не повинні бути пов'язані з рівнем фрагментації індексів з менш ніж 1000 сторінок. в тестах, індекси , що містять більше 10000 сторінок реалізований приріст продуктивності, з найбільшим прибутку за індексами зі значно більш сторінками (більше ніж 50 000 сторінок) . "

Тож цей тип відповідає на ваше запитання і підтримує відповіді Марка та Аарона.

Ви можете знайти хорошу інформацію про фрагментацію індексу в наступних статтях від Brent Ozar:

• Показники фрагментації покажчиків: Частина 1, Основи
• Показники фрагментації покажчиків: Частина 2, Розмір питань

Також океан чудової інформації про індекси загалом (також про проблеми з фрагментацією) можна знайти в блозі Кімберлі Трипп .

Це не призначено для відповіді на ваше запитання, але воно ніколи не впишеться в коментар. Ви можете створити цей сценарій динамічно, не копіюючи та вставляючи вихід у інше вікно. Беручи до уваги , що немає абсолютно ніяких підстав , REORGANIZEа потім REBUILD:

DECLARE @sql NVARCHAR(MAX) = N'';

SELECT @sql += N'ALTER INDEX all ON ' + name + ' REBUILD;
    ' FROM sys.tables;

PRINT @sql; -- to see the first 8,000 characters and make sure it checks out
-- EXEC sp_executesql @sql;