connexion JDBC à SQL très occupé 2000: selectMethod = curseur vs selectMethod = directe?

Question

Dans le processus d'essayer d'aider une équipe application de dev avec les problèmes de performances sur un serveur SQL 2000 (à partir d'un tas d'applications Java sur des serveurs d'applications séparés), j'ai couru une trace SQL et a découvert que tous les appels à la base de données sont complet d'états API serveur curseur (sp_cursorprepexec, sp_cursorfetch, sp_cursorclose).

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

  

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

UPDATE : 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 que leur chaîne de connexion standard à partir de toutes les applications.

De mon point de vue DBA, qui est tout simplement ennuyeux (il encombre la trace avec indésirable inutile), et (je spéculer) entraîne dans de nombreux serveurs app-à-SQL supplémentaires allers-retours, ce qui réduit la performance globale.

Ils ont apparemment fait changer essai (juste un des 60 différentes connexions app) à selectMethod=direct mais certaines questions (connu dont je n'ai pas de détails) et sont préoccupés par la rupture de l'application.

Alors, mes questions sont:

• Can en utilisant les performances des applications à moindre 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 haute / sec)
• est selectMethod= un cadre transparent application sur une connexion JDBC? Cela pourrait-il briser leur application si nous le changer?
• Plus généralement, quand utiliser cursor vs direct?

permuté à SF .

EDIT :. Détails techniques réels reçus qui justifient une modification importante au titre, question et balises

EDIT : prime Ajouté. On a aussi ajouté prime à la question SF (cette question se concentre sur le comportement de l'application, la question SF se concentre sur les performances SQL.) Merci !!

Answer 1

En bref,

1. selectMethod=cursor
   • nécessite théoriquement plus de ressources côté serveur que selectMethod=direct
   • charges seulement au plus taille des lots enregistrements dans la mémoire du client à la fois, entraînant une empreinte mémoire du client plus prévisible
2. selectMethod=direct
   • nécessite théoriquement moins de ressources côté serveur que selectMethod=cursor
   • va lire l'ensemble de résultat dans la 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 en manière telle que le traitement d'arrêt après avoir traversé seulement une fraction de l'ensemble des résultats (avec direct il a déjà payé le coût de la récupération de données, il sera essentiellement deux pas; avec cursor les déchets est limitée au maximum taille des lots - 1 rangs - la condition de résiliation anticipée devrait probablement être recodées dans SQL de toute façon, par exemple en tant que fonctions SELECT TOP ou fenêtre)
     2. performances réduites avec de grands ensembles de résultats en raison de la collecte des déchets potentiels et / ou hors de la mémoire questions liées à une empreinte mémoire accrue

En résumé,

• Can en utilisant les performances des applications à moindre selectMethod=cursor - ou l'autre méthode peut réduire les performances, pour des raisons différentes. Passé une certaine taille resultset, cursor peut encore être préférable. Voir ci-dessous pour le moment d'utiliser l'un ou l'autre
• selectMethod= un cadre transparent application sur une connexion JDBC - il est transparent, mais il peut encore briser leur application si l'utilisation de la mémoire se développe suffisamment pour porcs leur système client (et, en conséquence , votre serveur) ou planter le client tout à fait
• Plus généralement, quand utiliser cursor vs direct - J'utilise personnellement cursor lorsqu'ils traitent avec des résultats potentiellement importants ou autrement sans bornes ensembles. Les frais généraux aller-retour est ensuite amorti donné une assez grande taille du lot, et mon empreinte mémoire client est prévisible. J'utilise direct lorsque la taille du jeu de résultats que je pense est connu pour être inférieure à ce que la taille du lot que j'utilise avec cursor, ou lié d'une certaine façon, ou lorsque la mémoire est pas un problème.

Answer 2

Utilisation selectMethod=cursor empêche SQL Server d'utiliser traitement parallèle de requête , qui peut avoir un impact sur les performances, par exemple lorsque:

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

Enfin, Microsoft précise ce qui suit:

  

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

Vous devriez certainement essayer de voir si le réglage selectMethod = marques directes une différence pour vous.