conexión JDBC a muy ocupado SQL 2000: SelectMethod = cursor vs = SelectMethod directa?

Question

En el proceso de tratar de ayudar a un equipo de aplicación dev con problemas de rendimiento en el servidor SQL 2000 (de un montón de aplicaciones Java en servidores de aplicaciones separadas), me encontré con una traza SQL y descubrió que todas las llamadas a la base de datos son llena de declaraciones de API de servidor cursor (sp_cursorprepexec, sp_cursorfetch, sp_cursorclose).

Parece que están especificando algunas propiedades de cadena de conexión que fuerza el uso de cursores de servidor, recuperar sólo 128 filas de datos a la vez: (A partir de http://msdn.microsoft.com/en-us/library/Aa172588 )

  

Cuando los atributos de cursor o API   propiedades se establecen en otro valor   que sus valores predeterminados, el OLE DB   proveedor para SQL Server y SQL   Servidor de ODBC utilización controlador de servidor API   cursores en lugar de resultado por defecto   conjuntos. Cada llamada a una función API   que captan filas genera una   ida y vuelta al servidor para buscar el   filas desde el cursor de servidor API.

Actualizar : La cadena de conexión en cuestión es un parámetro de cadena de conexión JDBC, selectMethod=cursor (que permite a los cursores de servidor que se discutió anteriormente) vs el selectMethod=direct alternativa. Ellos han estado utilizando selectMethod=cursor como su cadena de conexión estándar a partir de todas las aplicaciones.

Desde mi perspectiva DBA, que es sólo una molestia (que estorba la traza arriba de chatarra inútil), y (me gustaría especular) se traduce en muchos viajes ida y vuelta adicional de servidor-app-a SQL, lo que reduce el rendimiento general.

Al parecer, hicieron pruebas cambiando (solo uno de los 60 diferentes conexiones de aplicaciones) para selectMethod=direct pero experimentaron algunos problemas (de los cuales no tengo más detalles) y están preocupados por la ruptura de la aplicación.

Por lo tanto, mis preguntas son:

• Can usando rendimiento de las aplicaciones más baja selectMethod=cursor, como he tratado de argumentar? (Aumentando el número de idas y vueltas necesarias en el servidor SQL que ya tiene una consultas muy alta / seg)
• ¿Es selectMethod= un entorno aplicación transparente sobre una conexión JDBC? Podría esto romper su aplicación, si lo cambiamos?
• En términos más generales, cuando se debe utilizar cursor vs direct?

-cruz publicado a SF .

Editar :. Recibidas detalles técnicos reales que justifican una edición significativa de títulos, preguntas, y las etiquetas

Editar : Añadido recompensa. También se ha añadido la generosidad a la pregunta SF (esta pregunta se centra en el comportamiento de la aplicación, la cuestión SF se centra en el rendimiento de SQL.) Gracias !!

Answer 1

Brevemente,

1. selectMethod=cursor
   • más recursos de servidor de selectMethod=direct
   • sólo cargas en la mayoría de lote de tamaño registros en la memoria del cliente a la vez, lo que resulta en una memoria cliente más predecible huella
2. selectMethod=direct
   • requiere teóricamente menos recursos del lado del servidor que selectMethod=cursor
   • leerá todo el conjunto de resultados en la memoria del cliente (a menos que el conductor soporta de forma nativa recuperación conjunto de resultados asíncrono) antes de la aplicación cliente puede iterar sobre ella; este puede reducir el rendimiento de dos maneras: :
     1. reducción del rendimiento con grandes conjuntos de resultados si la aplicación cliente está escrito de tal manera como para el procesamiento de parada después de atravesar sólo una fracción del conjunto de resultados (con direct que ya ha pagado el costo de la recuperación de datos que, esencialmente, se tire; cursor con los desechos está limitado a un máximo de lotes de tamaño - 1 filas - la condición de terminación temprana probablemente debería ser recodificados en SQL de todas formas por ejemplo, como SELECT TOP o ventana de funciones)
     2. disminución del rendimiento con grandes conjuntos de resultados a causa de la recaudación potencial de basura y / o fuera de la memoria problemas asociados con un mayor consumo de memoria

En resumen,

• Can usando selectMethod=cursor menor rendimiento de las aplicaciones -? Cualquiera de estos métodos puede reducir su rendimiento, por diferentes razones. Pasado un cierto tamaño de resultados, cursor todavía puede ser preferible. Véase más abajo para cuándo utilizar uno u otro
• es selectMethod= un entorno aplicación transparente sobre una conexión JDBC ? - es transparente, pero todavía puede romper su aplicación en caso de uso de la memoria crece significativamente suficiente para acaparar su sistema cliente (y, correspondientemente , el servidor) o bloquearse por completo el cliente
• En términos más generales, cuando se debe utilizar cursor vs direct -? Yo personalmente uso cursor cuando se trata de potencialmente grandes o de otra manera sin límites conjuntos de resultados. La sobrecarga de ida y vuelta se amortiza da un tamaño de lote bastante grande, y mi huella de la memoria del cliente es predecible. Yo uso direct cuando el tamaño del conjunto de resultados que espero se sabe que es inferior a lo que sea el tamaño del lote que utilizo con cursor, o unido de alguna manera, o cuando la memoria no es un problema.

Answer 2

El uso de selectMethod=cursor impide que SQL Server utilizando procesamiento de consultas en paralelo, lo que puede tener un gran impacto en el rendimiento, por ejemplo, cuando:

• tiene muchos núcleos de CPU (y quién no?)
• que ha optimizado su base de datos de las tablas de partición
• está ejecutando una gran cantidad de consultas de agregado (sum(), count(), etc.)

Por último, Microsoft estados lo siguiente:

  

( selectMethod=direct ) proporciona el rendimiento más rápido cuando la aplicación está procesando todas las filas.

sin duda debe probar y ver si la configuración SelectMethod = marcas directos una diferencia para usted.