Sensibilidad a mayúsculas y minúsculas al consultar SQL Server 2005 desde .NET con OleDB

Question

Tengo una consulta que estoy ejecutando desde una aplicación .NET a una base de datos de SQL Server y parece que lleva bastante tiempo completarla (más de 5 minutos). Creé una aplicación de prueba en C # para intentar ver lo que estaba hablando tanto tiempo (la consulta debería volver rápidamente).

Como estaba reconstruyendo la consulta agregando elementos para ver qué porción estaba tomando tanto tiempo, terminé reconstruyendo la consulta prácticamente literalmente donde la única diferencia eran los espacios en la consulta original y una diferencia de mayúsculas. Esta diferencia arrojó un resultado en aproximadamente 100 milisegundos.

¿Alguien ha visto esto antes? Me pregunto si hay servicios desactivados en nuestro servidor (ya que un compañero de trabajo tiene el mismo problema) o en nuestras computadoras.

Gracias de antemano por cualquier ayuda con esto.

Ejemplo de código a continuación (La diferencia en la primera línea de la consulta al final (fk_source vs. fk _Source):

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);

Answer 1

Sospecho que este es un problema de caché de procedimientos. Una ventaja de los procedimientos almacenados es que el plan se almacena para usted, lo que acelera las cosas. Desafortunadamente, es posible obtener un mal plan en el caché (incluso cuando se usan consultas dinámicas).

Solo por diversión, verifiqué mi caché de procedimientos, ejecuté una consulta ad hoc, volví a verificar, luego ejecuté la misma consulta con diferente capitlización y me sorprendió ver que el procedimiento contaba más alto.

Prueba esto ...

Conéctese a SQL Server Management Studio.

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

Creo que encontrará que TotalProcs cambia cuando cambia la declaración (incluso cuando el único cambio distingue entre mayúsculas y minúsculas).

Actualizar sus estadísticas puede ayudar. Ese es un proceso de ejecución bastante lento, por lo que es posible que desee ejecutarlo durante un período lento.

Answer 2

Dado que está utilizando SQL Server 2005, ¿ha intentado con un objeto SqlCommand en lugar del objeto OleDbCommand?

Answer 3

No veo una diferencia en sus consultas que afecte el rendimiento: ¿qué pasa con el almacenamiento en caché o los cambios de índice / estadísticas entre ejecuciones? El plan de ejecución puede haber cambiado debido a cambios en las estadísticas o en el índice.

Con respecto al caso: El caso puede importar si la base de datos está configurada para ser sensible a mayúsculas y minúsculas, pero para que ambas consultas se ejecuten en una base de datos sensible a mayúsculas y minúsculas, debería haber columnas con nombres en ambos formatos; el analizador de consultas obedecerá el caso: no causará una diferencia de rendimiento.

Answer 4

en primer lugar, ¿estás 100% seguro de que es la consulta la que sale mal? Compruebe el perfil de rastreo en el servidor sql para ver cuánto tiempo tarda en la base de datos.

En segundo lugar, está obteniendo el mismo número de resultados. La capitalización no debería importar por defecto en el servidor sql, pero podría haberse configurado de manera diferente.

Answer 5

Si tuviera una consulta que diera '' 5+ minutos '', no estaría preocupado por los 100 milisegundos que se necesitan para hacer coincidir el caso de la cadena.

Answer 6

gracias por todas sus respuestas, responderé a cada una a su vez:

1) Russ, estoy de acuerdo en que SQLConnection sería mejor, pero desafortunadamente no puedo configurar el tipo de conexión. Acabo de crear una pequeña aplicación para probar esta consulta, pero la consulta se crea dinámicamente en una aplicación mucho más grande.

2) gbjbaanb, creo que no es un problema del servidor, porque puedo ejecutar ambas consultas desde el estudio de administración aproximadamente al mismo tiempo, solo parece ser un problema cuando se ejecuta a través de Oledb en .net (1.1 y 2.0) . Hemos ejecutado un generador de perfiles en él y el archivo de seguimiento confirmó que tomó más de 5 minutos completar la consulta cuando se llamó de esta manera.

3) Joel Coehoorn, de acuerdo, pero realmente lo que estoy tratando de obtener aquí es "por qué" porque en este momento no sabemos qué tan grande es este problema y dónde está.

4) Cade Roux, la diferencia es muy reproducible, por lo que no creo que sea un problema con los cambios de índice o el almacenamiento en caché, ya que he ejecutado las pruebas de forma consecutiva con los mismos resultados y que toman aproximadamente el mismo tiempo en SQL Server para ejecutar.

Answer 7

Gracias a G Mastros por la respuesta más completa, aunque en retrospectiva Cade sugirió la actualización de las estadísticas. Sin embargo, la solución de G Mastos se adaptaba mejor a mi nivel de experiencia en SQL Server.

¡Gracias por ayudar a todos!

Voy a investigar por qué esta diferencia aparentemente inocente tiene consecuencias tan grandes