Cómo mejorar el rendimiento en la tabla de SQL Server con campos de imagen?

Question

Estoy teniendo un problema de rendimiento muy particular en el trabajo!

En el sistema que estamos utilizando no hay una tabla que contiene información sobre el proceso de flujo de trabajo actual. Uno de los campos sostiene una hoja de cálculo que contiene metadatos sobre el proceso (no me pregunte por qué !! Y no, yo no puedo cambiarlo !!)

El problema es que esta hoja de cálculo se almacena en un campo de imagen en un servidor SQL Server 2005 (dentro de una base de datos creada con la compatibilidad de SQL 2000).

Esta tabla tiene actualmente 22K + líneas e incluso una simple consulta como esta:

SELECT TOP 100 *
  FROM OFFENDING_TABLE

tarda 30 segundos para recuperar los datos en el Analizador de consultas.

Estoy pensando en actualizar la compatibilidad con SQL 2005 (una vez que se me informó que la aplicación puede manejarlo).

La segunda cosa que estoy pensando es cambiar el tipo de datos de la columna a varbinary(max) pero no sé si al hacer esto afectará a la aplicación.

Otra cosa que estoy considerando es usar sp_tableoption para establecer el large value types out of row a 1 ya que es actualmente 0, pero no tengo ninguna información si hacer esto mejorará el rendimiento.

¿Alguien sabe cómo mejorar el rendimiento de tal escenario?

---

Editado para aclarar

Mi problema es que no tengo ningún control sobre lo que la aplicación solicita al servidor SQL Server, y lo hice alguna reflexión sobre ella (la aplicación es una página web .NET 1.1) y utiliza el campo ofensivo para algunas cosas internas que no tienen idea de lo que es.

Necesito mejorar el rendimiento general de esta tabla.

Answer 1

Me gustaría recomendar que mira en el diseño de la mesa de salud infractor:

select * from sys.dm_db_index_physical_stats(
       db_id(), object_id('offending_table'), null, null, detailed);

Las cosas también buscar son avg_fragmentation_in_percent, page_count, avg_page_space_used_in_percent, record_count y ghost_record_count. Como señales de alta fragmentación, o un alto número de registros fantasma, o un porcentaje bajo de página utilizada indican problemas y las cosas se pueden mejorar un poco con sólo la reconstrucción del índice (es decir la tabla.) A partir de cero:

ALTER INDEX ALL ON offending_table REBUILD;

Yo digo esto teniendo en cuenta que no se puede cambiar la tabla ni la aplicación. Si usted sería capaz de cambiar la mesa y la aplicación, los consejos que ya tiene es un buen consejo (no usar '*', 'No seleccione w / OA condición, utilice la nueva varbinary (max) tipo, etc, etc) .

También me miro en el tiempo de vida media página en los contadores de rendimiento de entender si el sistema es la memoria de hambre. Desde su descripción de los symptomps el sistema se ve obligado IO que me lleva a que hay poca caché de la página pasando, y más memoria RAM podría ayudar, así como un subsistema IO más rápido. En un sistema SQL 2008 Me gustaría también sugieren girando la compresión de página, pero en 2005 no se puede.
Y, sólo para estar seguro, asegúrese de que las consultas no son bloqueados por la contención de la aplicación en sí, es decir. la consulta no gasta el 90% de esos 30 segundos de espera para un bloqueo de registro. Mira sys.dm_exec_requests mientras se ejecuta la consulta, consulte la wait_time , wait_type y wait_resource. ¿Es PAGEIOLATCH_XX? O se trata de una cerradura? Además, ¿cómo es el sys.dm_os_wait_stats en su servidor, lo que son las razones arriba esperar?

Answer 2

En primer lugar - no hacer nunca un SELECT * en el código de producción - informar o no.

Usted tiene tres opciones básicas:

• mover ese campo masa amorfa fuera en una tabla separada si es que no siempre es necesario; Probablemente no es práctico ya que mencionas no se puede cambiar el esquema

• ser más cuidadoso con sus declaraciones SELECT para seleccionar sólo aquellos campos que realmente necesita - y omitir el campo blob

• ver si se puede limitar su consulta para incluir una cláusula WHERE y encontrar una manera de optimizar el plan de consulta por ejemplo la adición de un índice adecuado a la mesa (si puede)

No hay magia "hacer esto más rápido" interruptor - pero se puede optimizar su consulta o optimizar su diseño de la mesa. Ambos ayuda. Si no puede cambiar nada - ni el diseño de la mesa, ni añadir un índice, ni cambiar las consultas, tendrá dificultades para la optimización de nada, me temo ....

Simplemente cambiar el campo para varbinary (max) no cambiará nada en absoluto -. Ninguna mejora en el rendimiento que se espera sólo de cambiar el tipo de datos

Answer 3

Una respuesta corta es hacer sólo selecciona contra varias filas cuando los campos mostrados no incluyen el campo de imagen infractor, es decir, sin SELECT *. Si desea que el valor del campo de imagen, recuperarlo en una base de caso por caso.

Answer 4

Configuración de los tipos de valores grandes de opción fila definitivamente debe mejorar el rendimiento. El tamaño de fila será significativamente más pequeño, SQL Server puede hacer mucho menos lecturas físicas para obtener throught la tabla.