SQL Server 2014 CTP1 presenta extensiones a las opciones de operación en línea que serán buenas noticias para las empresas que alojan bases de datos muy grandes que requieren poco o ningún tiempo de inactividad.
Para establecer el contexto, imagine que está utilizando SQL Server 2012 Enterprise Edition para las funciones de partición de índice y administración de índice en línea e intenta la siguiente reconstrucción de índice en una tabla particionada:
ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber] ON [dbo].[FactInternetSales] REBUILD PARTITION = ALL WITH (ONLINE= ON);
Al probar esto en SQL Server 2012, podemos reconstruir todas las particiones en línea sin errores. Pero, ¿y si queremos especificar una partición específica en lugar de todas las particiones?
ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber] ON [dbo].[FactInternetSales] REBUILD PARTITION = 1 WITH (ONLINE= ON);
Al intentar esto en SQL Server 2012 o anterior, verá el siguiente mensaje de error:
Mensaje 155, nivel 15, estado 1, línea 4'EN LÍNEA' no es una opción reconocida de ALTER INDEX REBUILD PARTITION.
Pero a partir de SQL Server 2014 (a partir de CTP1), ahora se admiten las operaciones de índice de partición única en línea. Y esto es sin duda un gran problema para los escenarios de mantenimiento de tablas muy grandes en los que preferiría, o de hecho debe dividir su mantenimiento general en partes más pequeñas durante un período de tiempo. También es posible que desee realizar un mantenimiento a nivel de partición solo para aquellas particiones que realmente lo requieran, por ejemplo, aquellas particiones que superen un nivel de fragmentación específico.
Para probar esta funcionalidad CTP1 de SQL Server 2014, utilicé AdventureWorksDW2012 con una versión de FactInternetSales que contiene 61 847 552 filas y está dividida por la columna ShipDate.
Reconstruyendo todas las particiones en línea para la tabla usando PARTITION = ALL en mi entorno de prueba tomó 3 minutos y 23 segundos. Con respecto a la duración general, mis pruebas fueron para índices que no estaban tan fragmentados, por lo que la duración de 3 minutos y 23 segundos representa una duración promedio en algunas pruebas. También tenga en cuenta que no tenía cargas de trabajo competidoras ejecutándose en ese momento, por lo que la reconstrucción en línea se lleva a cabo sin tener que competir con otras cargas de trabajo significativas contra el índice en cuestión.
La forma del plan de ejecución de consultas para la reconstrucción del índice en línea usando PARTITION = ALL fue el siguiente:
Plan de ejecución para la reconstrucción en línea de todas las particiones
Tenga en cuenta que las operaciones están habilitadas en paralelo excepto por el operador Constant Scan. En el plan de ejecución de consultas, puede ver 39 filas en la exploración constante de referencia externa que se pasan al operador Distribute Streams y luego activan el bucle anidado.
¿El significado de las 39 filas? La siguiente consulta valida el número máximo de particiones de sys.dm_db_partition_stats . Para mi entorno de prueba, el resultado fue 39 para el número máximo de particiones, coincidiendo con lo que vi para las filas reales de Constant Scan:
SELECT MAX([partition_number]) AS [max_partition_number]
FROM [sys].[dm_db_partition_stats]
WHERE [object_id] = OBJECT_ID('FactInternetSales');
Ahora también notará el operador Insertar índice en línea en el plan anterior. Eliminando ONLINE = ON opción de mi ALTER INDEX REBUILD (haciéndolo una operación fuera de línea), y manteniendo la PARTITION = ALL opción, el único cambio fue tener un operador de "Inserción de índice" en lugar de una "Inserción de índice en línea" en el plan de ejecución de consultas, y también una reducción en la duración, donde mi prueba mostró una duración de ejecución de 1 minuto y 9 segundos en comparación con el en línea 3 minutos y 23 segundos.
Luego probé una reconstrucción en línea de una partición con 5 678 080 filas (recuerde que el recuento total de filas de la tabla es 61 847 552 filas). Para esta prueba, la duración general tomó exactamente 1 minuto y tenía la siguiente forma de plan de ejecución de consultas:
Plan de ejecución para la reconstrucción en línea de una única partición
La primera observación es que se trata de un plan en serie. También tenga en cuenta que dije que elegí una partición de las 39 originales, aunque esa partición en particular representó ~ 9% de las filas en la tabla en general. Observe también que Constant Scan muestra 1 fila en lugar de 39, como cabría esperar.
¿Qué pasa con la duración de una sola partición, reconstrucción fuera de línea? En mi entorno de prueba, esto tomó 11 segundos en comparación con la reconstrucción en línea de 1 minuto. La forma del plan de ejecución de consultas para la reconstrucción fuera de línea de una sola partición fue la siguiente:
Plan de ejecución para la reconstrucción sin conexión de una sola partición
Observe que no hay un proceso de exploración constante o bucles anidados asociados y también observe que este plan ahora tiene operadores paralelos en comparación con el plan en serie anterior, aunque ambos están realizando una exploración de índice agrupado para 5 678 080 filas. Además, hacer una búsqueda de palabra clave de "partición" en el texto del plan XML para la operación de índice paralelo fuera de línea de partición única no dio como resultado ninguna coincidencia, en comparación con el plan en serie, la operación de índice de partición única en línea que tenía Partitioned ="true" para el Escaneo de índice agrupado e índice en línea Insertar operadores físicos.
Volver a la exploración principal...
¿Puedo elegir algunas, pero no todas las particiones en una sola ejecución? Lamentablemente no.
El ALTER INDEX y ALTER TABLE los comandos tienen la PARTITION = ALL argumento y luego PARTITION = <partition number> argumento, pero no la capacidad de enumerar varias particiones para una sola operación de reconstrucción. Sin embargo, no me quejo mucho de esto, ya que estoy feliz de tener la capacidad de reconstruir una sola partición en línea y no es terriblemente complicado ejecutar la operación una vez para cada reconstrucción, sin embargo, el impacto acumulativo en la duración fue algo Quería explorar más.
¿Cuánto tiempo llevaría reconstruir las 39 particiones por separado y en línea en comparación con PARTITION = ALL? duración de 3 minutos y 23 segundos?
Sabemos que un beneficio de las reconstrucciones en línea es la capacidad de seguir accediendo a la tabla o índice asociado durante la operación de indexación. Pero a cambio de esa operación en línea, perderemos la ventaja de rendimiento de la reconstrucción en comparación con una reconstrucción fuera de línea. Y lo que quería saber a continuación era cómo se comportaría una reconstrucción en línea de una partición en comparación con PARTITION = ALL alternativa.
Al ejecutar 39 operaciones de reconstrucción separadas (una reconstrucción para cada partición única), la duración total de la ejecución fue de 9 minutos y 54 segundos en comparación con PARTITION = ALL que tomó 3 minutos y 23 segundos, por lo que claramente el enfoque gradual no es tan rápido como una reconstrucción en línea de todas las particiones en una declaración. Si bien pude hacer una partición a la vez, el beneficio general es la capacidad de dividir nuestras actividades de mantenimiento a lo largo del tiempo y mantener el acceso a los objetos a medida que se reconstruyen, pero si está buscando una reconstrucción más corta ventana, las opciones fuera de línea siguen siendo las más rápidas, seguidas de las opciones en línea para PARTITION = ALL y luego en último lugar, haciendo una partición a la vez.
La siguiente tabla resume las comparaciones de duración y, nuevamente, estas pruebas se basaron en SQL Server 2014 CTP1 y un tamaño de tabla muy específico y una configuración de invitado de VM, así que preste más atención a las duraciones relativas entre las pruebas que a las duraciones en sí:
| Descripción de la prueba | Duración |
|---|---|
| Reconstrucción sin conexión de todas las particiones | 1:09 |
| Reconstrucción en línea de todas las particiones | 3:23 |
| Reconstrucción en línea de una partición | 1:00 |
| Reconstrucción sin conexión de una partición | 0:11 |
| Reconstrucción en línea de todas las particiones, una partición a la vez | 9:54 |
Ahora también hay otros aspectos a explorar sobre este tema. El hecho de que una operación esté en línea no significa que no haya algunos momentos (o más) en los que aún se mantengan bloqueos en el objeto de destino. Las operaciones de índice todavía tienen un comportamiento de bloqueo para las operaciones en línea, y SQL Server 2014 también ha proporcionado opciones para esto, que exploraré en una publicación separada.
