Compresión en un montón

El siguiente es un párrafo de Microsoft Docs :

Las nuevas páginas asignadas en un montón como parte de las operaciones DML no utilizarán la compresión PAGE hasta que se reconstruya el montón. Reconstruya el montón eliminando y volviendo a aplicar la compresión, o creando y eliminando un índice agrupado.

No puedo entender por qué este es el caso. Si tengo un montón con una configuración de compresión especificada, ¿por qué no se aplicaría a una página que pertenece a la tabla?

Gracias

Si bien no conozco los mecanismos internos específicos que son responsables de las diferencias, puedo decir que los montones se administran (internamente) de manera ligeramente diferente que los índices agrupados (y posiblemente también los índices no agrupados):

• Eliminar filas de un montón de modo que una o más páginas de datos estén vacías (sin filas asignadas) no libera necesariamente ese espacio. Es probable que necesite crear y luego soltar un índice agrupado en la tabla o llamar ALTER TABLE [TableName] REBUILD;(a partir de SQL Server 2014?). Consulte la página Documentos de Microsoft para ELIMINAR para obtener más detalles y opciones.

• Insertar filas individuales (es decir, no basadas INSERTen un conjunto ) en un montón no llena las páginas de datos tan completamente como lo hace con los índices agrupados. Los índices agrupados encajarán en filas siempre que haya espacio para la fila (datos y sobrecarga de fila) más la sobrecarga de 2 bytes de la matriz de ranuras. Sin embargo, las páginas de datos en los montones no usan la cantidad de bytes que quedan en la página, sino que usan un indicador muy generalizado de cuán llena está la página, y no hay tantos niveles que se informan. Los niveles son algo así como: 0%, 20%, 50%, 80% y 100% completo. Y cambiará al 100% mientras haya espacio para otra fila (y, de hecho, si se hubiera insertado el mismo número de filas en una operación basada en conjuntos, habría llenado la página tanto como fuera posible). Por supuesto, al igual que con elDELETE operaciones, la reconstrucción del montón empaquetará tantas filas como quepan en la página de datos.

Ahora considere la siguiente información, tomada de la sección "Cuando ocurre la compresión de la página" de la página de documentos de Microsoft para la implementación de la compresión de la página :

... A medida que se agregan datos a la primera página de datos, los datos se comprimen en filas. ... Cuando la página está llena, la siguiente fila a agregar inicia la operación de compresión de la página. Se revisa toda la página; ...

Por lo tanto, parece completamente en línea con este otro comportamiento del Montón que requerirían una ALTERACIÓN DE LA RECONSTRUCCIÓN DE LA TABLA, CREAR / COLOCAR un índice agrupado o un cambio en la configuración de Compresión de datos (todo lo cual reconstruye el montón) antes de que se escriban las páginas de datos óptimamente Si los montones no son plenamente conscientes de las "páginas completas" (hasta que se reconstruye el montón) y no saben cuándo la página está definitivamente llena, entonces no sabrán cuándo iniciar la operación de compresión de la página (cuando se trata de actualizaciones y solo insertos de hilera).

Otro tecnicismo que limitaría aún más algunos Heaps de la aplicación automática de la compresión de página (incluso si de otro modo pudieran hacerlo) es que la aplicación de la compresión requeriría la reconstrucción de todos los índices no agrupados para ese montón (si existe). Como esa página vinculada para "Compresión de datos" también dice:

Cambiar la configuración de compresión de un montón requiere que todos los índices no agrupados en la tabla se reconstruyan para que tengan punteros a las nuevas ubicaciones de fila en el montón.

Los "punteros" a los que se hace referencia son los ID de fila (RID), que son una combinación de: ID de archivo, ID de página y posición / posición en la página. Estos RID se copian en índices no agrupados. Al ser una ubicación física precisa, a veces son búsquedas más rápidas que atravesar un árbol b con las teclas de índice agrupado. Pero, un inconveniente de una ubicación física es que puede cambiar, y ese es el problema aquí. Sin embargo, los índices agrupados no sufren este problema porque sus valores clave se copian en índices no agrupados como el puntero de vuelta al índice agrupado. Y los valores clave siguen siendo los mismos, incluso cuando cambia su ubicación física.

Ver también:

• la sección "Administración de montones" de la página de documentos de Microsoft para montones (tablas sin índices agrupados) :

  Para reconstruir un montón para recuperar el espacio desperdiciado, cree un índice agrupado en el montón y, a continuación, suelte ese índice agrupado.

• la sección "Consideraciones para cuando utiliza la compresión de filas y páginas" de la página de documentos de Microsoft para la compresión de datos :

  Cuando se configura un montón para la compresión a nivel de página, las páginas reciben compresión a nivel de página solo de las siguientes maneras:

  • Los datos se importan en masa con las optimizaciones en masa habilitadas.
  • Los datos se insertan usando la sintaxis INSERT INTO ... WITH (TABLOCK) y la tabla no tiene un índice no agrupado.
  • Una tabla se reconstruye ejecutando la instrucción ALTER TABLE ... REBUILD con la opción de compresión PAGE.

  Y la declaración citada en la pregunta.

No todos los mecanismos en SQL Server son como creemos que deberían ser.

Paul Randal ha proporcionado una fuerte recomendación sobre la gestión del problema.

http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2930-fixing-heap-fragmentation/