De acuerdo con Marc y Unkown arriba ... 6 índices en el índice agrupado son demasiados, especialmente en una tabla que tiene solo 14 columnas. No debería tener más de 3 o 4, si eso, diría 1 o tal vez 2. Es posible que sepa que el índice agrupado es la tabla real en el disco, por lo que cuando se inserta un registro, el motor de la base de datos debe ordenarlo y colóquelo en su lugar ordenado y organizado en el disco. Los índices no agrupados no lo son, son compatibles con las 'tablas' de búsqueda. Mis VLDB están dispuestos en el disco (ÍNDICE CLUSTERADO) de acuerdo con el primer punto a continuación.
- Reduzca su índice agrupado a 1 o 2. Las mejores opciones de campo son IDENTIDAD (INT), si tiene uno, o un campo de fecha en el que los campos se agregan a la base de datos, o algún otro campo que sea un tipo natural de cómo se agregan sus datos a la base de datos. El punto es que usted está tratando de mantener esos datos en la parte inferior de la tabla... o tenerlos dispuestos en el disco de la mejor manera (90%+) que leerá los registros. Esto hace que no se produzca una reorganización o que solo se requiera un golpe para colocar los datos en el lugar correcto para la mejor lectura. Asegúrese de colocar los campos eliminados en índices no agrupados para no perder la eficacia de la búsqueda. NUNCA he puesto más de 4 campos en mis VLDB. Si tiene campos que se actualizan con frecuencia y están incluidos en su índice agrupado, OUCH, eso reorganizará el registro en el disco y causará una fragmentación COSTOSA.
- Compruebe el factor de relleno en sus índices. Cuanto mayor sea el número del factor de relleno (100), más completas estarán las páginas de datos y las páginas de índice. En relación con cuántos registros tiene y cuántos registros está insertando, cambiará el factor de relleno # (+ o -) de sus índices no agrupados para permitir el espacio de relleno cuando se inserta un registro. Si cambia su índice agrupado a un campo de datos secuenciales, esto no importará tanto en un índice agrupado. Regla general (IMO), factor de relleno 60-70 para escrituras altas, 70-90 para escrituras medias y 90-100 para lecturas altas/escrituras bajas. Al bajar su factor de relleno a 70, significará que por cada 100 registros en una página, se escriben 70 registros, lo que dejará espacio libre de 30 registros para registros nuevos o reorganizados. Ocupa más espacio, pero es mejor que tener que DESFRAGEAR cada noche (ver 4 a continuación)
- Asegúrese de que las estadísticas existan en la tabla. Si desea realizar un barrido de la base de datos para crear estadísticas utilizando "sp_createstats 'indexonly'", entonces SQL Server creará todas las estadísticas en todos los índices que el motor ha acumulado que requieren estadísticas. Sin embargo, no omita el atributo 'indexonly' o agregará estadísticas para cada campo, eso no sería bueno.
- Compruebe la tabla o los índices mediante DBCC SHOWCONTIG para ver qué índices se fragmentan más. No entraré en detalles aquí, solo sé que debes hacerlo. Luego, en función de esa información, cambie el factor de relleno hacia arriba o hacia abajo en relación con los cambios que experimentan los índices y con qué rapidez (a lo largo del tiempo).
- Configure un programa de trabajo que se realizará en línea (DBCC INDEXDEFRAG) o fuera de línea (DBCC DBREINDEX) en índices individuales para desfragmentarlos. Advertencia:no haga DBCC DBREINDEX en una tabla tan grande sin que sea durante el tiempo de mantenimiento porque hará que las aplicaciones se caigan... especialmente en el ÍNDICE CLUSTERADO. Has sido advertido. Prueba y prueba esta parte.
- Use los planes de ejecución para ver qué EXPLORACIONES y FAT PIPES existen y ajuste los índices, luego desfragmente y reescriba los procesos almacenados para deshacerse de esos puntos críticos. Si ve un objeto ROJO en su plan de ejecución, es porque no hay estadísticas en ese campo. Eso es malo. Este paso es más "arte que ciencia".
- En las horas de menor actividad, ejecute ACTUALIZAR ESTADÍSTICAS CON EXPLORACIÓN COMPLETA para proporcionar al motor de consultas tanta información como pueda sobre las distribuciones de datos. De lo contrario, realice las ESTADÍSTICAS DE ACTUALIZACIÓN estándar (con un escaneo estándar del 10 %) en las tablas durante la noche o más a menudo, según lo considere adecuado, con sus observaciones para asegurarse de que el motor tenga más información sobre las distribuciones de datos para recuperar los datos de manera eficiente.
Lo siento, esto es tan largo, pero es extremadamente importante. Aquí solo le he dado información mínima, pero ayudará mucho. Hay algunos presentimientos y observaciones que se relacionan con las estrategias utilizadas por estos puntos que requerirán su tiempo y pruebas.
No es necesario ir a la edición Enterprise. Sin embargo, lo hice para obtener las funciones de las que se habló anteriormente con la partición. Pero lo hice ESPECIALMENTE para tener capacidades mucho mejores de subprocesos múltiples con búsqueda y DESFRAGACIÓN y mantenimiento en línea ... En la edición Enterprise, es mucho mejor y más amigable con VLDB. La edición estándar tampoco maneja hacer DBCC INDEXDEFRAG con bases de datos en línea.
