Mejores prácticas para diseñar tablas para admitir la actualización de un campo más rápido utilizando el servidor sql

Question

Estoy trabajando en un sistema de flujo de trabajo. Tengo una tabla de tareas y un campo de estado. El valor para el estado puede ser uno de Nuevo, listo, procesando, error, aborto, hecho.

Tengo aproximadamente 7 procesos que se desencadenarán en función de una situación diferente para cambiar el valor del estado de la tarea. La mayoría del tiempo cada proceso funcionará en su propio conjunto de datos y cada vez solo procesa hasta 5000 registros. Pero aún veo un punto muerto si los datos llegan a alrededor de 2 millones de registros. Verifico con SQL Profiler, parece que está relacionado con algún recurso de la página. No soy bueno en el ajuste de rendimiento del servidor sql y no lo entiendo muy bien.

Dado que la tarea inactiva se archivará todos los días, estoy pensando en rediseñar la tabla para admitir alrededor de 10 millones de registros.

pocos elección puede ser:

1. Crear tablas divididas basadas en el estado.
2. Crear una tabla maestra con datos estáticos y mesa apoyada en base al estado

¿Hay alguna buena práctica para este tipo de situación?

Gracias!

Answer 1

• Puede dividir la tabla en función de la columna de estado. Registros activos en una parición. Registros cerrados en otra parición
• Mensualmente también puede borrar los registros cerrados (Eliminar si ya no es necesario) o pasar a la Tabla de archivos
• Tabla dividida No creo que sea una mejor opción (No necesita tablas multivelo para la misma funcionalidad)
• Para evitar un punto muerto, ¿Qué versión de SQL Server está usando?
• Si está utilizando SQL 2005 y superior Utilice Read Committed Snapshot Isolation para leer datos confirmados. Esto aseguraría que lee no bloquear escribe

Answer 2

Sé que debería a publicar una respuesta, pero con estas preguntas las respuestas pueden seguir:

1.) ¿Son las sugerencias de tabla en su lugar? Si no, entonces experimente aplicando esos

2.) ¿Se utilizan todos los índices disponibles, y es la columna TaskId el único índice aceptable? Algunas veces, ciertas situaciones, cuando se analizan, generarán la necesidad de un nuevo índice

3.) ¿Están activos o activos los 2 millones de registros en un momento determinado?

4.) ¿Ha comprobado si hay índices fragmentados? archivado diaria puede causar la fragmentación del índice, por lo que es posible que desee añadir al final de su trabajo archivado un paso para comprobar y corregir la fragmentación

5.) campos de estado de new, ready, processing, error, abort, done es bajo ¿qué tipo de datos?

6.) ¿Ha experimentado con vistas indizadas?Si ya sabe que está limitando ciertos datos y desea evitar los escaneos de tablas, podría ayudar