SQL Server 2005: índice más grande que los datos almacenados

Question

Creé 1 base de datos con 2 grupos de archivos: 1 principal y 1 índice.

• grupo de archivos principal incluye 1 archivo de datos (* .mdf): almacenar todas las tablas
• grupo de archivos Índice incluye 1 archivo de índice (* .ndf): almacenar todos los índices

La mayoría de los índices son índices no agrupados

Después de un corto tiempo de uso de la base de datos, el archivo de datos es de 2 GB pero el archivo de índice es de 12 GB. No sé qué problema pasó en mi base de datos.

Tengo algunas preguntas:

1. ¿Cómo puedo reducir el tamaño del archivo de índice?
2. ¿Cómo puedo saber qué se almacena en el archivo de índice?
3. ¿Cómo rastrear todos los impactos en el archivo de índice?
4. ¿Cómo puedo limitar el crecimiento de tamaño del archivo de índice?

Answer 1

¿Cómo puedo reducir el tamaño del archivo de índice?

Elimine algunos índices innecesarios o reduzca el número de columnas en los existentes. Recuerde que la (s) columna (s) de índice agrupados es una columna incluida "oculta" en todos los índices no agrupados.

Si tiene un índice en a,b,c,d y un índice en a,b,c, podría considerar descartar el segundo, ya que el primero cubre el segundo.

También puede ser capaz de find potential unused indexes examinado sys.dm_db_index_usage_stats

¿Cómo saber lo que se almacena en el archivo de índice?

¡Almacenará lo que usted haya definido para almacenar! La siguiente consulta le ayudarán a contar los índices que están utilizando la mayoría del espacio y por qué razón (en datos de fila, los datos LOB)

SELECT convert(char(8),object_name(i.object_id)) AS table_name, i.name AS index_name, 
    i.index_id, i.type_desc as index_type, 
    partition_id, partition_number AS pnum, rows, 
    allocation_unit_id AS au_id, a.type_desc as page_type_desc, total_pages AS pages 
FROM sys.indexes i JOIN sys.partitions p 
     ON i.object_id = p.object_id AND i.index_id = p.index_id 
    JOIN sys.allocation_units a 
     ON p.partition_id = a.container_id 
     order by pages desc 

Answer 2

Mi conjetura (que creo que es donde también se dirigieron marc_s) es que' he declarado sus índices agrupados para que al menos algunas de sus tablas estén en el grupo de archivos de índice. El índice agrupado determina cómo (y dónde) se almacenan los datos reales para su tabla.

Publicar un poco de su código sin duda ayudará a otros a identificar el problema.

Creo que Martin Smith respondió a sus otras preguntas bastante bien. Añadiré esto ... Si quiere limitar los tamaños de los índices, debe evaluar sus índices. No agregue índices solo porque piensa que los puede necesitar. Haga pruebas con cargas realistas (o idealmente del mundo real) en la base de datos para ver qué índices realmente le darán impulsos necesarios para el rendimiento. Los índices tienen costos para ellos. Además del costo de espacio que está viendo, también se suman a la sobrecarga de inserciones y actualizaciones, que tienen que mantener los índices sincronizados. Debido a estos costos, siempre debe tener una buena razón para agregar un índice y debe pensar conscientemente sobre las concesiones.

Answer 3

Considere que en realidad es bastante común que el almacenamiento total requerido para los índices sea mayor que el almacenamiento requerido para los datos de la tabla dentro de una base de datos dada.

Sin embargo, su escenario particular parecería bastante excesivo. Como otros han señalado, si ha asignado el índice agrupado para que una tabla determinada resida en un archivo de datos separado (su archivo de datos de índice), entonces la tabla física completa residirá también en este archivo, porque de una manera de hablar el El índice agrupado es la tabla.

Proporcionar detalles de su Esquema de tabla y Estructuras de índice nos permitirá proporcionarle una orientación más específica.

Otros críticos han mencionado que:

• debe revisar su índice definiciones para los índices duplicados. Eche un vistazo a Identifying Overlapping Indexes por Brent Ozar.
• Debe buscar identificar los índices no utilizados. Toma una mirada como SQL Server Pedia artículo: Finding Unused Indexes

Otras vías para explorar incluyen la revisión de la fragmentación de los índices, ya que esto puede aumentar los requisitos de almacenamiento.

La fragmentación intensa, particularmente en el Índice Agrupado de una tabla que contiene datos LOB, puede dar como resultado un aumento significativo en las necesidades de almacenamiento. La reorganización del índice agrupado en tablas que contienen datos LOB compactará los datos LOB.

See Reorganizing and Rebuilding Indexes

Answer 4

@ respuesta de Martin-Smith es casi lo que necesitaba ...

Aquí es cómo ordenar por tamaño del índice en GB (mssql utiliza 8KB páginas == 128 páginas/MB)

SELECT 
    object_name(p.object_id) AS table_name 
    , i.name AS index_name 
    , i.index_id 
    , i.type_desc AS index_type 
    -- , partition_id 
    -- , partition_number AS pnum 
    -- , allocation_unit_id AS au_id 
    , rows 
    , a.type_desc as page_type_desc 
    , total_pages/(1024 * 128.0) AS sizeGB 
FROM 
    sys.indexes i 
    JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id 
    JOIN sys.allocation_units a ON p.partition_id = a.container_id 
    JOIN sys.all_objects ao ON (ao.object_id = i.object_id) 
    WHERE ao.type_desc = 'USER_TABLE' 
ORDER BY 
    -- table_name 
    sizeGB DESC