Mesas muy grandes en SQL Server

Question

Tenemos una tabla muy grande (> 77M de registros y en crecimiento) ejecutándose en SQL Server 2005 64bit Standard edition y estamos viendo algunos problemas de rendimiento. Hay hasta cien mil registros agregados diariamente.

¿Alguien sabe si existe un límite en la cantidad de registros que SQL Server Standard edition puede manejar? ¿Debería considerar mudarse a la edición Enterprise o hay algunos trucos que podemos usar?

Otros detalles:

La tabla en cuestión es bastante plana (14 columnas), hay un índice agrupado con 6 campos, y otros dos índices en campos individuales.

Agregamos un cuarto índice usando 3 campos que estaban en una consulta de selección en un problema y no vimos ninguna diferencia en el rendimiento estimado (la consulta es parte de un proceso que tiene que ejecutarse en las horas libres para que no nos pongamos no tienen métricas todavía). Estos campos son parte del índice agrupado.

Answer 1

[hay un índice agrupado con 6 campos, y otros dos índices en campos individuales.]

Sin conocer los detalles acerca de los campos, me gustaría tratar de encontrar una forma de hacer que el índice agrupado sea más pequeño.

Con SQL Server, todos los campos de clave agrupada también se incluirán en todos los índices no agrupados (como una forma de realizar la búsqueda final desde el índice no agrupado a la página de datos real).

Si tiene seis campos a 8 bytes cada uno = 48 bytes, multiplique eso por dos índices más multiplicados por 77 millones de filas, y verá un montón de espacio desperdiciado que se traduce en un lote de operaciones de E/S (y por lo tanto degrada el rendimiento).

Para el índice agrupado, es absolutamente CRUCIAL que sea único, estable y lo más pequeño posible (preferiblemente una sola INT o similar).

Marc

Answer 2

http://msdn.microsoft.com/en-us/library/ms143432.aspx

tienes un poco de espacio para crecer.

En cuanto a los problemas de rendimiento, esa es otra pregunta. Almacenamiento en memoria caché, fragmentación, normalización, indización, ajuste de consulta, ajuste de código de aplicación, etc.

Answer 3

Lo primero que vería es indexar. Si usa el generador de planes de ejecución en Management Studio, quiere ver las búsquedas de índice o de índice agrupado. Si ve escaneos, en particular escaneos de tablas, debería ver la indexación de las columnas en las que generalmente busca para ver si eso mejora su rendimiento.

No debería tener que pasar a Enterprise Edition para esto.

Answer 4

Estándar debería ser capaz de manejarlo. Me gustaría ver la indexación y las consultas que utiliza con la tabla. Desea estructurar las cosas de forma tal que sus insertos no causen demasiados recalcs de índice, pero sus consultas aún pueden aprovechar el índice para limitar las búsquedas a una pequeña porción de la tabla.

Más allá de eso, puede considerar dividir la tabla. Esto le permitirá dividir la tabla en varios grupos lógicos. Puede hacerlo "detrás de escena", por lo que aún aparece en el servidor sql como una tabla aunque se haya almacenado por separado, o puede hacerlo manualmente (cree una nueva tabla 'archive' o anual y mueva manualmente las filas) . De cualquier manera, solo hazlo después de primero miraste las otras opciones, porque si no lo haces bien, terminarás teniendo que verificar cada partición. Además: partición hacerequire Enterprise Edition, por lo que es otra razón para guardar esto como último recurso.

Answer 5

En sí mismo, 77M registros no es mucho para SQL Server. ¿Cómo estás cargando los 100.000 registros? ¿Es eso una carga por lotes cada día? o a través de algún tipo de aplicación OLTP? ¿y ese es el problema de rendimiento que está teniendo, es decir, agregar los datos? ¿O es la consulta la que te da más problemas?

Si está agregando 100K registros a la vez, y los registros que se están agregando obligan al índice de clúster a reorganizar su tabla, eso matará su rendimiento rápidamente. Más detalles sobre la estructura de la tabla, los índices y el tipo de datos insertados ayudarán.

Además, la cantidad de ram y la velocidad de sus discos harán una gran diferencia, ¿en qué se ejecutan?

Answer 6

¿Qué tipo de discos tiene?

Puede controlar algunos contadores de disco para ver si las solicitudes están en cola.

Puede mover esta tabla a otra unidad colocándola en otro grupo de archivos. También puede hacer lo mismo con los índices.

Answer 7

¿Realmente necesita tener acceso a los 77 millones de registros en una sola tabla?

Por ejemplo, si solo necesita acceder a los últimos X meses de datos, entonces podría considerar crear una estrategia de archivo. Esto podría usarse para reubicar datos en una tabla de archivo para reducir el volumen de datos y, posteriormente, el tiempo de consulta en su tabla 'hot'.

Este enfoque podría implementarse en la edición estándar.

Si actualiza a la edición Enterprise, puede hacer uso de la partición de la tabla. De nuevo, dependiendo de su estructura de datos, esto puede ofrecer importantes mejoras de rendimiento. El particionamiento también se puede utilizar para implementar la estrategia mencionada anteriormente pero con menos gastos administrativos.

Aquí es un excelente Libro Blanco sobre la partición de tablas en SQL Server 2005

http://msdn.microsoft.com/en-us/library/ms345146.aspx

Espero que lo que he detallado es clara y comprensible. Por favor, siéntase en contacto conmigo directamente si necesita más ayuda.

Saludos,

Answer 8

Inicialmente quería estar de acuerdo con Marc. El ancho de su índice agrupado parece sospechoso, ya que esencialmente se utilizará como la clave para realizar búsquedas en todos sus registros. Cuanto más amplio es el índice agrupado, más lento es el acceso, en general. Y un índice agrupado de seis campos se siente realmente sospechoso.

La exclusividad no es necesaria para un índice agrupado. De hecho, los mejores candidatos para los campos que deberían estar en el índice agrupado son los que no son únicos y se utilizan en las uniones.Por ejemplo, en una tabla Persons donde cada Person pertenece a un Group y se une con frecuencia al Persons al Groups, mientras se accede a lotes de personas por grupo, Person.group_id sería un candidato ideal, para este caso de uso particular.

Answer 9

Estoy de acuerdo con Marc y Unkown anteriores ... 6 índices en el índice agrupado es demasiado, 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. Puede saber 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 colocarlo en su lugar organizado ordenado en el disco. Los índices no agrupados no lo son, están soportando 'tablas' de búsqueda. Mis VLDB están dispuestos en el disco (CLUSTERED INDEX) de acuerdo con el 1er punto a continuación.

1. Reducir el índice agrupado a 1 o 2. Las mejores opciones son el campo IDENTIDAD (INT), si tiene uno, o un campo de fecha en la que se añaden los campos de la base de datos, o algún otro campo ese es un tipo natural de cómo se están agregando sus datos a la base de datos. El punto es que intentas mantener esos datos en la parte inferior de la tabla ... o tenerlos distribuidos en el disco de la mejor manera (90% +) de lectura de los registros. Esto hace que no haya ninguna reorganización o que esté tomando un solo golpe para obtener los datos en el lugar correcto para la mejor lectura. Asegúrese de colocar los campos eliminados en índices no agrupados para que no pierda la eficacia de búsqueda. NUNCA he puesto más de 4 campos en mis VLDB. Si tiene campos que se actualizan frecuentemente y están incluidos en su índice agrupado, OUCH, eso reorganizará el registro en el disco y causará una fragmentación COSTOSA.
2. Compruebe el factor de relleno en sus índices. Cuanto mayor sea el número de 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, entonces esto no importará tanto en un índice agrupado. Regla de oro (IMO), 60-70 factor de relleno para escrituras altas, 70-90 para escrituras medianas, y 90-100 para escrituras altas/escrituras bajas. Al soltar su factor de relleno a 70, significará que por cada 100 registros en una página, se escribirán 70 registros, lo que dejará un espacio libre de 30 registros para registros nuevos o reorganizados. Consume más espacio, pero es mejor que tener que desfragmentar todas las noches (vea 4 a continuación)
3. Asegúrese de que las estadísticas existan en la mesa. Si desea barrer la base de datos para crear estadísticas utilizando el "sp_createstats 'indexonly'", entonces SQL Server creará todas las estadísticas en todos los índices que el motor ha acumulado como que requieren estadísticas. No deje de lado el atributo 'indexonly' (solo index), o agregará estadísticas para cada campo, que luego no sería bueno.
4. Compruebe la tabla/índices usando DBCC SHOWCONTIG para ver qué índices se están fragmentando 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 la rapidez (en el tiempo).
5. 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 esta gran tabla sin que sea durante el tiempo de mantenimiento, ya que reducirá las aplicaciones ... especialmente en el ÍNDICE CLUSTER. Has sido advertido. Prueba y prueba esta parte.
6. Utilice los planes de ejecución para ver qué SCANS y FAT PIPES existen y ajuste los índices, luego defragmente y vuelva a escribir los procesos almacenados para deshacerse de esos puntos conflictivos. Si ve un objeto RED en su plan de ejecución, es porque no hay estadísticas en ese campo. Eso es malo. Este paso es más del "arte que de la ciencia".
7. En horas pico, ejecute UPDATE STATISTICS WITH FULLSCAN para proporcionar al motor de consultas la mayor cantidad de información posible sobre la distribución de datos.De lo contrario, realice las ESTADÍSTICAS DE ACTUALIZACIÓN estándar (con escaneo estándar del 10%) en las mesas durante la semana o más a menudo según lo considere oportuno 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 muy largo, pero es extremadamente importante. Solo te doy aquí información mínima, pero te ayudará muchísimo. Hay algunos sentimientos viscerales y observaciones que entran en las estrategias utilizadas por estos puntos que requerirán tiempo y pruebas.

No es necesario ir a la edición Enterprise. Lo hice para obtener las características mencionadas anteriormente con particionamiento. Pero lo hice ESPECIALMENTE para tener capacidades de multithreading mucho mejores con la búsqueda y el DESGRAVE y el mantenimiento en línea ... En la edición Enterprise, es mucho mejor y más amigable con los VLDB. La edición estándar no maneja hacer DBCC INDEXDEFRAG con bases de datos en línea también.

Answer 10

quizás estas son liendres menores, pero .... (1) las bases de datos relacionales no tienen CAMPOS ... tienen COLUMNAS. (2) Las columnas de IDENTIDAD generalmente significan que los datos no están normalizados (o que el diseñador era flojo). Alguna combinación de columnas DEBE ser única (y esas columnas constituyen la clave principal) (3) la indexación en columnas de fecha y hora suele ser una mala idea; CLUSTERING en columnas de fecha y hora también suele ser una mala idea, especialmente una columna de fecha y hora en constante aumento, ya que todas las inserciones compiten por el mismo espacio físico en el disco. La agrupación en columnas de fecha y hora en una tabla de solo lectura donde esa columna es parte de las restricciones de rango suele ser una buena idea (vea cómo las ideas entran en conflicto? Quién dijo que el diseño de db no era un arte ?!)