¿Con qué frecuencia deberían reconstruirse los índices en nuestra base de datos SQL Server?

Question

Actualmente nuestra base de datos tiene un tamaño de 10 GB y está creciendo en alrededor de 3 GB por mes. A menudo escucho que uno debe de vez en cuando reconstruir los índices, para mejorar el tiempo de ejecución de la consulta. Entonces, ¿con qué frecuencia debería reconstruir los índices en el escenario dado?

Answer 1

Hay un consenso general de que se debe reorganizar ("desfragmentar") sus índices tan pronto como la fragmentación del índice llega a más de 5 (a veces 10%), y debe reconstruir por completo cuando se va más allá del 30% (al menos esos son los números que he escuchado abogar en muchos lugares).

Michelle Ufford (a.k.a. "SQL Fool") tiene un automated index defrag script, que usa esos límites exactos para decidir cuándo reorganizar o reconstruir un índice.

También vea Brad McGehee's tips on rebuild indexes con algunas buenas ideas y consejos sobre cómo lidiar con la reconstrucción de índices.

---

utilizo este script aquí (no recuerdo cuando llegué a esto desde - quienquiera que fuese: muchas gracias Cosas realmente útil!) Para mostrar la fragmentación del índice en todos sus índices en una base de datos dada:

SELECT 
    t.NAME 'Table name', 
    i.NAME 'Index name', 
    ips.index_type_desc, 
    ips.alloc_unit_type_desc, 
    ips.index_depth, 
    ips.index_level, 
    ips.avg_fragmentation_in_percent, 
    ips.fragment_count, 
    ips.avg_fragment_size_in_pages, 
    ips.page_count, 
    ips.avg_page_space_used_in_percent, 
    ips.record_count, 
    ips.ghost_record_count, 
    ips.Version_ghost_record_count, 
    ips.min_record_size_in_bytes, 
    ips.max_record_size_in_bytes, 
    ips.avg_record_size_in_bytes, 
    ips.forwarded_record_count 
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips 
INNER JOIN 
    sys.tables t ON ips.OBJECT_ID = t.Object_ID 
INNER JOIN 
    sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id 
WHERE 
    AVG_FRAGMENTATION_IN_PERCENT > 0.0 
ORDER BY 
    AVG_FRAGMENTATION_IN_PERCENT, fragment_count 

Answer 2

Dado el tamaño de su base de datos, puede reconstruir fácilmente los índices una vez al mes. Pero a medida que aumenta el tamaño, digamos a alrededor de 500 GB, puede hacerlo dos veces al mes.

Answer 3

"Cuando lo necesites" y "Cuando puedas"!

Por ejemplo ...

• de prueba para la fragmentación primero y decidir si hacer nada, reorganizar o reconstruir. SQL Fool's script does this, por ejemplo, tiene @minFragmentation y @rebuildThreshold parámetros

• hace las estadísticas diarias, por ejemplo, pero los índices de los fines de semana. ¿Cuál es su ventana de mantenimiento?

Answer 4

Debe reconstruir los índices con la frecuencia suficiente para que la degradación del índice no afecte negativamente a las producciones. Entiendo que esto parece vago, pero todas las bases de datos son diferentes y se usan de diferentes maneras. Solo necesita reconstruir/desfragmentar periódicamente los índices que incurren en operaciones de escritura (inserciones/actualizaciones); sus tablas estáticas o de lectura mayoritaria no necesitarán mucha reindexación.

Deberá usar dbcc showcontig([Table]) para verificar el nivel de fragmentación de sus índices, determinar con qué frecuencia se fragmentan y en qué nivel se encuentra la fragmentación.

Utilice dbcc dbreindex([Table]) para reconstruir totalmente los índices cuando estén demasiado fragmentados (más de 20% -30% o menos) pero si no puede encontrar una ventana de tiempo de inactividad suficientemente grande y el nivel de fragmentación es relativamente bajo (1% -25%) , debe usar dbcc indexdefrag([Database], [Table], [Index]) para desfragmentar el índice en un estado "en línea". También tenga en cuenta que puede detener la operación de desfragmentación del índice y volver a iniciarla en otro momento sin perder ningún trabajo.

Mantener una base de datos y sus índices "en sintonía" requiere un poco de supervisión para realmente tener una idea de cuándo y qué reindexar.