enorme mesa en la base de datos SQL 2005 necesita un mejor rendimiento!

Question

Estoy trabajando en una aplicación web basada en los datos que utiliza una base de datos SQL 2005 (edición estándar).

Una de las mesas es bastante grande (8 millones + filas grande con cerca de 30 columnas). El tamaño de la tabla, obviamente, afecta al rendimiento de la página web, que es la selección de los elementos de la tabla a través de procedimientos almacenados. La tabla está indexada pero aún así el rendimiento es pobre debido a la gran cantidad de filas de la tabla - esto es parte del problema - la tabla se lee como igualmente actualizada, por lo que no se puede añadir / quitar índices sin hacer una de las operaciones peor.

El objetivo que tengo aquí es aumentar el rendimiento al seleccionar elementos de la tabla. La tabla tiene datos '' actuales y los datos antiguos / apenas tocado. La solución más efectiva que podemos pensar en esta etapa es para separar la tabla en 2, es decir, uno de los elementos antiguos (antes de una fecha determinada, DICE 1 enero de 2005) y uno de los artículos más recientes (igual o antes del 1 de enero de 2005) .

No sabemos de cosas como vistas distribuidas con particiones - pero todas estas funciones requieren Enterprise Edition, que el cliente no va a comprar (y no, lanzando hardware en que no va a suceder tampoco)

.

Answer 1

Siempre se puede liar "partición / DPV del hombre pobre", incluso si no huele como la forma correcta de hacerlo. Esto es sólo una aproximación conceptual amplio:

1. Crea una nueva tabla para los datos del año en curso - la misma estructura, los mismos índices. Ajustar el procedimiento almacenado que escribe en la tabla principal, grande como para escribir en ambas tablas (solo temporalmente). Recomiendo hacer la lógica en el procedimiento almacenado decir si CURRENT_TIMESTAMP> = '[una fecha entera sin tiempo]' - esto hará que sea fácil para rellenar los datos de esta tabla, que es anterior a la modificación del procedimiento que comienza a ingresar allí.

2. Crear un nuevo cuadro por cada año en su historia mediante el uso de SELECT INTO de la mesa principal. Usted puede hacer esto en una base de datos diferente en la misma instancia para evitar la sobrecarga en la base de datos actual. Los datos históricos no va a cambiar Asumo, por lo que en esta otra base de datos que podría incluso hacer que sea de sólo lectura cuando se hace (lo que mejorará considerablemente el rendimiento de lectura).

3. Una vez que tenga una copia de toda la tabla, puede crear vistas que hacen referencia sólo el año en curso, otra vista que hace referencia 2005 para el año en curso (mediante el uso de UNION ALL entre la tabla actual y los de la otra base de datos que son> = 2005), y otro que hace referencia a los tres conjuntos de tablas (los mencionados, y las tablas que son anteriores a 2005). Por supuesto se puede romper esto aún más, pero yo sólo quería mantener el concepto mínima.

4. Cambiar los procedimientos almacenados que se leen los datos a ser "inteligente" - si el intervalo de fechas solicitado caídas dentro del año natural en curso, utilice la vista más pequeña que sólo es local; Si el intervalo de fechas es> = 2,005 continuación, utilizar el segundo punto de vista, de lo contrario utilizar el tercer punto de vista. Puede seguir una lógica similar a los procedimientos almacenados que escriben, si usted está haciendo algo más que la inserción de nuevos datos que son relevantes sólo para el año en curso.

5. En este punto, usted debe ser capaz de detener la inserción en la tabla masiva y, una vez que todo se ha demostrado que estar trabajando, dejarlo caer y recuperar algo de espacio en disco (y con esto quiero decir que libera espacio en el archivo de datos (s) para su reutilización, no realizar una base de datos de contracción -., ya que va a utilizar ese espacio nuevo)

No tengo todos los detalles de su situación, pero por favor seguimiento si tiene preguntas o preocupaciones. He utilizado este enfoque en varios proyectos de migración, incluyendo uno que está pasando en este momento.

Answer 2

  

rendimiento es pobre debido a la gran cantidad de filas de la tabla

8 millones de filas no suena tan loco. ¿Ha comprobado sus planes de consulta?

  

la tabla se lee como igualmente actualizado

¿En realidad actualizando una columna indexada o es igualmente leer y insertada a

  

(y no, lanzando hardware en que no va a suceder tampoco)

Esto es una lástima, porque la memoria RAM es muy barato.

Answer 3

Reconstruir todos los índices. Esto aumentará el rendimiento de las consultas. Cómo hacerlo es este y más en efecto en la reconstrucción del clúster y no índice -clustered aquí

En segundo lugar realizar la desfragmentación de su unidad en la que se almacena la base de datos.