¿Cómo reducir la fragmentación HEAP en SQL Server?

Hace poco descubrí que una tabla de montón tenía más del 70% de fragmentación. Entonces decidí hacer un

ALTER TABLE dbo.myTable REBUILD

Curiosamente, después tuve un 20% de fragmentación. No había escrito en esa mesa desde entonces. Así que decidí hacer la reconstrucción una vez más.

Después de la segunda vez, la mesa tiene una fragmentación del 50%, ¡así que aún más! Realmente no entiendo cómo puede suceder esto ...

¿Qué significa la fragmentación en un montón?

El valor de fragmentación en el montón que obtiene de la columna avg_fragmentation_in_percental consultar sys.dm_db_index_physical_statsDMV indica que

Fragmentación lógica para índices, o fragmentación de extensión para montones en la unidad de asignación IN_ROW_DATA.

Además, el mismo BOL dice que

Este es el porcentaje de extensiones fuera de orden en las páginas de hoja de un montón. Una extensión fuera de orden es aquella en la que la extensión que contiene la página actual para un montón no es físicamente la siguiente extensión después de la extensión que contiene la página anterior.

Entonces puede ver que no es el espacio libre presente en las páginas asignadas a Heap sino la secuencia variable de páginas lo que crea la fragmentación.

Esto se puede demostrar mediante una pequeña prueba. Creemos una tabla de montón e inserte algunos registros en ella y luego verifiquemos la fragmentación.

create table dbo.HeapTest
(
Id INT not NULL Default (1),
Col1   char(5000) Not null Default ('Heaps Are Cool')
)

SET NOCOUNT ON

Insert into dbo.Heaptest default values
go 50

select index_type_desc,avg_fragmentation_in_percent,fragment_count,
avg_page_space_used_in_percent,record_count
from sys.dm_db_index_physical_stats(db_id(),object_id('dbo.HeapTest','U'),0,default,'detailed')

Por lo tanto, la tabla del montón se crea con 50 registros. A continuación se muestra cómo se ve la fragmentación después de la consulta DMV sys.dm_db_index_physical stats

Puede ver avg_fragmentation_in_percentque el valor de la columna es 33%. Ahora veamos cómo están organizadas las páginas. Esto se puede hacer mediante la consulta no documentada%%lockres%% . La consulta sería

SELECT  %%lockres%%, * FROM dbo.HeapTest;

Y a continuación se muestra cómo se ve la salida. Adjuntando solo una parte relevante del mismo. La consulta produjo 50 filas ya que insertamos 50 filas en nuestra tabla dbo.HeapTest.

Lo que dice es que la primera página tiene ID, 197la página siguiente tiene ID. Las 242páginas siguientes tienen ID continua hasta que alcanzamos la ID de la página 264porque después de eso obtenemos la ID de la página 280. Entonces, este salto en los números de ID de página es lo que realmente causa la fragmentación.

Ahora no sea que reconstruya el montón y ejecute el comando nuevamente para ver la fragmentación y cómo se organizan las páginas. Obtenemos fragmentación como

Puedes ver que la fragmentación es ahora 14%.

Veamos los números de página asignados

Solo tenemos un salto de salto; todas las páginas tienen asignada la ID de página en serie. Dado que solo un salto la fragmentación disminuyó considerablemente.

Reconstruí el montón nuevamente y ahora, cuando verifiqué la fragmentación, desapareció por completo. Y la asignación de ID de página es como

Por qué aumentó la fragmentación

Ahora, con respecto a lo que podría haber causado el aumento de la fragmentación, podemos corroborarlo al hecho de que cuando las páginas se asignaban al montón, no serían continuas, como se vio anteriormente, lo que causó que el valor de la fragmentación aumentara fue el salto en la ID de PÁGINA asignada a las páginas.

En la parte posterior de la cabeza, también debe tener en cuenta que la palabra fragmentación para HEAP no tiene ningún significado, ¿cómo definiría la fragmentación para un montón de páginas no ordenadas?

Realmente preocupado por la fragmentación

Si realmente enfrenta un escenario en el que la tabla de montón está fragmentada y ralentiza las consultas, sería mejor crear un índice agrupado en la tabla que reconstruirlo. La razón es que cuando reconstruye el montón todos los índices subyacentes no agrupados también se reconstruyen, lo que hace que el proceso de reconstrucción tarde mucho más tiempo, utilizando muchos recursos y un registro de transacciones hinchado. En un sistema de producción, uno siempre trataría de evitar esto. Paul cubrió esto en su Sección de Mitos sobre el montón .

PD: No utilices comandos no documentados en el sistema de producción. Esto fue solo para demostración.