À propos de la sélection d'un type de curseur
La sélection d'un type de curseur dépend de plusieurs variables, à savoir :
- taille de l'ensemble de résultats ;
- pourcentage des données susceptibles d'être nécessaires ;
- performances du curseur ouvert ;
- besoin d'opérations de curseur, telles que le défilement ou les mises à jour positionnées ;
- niveau de visibilité sur les modifications des données effectuées par d'autres utilisateurs.
Les valeurs par défaut conviennent à un petit ensemble de résultats si aucune mise à jour n'est effectuée. Il est cependant préférable d'utiliser un curseur dynamique dans le cas d'un ensemble de résultats conséquent, dans lequel l'utilisateur peut trouver une réponse avant de devoir extraire un grand nombre de lignes.
Si les données à récupérer doivent toutes être consommées dans leur ensemble et les mises à jour ou le défilement positionné ne sont pas nécessaires, les ensembles de résultats par défaut sont recommandés. Microsoft SQL Server 2005 supprime la restriction qui empêchait d'avoir plus d'un ensemble de résultats par défaut en attente lors de l'utilisation de MARS (Multiple Active Result Sets).
Règles de sélection d'un type de curseur
Règles simples à suivre lors de la sélection d'un type de curseur :
- Utiliser autant que possible des ensembles de résultats par défaut. Si le défilement est nécessaire, il peut être plus efficace de mettre en mémoire cache un petit ensemble de résultats sur le client et de parcourir la mémoire cache que de demander au serveur d'implémenter un curseur.
- Utilisez les valeurs par défaut lorsque vous extrayez la totalité d'un ensemble de résultats et que vous le placez chez un client, par exemple lors de la génération d'un rapport. Les ensembles de résultats par défaut constituent la méthode la plus rapide de transmission de données au client.
- Vous ne pouvez pas recourir aux ensembles de résultats par défaut si l'application utilise les mises à jour positionnées.
- Les ensembles de résultats par défaut doivent être utilisés pour les instructions ou lots d'instructions Transact-SQL produisant plusieurs ensembles de résultats.
- Les curseurs dynamiques s'ouvrent plus rapidement que les curseurs statiques ou pilotés par jeux de clés. Les tables de travail temporaires internes doivent être créées au moment de l'ouverture des curseurs statiques et pilotés par jeux de clés, mais ne sont pas obligatoires pour les curseurs dynamiques.
- Dans les jointures, les curseurs statiques et pilotés par jeux de clés peuvent être plus rapides que les curseurs dynamiques.
- Vous devez utiliser des curseurs statiques ou pilotés par jeux de clés si vous voulez effectuer des extractions absolues.
- Les curseurs statiques et pilotés par jeux de clés augmentent l'utilisation de la base de données tempdb. Les curseurs de serveur statiques créent la totalité du curseur dans tempdb ; les curseurs pilotés par jeux de clés créent ce jeu dans tempdb.
- Si un curseur doit rester ouvert pendant une opération de restauration, utilisez un curseur statique synchrone et affectez à CURSOR_CLOSE_ON_COMMIT la valeur OFF.
Chaque appel d'une fonction ou d'une méthode d'extraction d'API provoque un aller-retour vers le serveur en cas d'utilisation de curseurs de serveur. Les applications doivent réduire ces aller-retour à l'aide de curseurs de bloc permettant de retourner un nombre de lignes raisonnablement important à chaque extraction.
Voir aussi
Concepts
Types de curseurs (moteur de base de données)