¿Cuándo deben descartarse y recrearse los índices?

Estamos construyendo un almacén de datos que inicialmente será de 1 TB y crecerá alrededor de 20 gigas cada mes.

Para ciertas tablas estamos haciendo procesos ETL diarios y otros estamos haciendo semanalmente / mensualmente.

Cuando hay una importación de datos en una tabla, ¿es necesario eliminar y volver a crear los índices?

¿Hay algún punto para soltar y recrear índices o se actualizan automáticamente?

Las estadísticas están configuradas para actualizarse automáticamente.

Muchas gracias por su ayuda y orientación.

Tengo este guión genio:

SELECT 'ALTER INDEX [' + ix.name + '] ON [' + s.name + '].[' + t.name + '] ' +
       CASE WHEN ps.avg_fragmentation_in_percent > 40 THEN 'REBUILD' ELSE 'REORGANIZE' END +
       CASE WHEN pc.partition_count > 1 THEN ' PARTITION = ' + cast(ps.partition_number as nvarchar(max)) ELSE '' END
FROM   sys.indexes AS ix INNER JOIN sys.tables t
           ON t.object_id = ix.object_id
       INNER JOIN sys.schemas s
           ON t.schema_id = s.schema_id
       INNER JOIN (SELECT object_id, index_id, avg_fragmentation_in_percent, partition_number
                   FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL)) ps
           ON t.object_id = ps.object_id AND ix.index_id = ps.index_id
       INNER JOIN (SELECT object_id, index_id, COUNT(DISTINCT partition_number) AS partition_count
                   FROM sys.partitions
                   GROUP BY object_id, index_id) pc
           ON t.object_id = pc.object_id AND ix.index_id = pc.index_id
WHERE  ps.avg_fragmentation_in_percent > 10 AND
       ix.name IS NOT NULL

de aquí:

http://weblogs.asp.net/okloeten/archive/2009/01/05/6819737.aspx

¿Sugiere que ejecute este script diariamente y, según los resultados, ejecute el código generado?

Si se trata de ETL cíclico y se encuentra en un entorno de datos de desarrollo (es decir, NO EN VIVO), definitivamente debe administrar sus índices como parte de su ciclo de carga.

Hago esto para varios conjuntos de datos cada mes, el mayor de los cuales agrega alrededor de 100 GB mensuales a un conjunto de datos de 5 TB.

He realizado pruebas exhaustivas y, según mi propia experiencia, la forma más eficiente de cargar con respecto a los índices es:

1. DISABLE índices no agrupados, dejando intacto el índice agrupado
2. Realizar carga de raw en su tabla de datos
3. REBUILD Índices NC

Si solo agrega filas periódicamente como parte de ETL administrado, este es el camino a seguir. Esto también garantiza que todas sus estadísticas estén actualizadas.

Para las estadísticas, es importante tener en cuenta que agregar 20GB a una base de datos de 1TB no alcanzará el punto de inflexión para una actualización automática de estadísticas, por lo que puede agregar un mes completo de datos sin actualizar las estadísticas.

Reconstruir sus índices NC es una buena forma de evitar esto. Es posible que también desee realizar una reconstrucción del índice agrupado periódicamente si la fragmentación aumenta (dependiendo de la estructura de su tabla y su clave agrupada).

Para una base de datos de 1 TB +, colocar y crear índices diariamente sería excesivo (incluso si recrea solo algunos de ellos).

Si le preocupan las velocidades de inserción / actualización en su tabla debido a la sobrecarga agregada por las actualizaciones de índice, le recomiendo dos cosas:

1. Utilice PK sustitutos para que las inserciones de índice agrupadas tengan una sobrecarga mínima.
2. Perfile su DWH y cree índices no agrupados donde sea absolutamente necesario.

Tendrá que vivir con actualizaciones de índice no agrupadas durante las operaciones de inserción / actualización.

Si le preocupa la fragmentación del índice, le recomiendo crear trabajos diarios (trabajos del Agente SQL) para reconstruir los índices. El período de reconstrucción puede ser realmente cualquier cosa, depende del nivel de fragmentación. Debería notar esto en la práctica y configurar el cronograma de trabajo en consecuencia.

Puede agregar algo de lógica a los scripts de reconstrucción, según el nivel de fragmentación. Algunas buenas pautas que puedes encontrar aquí .

La conclusión es que, bajo ninguna circunstancia, no debe realizar una reconstrucción completa del índice en una base de datos de ese tamaño.

Lea sobre la fragmentación

Desea reconstruir (no descartar / volver a crear) índices cuando la fragmentación es "demasiado alta"

Tengo el proceso IndexOptimize en este paquete programado para ejecutarse todas las noches.