Connexion JDBC à SQL 2000 très occupé: selectMethod = cursor vs selectMethod = direct?

Question

En essayant d'aider une équipe de développement d'applications avec des problèmes de performances sur un serveur SQL 2000 (à partir d'applications Java sur des serveurs d'applications distincts), j'ai exécuté une trace SQL et découvert que tous les appels étaient complets des instructions API Server Cursor (sp_cursorprepexec, sp_cursorfetch, sp_cursorclose).

On dirait qu'ils sont en spécifiant des propriétés de chaîne de connexion qui force l'utilisation de curseurs côté serveur, la récupération seulement 128 lignes de données à la fois: (De http://msdn.microsoft.com/en-us/library/Aa172588)

Lorsque les attributs curseur API ou propriétés sont définies à tout autre que leurs valeurs par défaut, le fournisseur OLE DB pour SQL Server et SQL API utilisation du pilote ODBC serveur serveur curseurs au lieu de résultat par défaut ensembles. Chaque appel à une fonction API qui récupère des lignes génère un aller-retour vers le serveur pour extraire les lignes du curseur du serveur API.

MISE À JOUR: La chaîne de connexion en cause est un paramètre de chaîne de connexion JDBC, selectMethod=cursor (qui permet aux curseurs côté serveur nous ci-dessus) contre la selectMethod=direct alternative. Ils utilisent selectMethod=cursor comme chaîne de connexion standard pour toutes les applications. Du point de vue de ma DBA, c'est juste ennuyeux (ça encombre la trace avec des ordures inutiles), et (je devrais spéculer) se traduit par de nombreux allers-retours de serveur app-to-SQL, réduisant les performances globales.

Ils ont apparemment testé le changement (juste l'un des 60 connexions d'applications différentes) à selectMethod=direct mais ont connu quelques problèmes (dont je n'ai pas de détails) et sont préoccupés par la rupture de l'application.

Alors, mes questions sont les suivantes:

• peut en utilisant les performances des applications moins selectMethod=cursor, comme je l'ai tenté de faire valoir? (en augmentant le nombre d'allers-retours nécessaires sur un serveur SQL qui a déjà des requêtes très élevées/s)
• selectMethod= est-il un paramètre transparent à l'application sur une connexion JDBC? Cela pourrait-il casser leur application si nous la changeons? En général, quand utiliser cursor par rapport à direct?

Egalement cross-posted to SF.

EDIT: a reçu des détails techniques qui justifient une modification significative du titre, de la question et des balises.

EDIT: Ajout de la prime. Ajout de la prime à la question de SF (cette question est centrée sur le comportement de l'application, la question SF est axée sur la performance SQL.) Merci !!

Answer 1

En bref,

1. selectMethod=cursor
   • nécessite théoriquement more server-side resources que selectMethod=direct
   • que les charges à la plupart lots de taille enregistrements dans la mémoire du client à la fois, entraînant une empreinte mémoire client plus prévisible
2. selectMethod=direct
   • nécessite théoriquement moins de ressources côté serveur que selectMethod=cursor
   • lira tout le résultat mis en mémoire du client (à moins que le pilote prend en charge nativement la récupération de jeu de résultats asynchrone) avant l'application cliente peut itérer dessus; ce peut réduire les performances de deux façons:
     1. performances réduites avec de grands résultats si l'application cliente est écrit de telle manière à arrêter le traitement après avoir traversé seulement une fraction de l'ensemble des résultats (avec direct il a déjà le cursorcursor les déchets sont limités au maximum à par lots - 1 rangées - la condition de terminaison anticipée devrait probablement être recodée dans SQL de toute façon, par exemple comme ou les fonctions de fenêtre)
     2. performances réduites avec de grands ensembles de résultats en raison de la possibilité de collecte des ordures et/ou questions ut-de-mémoire associée à une empreinte mémoire accrue

En résumé,

• peut à l'aide de la performance des applications plus faible selectMethod=cursor? - l'une ou l'autre méthode peut réduire les performances, pour différentes raisons. Passé une certaine taille de jeu de résultats, cursor peut encore être préférable. Voir ci-dessous pour savoir quand utiliser l'un ou l'autre
• Est-ce que selectMethod= est un paramètre transparent à l'application sur une connexion JDBC? - il est transparent, mais il peut encore briser leur application si l'utilisation de la mémoire augmente suffisamment pour monopoliser leur système client (et, par conséquent, votre serveur)
• Plus généralement, quand devez-vous utiliser cursor vs direct? - J'utilise personnellement cursor lorsque je traite des ensembles de résultats potentiellement volumineux ou non bornés. Le surcoût de l'aller-retour est ensuite amorti en fonction d'une taille de lot suffisamment importante, et l'empreinte mémoire de ma clientèle est prévisible. J'utilise direct lorsque la taille du jeu de résultats que j'attends est connue pour être inférieure à la taille de lot que j'utilise avec cursor, ou lié d'une certaine façon, ou lorsque la mémoire n'est pas un problème.

Answer 2

L'utilisation selectMethod=cursor empêche SQL Server d'utiliser Parallel Query Processing, qui peut avoir un impact sur les performances, par exemple lorsque: (et qui n'a pas)

• vous avez beaucoup de cœurs de processeurs
• vous ont optimisé votre base de données par des tables de partitionnement
• vous utilisez beaucoup de requêtes globales (sum(), count(), etc.)

Enfin, Microsoft states les éléments suivants:

(selectMethod=direct) fournit les meilleures performances lorsque l'application est en train de traiter toutes les lignes.

Vous devriez vraiment essayer de voir si le réglage de selectMethod = direct fait une différence pour vous.