2010-12-01 82 views
5

Me encuentro con un problema al completar un conjunto de registros ADO en VB6. La consulta (al llegar a SQLServer 2008) solo tarda aproximadamente 1 segundo en ejecutarse cuando la ejecuto usando SSMS. Funciona bien cuando el conjunto de resultados es pequeño, pero cuando llega a ser unos cientos de registros, lleva mucho tiempo. Más de 800 registros requieren aproximadamente 5 minutos para regresar (la consulta todavía demora 1 segundo en SSMS), y más de 6000 tarda más de 20 minutos. He "corregido" la excepción aumentando el tiempo de espera del comando, pero me preguntaba si había una forma de hacerlo funcionar más rápido, ya que no parece ser la consulta real que requiere tanto tiempo. Algo así como comprimir los resultados para que no tome tanto tiempo. El conjunto de registros se abre de la siguiente manera:Resolviendo un problema de tiempo de espera de ADO en VB6

myConnection.CommandTimeout = 2000 
myConnection.ConnectionString = "Provider=SQLOLEDB;" & _ 
     "Initial Catalog=DB_NAME;" & _ 
     "Data Source=SERVER_NAME" & _ 
     "Network Library=DBMSSOCN;" & _ 
     "User ID=USER_NAME;" & _ 
     "Password=PASSWORD;" & _ 
     "Use Encryption for Data=True;" 
myConnection.Open 

myRecordSet.Open STORED_PROC_QUERY_STRING, myConnection, adOpenStatic, adLockReadOnly 
Set myRecordSet.ActiveConnection = Nothing 

myConnection.Close 

Los datos devuelven 3 columnas utilizadas para llenar un cuadro combinado.

ACTUALIZACIÓN: Ejecuté el Analizador de SQL, y las instancias de la máquina cliente hacen más lecturas y toman más tiempo por un factor de 100 que ambas métricas para las consultas en SSMS. El texto de la consulta es el mismo tanto para SSMS como para la máquina cliente de acuerdo con el generador de perfiles, por lo que no creo que deba usarse un plan de ejecución diferente. ¿Podría la biblioteca de red o el proveedor tener algún impacto sobre esto?

estadísticas Profiler:

  • A partir de la aplicación de cliente: 7041720 lee, duración 59458 ms, 3900 fila conteos
  • De SSMS: 30802 lee, 238 ms duración, 3900 fila cuenta

Parece que está utilizando un plan de ejecución diferente, pero la consulta es exactamente la misma y no estoy seguro de cómo verificar el plan de ejecución que el cliente podría estar utilizando si es diferente. om lo que se muestra en SSMS.

+0

¿Has probado eliminar el "Usar cifrado para datos"? – Andomar

+0

No, pero esa no es realmente una opción disponible. Esta es una aplicación de cliente. –

+1

Ha intentado perfilar las llamadas y [mirando los planes de ejecución] (http://stackoverflow.com/questions/3831644/why-does-a-database-query-only-go-slow-in-the-application/ 3831685 # 3831685) para verificar que esto definitivamente no es un problema de olfateo de parámetros –

Respuesta

3

800+ records requires about 5 minutes = problema de consulta.

vistazo a su plan de ejecución:

En SSMS, ejecute:

SET SHOWPLAN_ALL ON

continuación, ejecute la consulta, no producirá el conjunto de resultados se esperaba, sino un plan de exceution sobre cómo la base de datos está recuperando tus datos La mayoría de las consultas erróneas suelen escanear tablas (ver todas las filas de la tabla, que es lenta), así que busque la palabra "ESCANEADO" en la columna StmtText. Trate de descubrir por qué el índice no se está utilizando en esa tabla (el nombre estará ahí con la palabra "ESCANEAR"). Si se une a múltiples tablas y tiene múltiples SCAN, concéntrese primero en las tablas más grandes.

Sin más información esta es la mejor ayuda "genérica" ​​que puede obtener.

EDITAR
De la lectura de su pregunta, no estoy seguro de si usted quiere decir que siempre es rápido de SSMS sin importar las filas, pero lento de VB a medida que aumentan las filas.Si ese es el caso, mira esto: http://www.google.com/search?q=sql+server+fast+from+ssms+slow+from+application&hl=en&num=100&lr=&ft=i&cr=&safe=images

podría ser algo como: descubrimiento de parámetros o parámetros de conexión inconsistentes (valores nulos ANSI, arithabort, etc)

para la configuración de conexión, intente ejecutar estos de SSMS y desde VB6 (añadirlos al conjunto de resultados) y ver si hay algunas diferencias:

SELECT SESSIONPROPERTY ('ANSI_NULLS') --Specifies whether the SQL-92 compliant behavior of equals (=) and not equal to (<>) against null values is applied. 
             --1 = ON 
             --0 = OFF 

SELECT SESSIONPROPERTY ('ANSI_PADDING') --Controls the way the column stores values shorter than the defined size of the column, and the way the column stores values that have trailing blanks in character and binary data. 
             --1 = ON 
             --0 = OFF 

SELECT SESSIONPROPERTY ('ANSI_WARNINGS') --Specifies whether the SQL-92 standard behavior of raising error messages or warnings for certain conditions, including divide-by-zero and arithmetic overflow, is applied. 
             --1 = ON 
             --0 = OFF 

SELECT SESSIONPROPERTY ('ARITHABORT') -- Determines whether a query is ended when an overflow or a divide-by-zero error occurs during query execution. 
             --1 = ON 
             --0 = OFF 

SELECT SESSIONPROPERTY ('CONCAT_NULL_YIELDS_NULL') --Controls whether concatenation results are treated as null or empty string values. 
                --1 = ON 
                --0 = OFF 

SELECT SESSIONPROPERTY ('NUMERIC_ROUNDABORT') --Specifies whether error messages and warnings are generated when rounding in an expression causes a loss of precision. 
               --1 = ON 
               --0 = OFF 

SELECT SESSIONPROPERTY ('QUOTED_IDENTIFIER') --Specifies whether SQL-92 rules about how to use quotation marks to delimit identifiers and literal strings are to be followed. 
              --1 = ON 
              --0 = OFF 

hacer su consulta como (por lo que se puede ver la configuración de conexión en Visual Basic 6):

SELECT 
    col1, col2 
     ,SESSIONPROPERTY ('ARITHABORT') AS ARITHABORT 
     ,SESSIONPROPERTY ('ANSI_WARNINGS') AS ANSI_WARNINGS 
    FROM ... 
+0

Según la publicación original, la consulta se ejecuta en menos de un segundo en SSMS. El texto de la consulta es exactamente el mismo (confirmado con el Analizador de SQL). He visto el plan de ejecución, y se ve bien. Todos los índices están siendo utilizados. –

+0

Realmente vale la pena comparar las propiedades de sesión anteriores, ya que pueden afectar el rendimiento, al menos probar la consulta ADO después de emitir un SET ARITHABORT EN –

+0

Era la propiedad arithabort. Gracias por la ayuda. –

Cuestiones relacionadas