sql-server - una - rebuild index sql server
¿Con qué frecuencia deberían reconstruirse los índices en nuestra base de datos SQL Server? (4)
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?
"Cuando lo necesites" y "Cuando puedas"!
Por ejemplo...
Pruebe primero la fragmentación y decida si no hacer nada, reorganizar o reconstruir. La secuencia de comandos de SQL Fool hace esto , por ejemplo, tiene los parámetros
@minFragmentationy@rebuildThresholdHaga las estadísticas diariamente, por ejemplo, pero los índices los fines de semana. ¿Cuál es su ventana de mantenimiento?
Dado el tamaño de su base de datos, puede reconstruir fácilmente los índices una vez por mes. Pero a medida que aumenta el tamaño, digamos a alrededor de 500 GB, puede hacerlo dos veces al mes.
Debe reconstruir índices con la frecuencia suficiente para que la degradación del índice no afecte negativamente a la producción. 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.
Tendrá que 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 (por encima del 20% -30% o menos), pero si no puede encontrar una ventana de tiempo de inactividad lo 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 movimiento "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 monitoreo para realmente tener una idea de cuándo y qué reindexar.
Existe un consenso general de que debe reorganizar ("desfragmentar") sus índices tan pronto como la fragmentación del índice llegue a más de 5 (a veces 10%), y debe reconstruirlos completamente cuando va más allá del 30% (al menos esos son los números I '' he oído defender en muchos lugares).
Michelle Ufford (también conocida como "SQL Fool") tiene una secuencia de comandos de desfragmentación de índices automatizada , que utiliza esos límites exactos para decidir cuándo reorganizar o reconstruir un índice.
También vea los consejos de Brad McGehee sobre los índices de reconstrucción con algunos buenos pensamientos y consejos sobre cómo lidiar con la reconstrucción del índice.
Utilizo este script aquí (no puedo recordar cuándo obtuve esto, quien sea: muchas gracias, cosas realmente útiles) 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