Conseil 4 : Faire attention aux curseurs Asensitive avec Read-Only

– Les changements apportés aux données
après que le curseur ait été ouvert, ne sont pas visibles par le
programme.
Asensitive (par défaut) – Quand le curseur est en lecture
seule, il est insensitive ; dans le cas contraire, il est sensitive.

Le moteur DB2 fait toujours une copie temporaire du jeu
de résultats pour les curseurs insensitive ; cette opération demande
du temps et absorbe des ressources. Il vaut mieux éviter
cette copie quand le moteur de base de données peut recourir
à  une technique d’accès plus rapide. Bien entendu, si
un curseur doit être insensitive, il faut coder explicitement le
mot-clé Insensitive. Cela assure et documente la sensibilité
du curseur voulue. A noter que le fait de spécifier Insensitive
a pour résultat de mettre un curseur en lecture seule.
Dans le même esprit, si un curseur doit être sensitive, il
faut coder le mot-clé sensitive. Tout curseur appelé à  exécuter
des instructions Update ou Delete doit être sensitive. Il
est également courant, dans des applications « browse »,
d’utiliser des curseurs (permettant un positionnement vers
l’avant et vers l’arrière) et de les déclarer comme des
curseurs sensitive, afin qu’ils reflètent les toutes dernières
données.
Parfois, il sera indifférent que le curseur soit sensitive ou
pas. Dans ce cas, il ne faudra pas commettre l’erreur de coder Asensitive (ou de ne pas coder de mot-clé du tout, ce
qui est équivalent) en pensant obtenir ainsi le résultat optimal.
Si l’on code à  la fois Asensitive et For Read Only sur la
déclaration du curseur, l’optimiseur de requêtes fera une copie
temporaire, pénalisante pour la performance. (L’équipe
de développement DB2 d’IBM songe à  changer ce comportement
; à  suivre, donc.)
En combinant l’information de ce conseil avec celle du
conseil 3, on obtient les règles suivantes :

• Pour avoir un curseur insensitive, coder Insensitive et For
  Read Only.

• Pour avoir un curseur sensitive, coder Sensitive et la clause
  d’accès appropriée comme suggéré au Conseil 3.

• Quand on ne se soucie pas de la sensibilité des données et
  que l’application contient des instructions Update ou
  Delete qui font référence au curseur, coder
  Sensitive et la clause d’accès appropriée
  comme au Conseil 3.

Quand on ne se soucie pas de la sensibilité
des données et que l’application ne
contient que des opérations Fetch, il faut élaborer
un peu plus. Essentiellement, il faut
découvrir si l’optimiseur utilisera ou non une
copie temporaire pour honorer la requête
plus efficacement :

• Premièrement, coder la déclaration du curseur sans le motclé
  Asensitive et sans une clause For Read Only ou For
  Update.

• Tester l’application sur des tables de production en mode
  debug (ou utiliser iSeries Navigator Visual Explain) pour
  examiner quelle méthode d’accès choisit
  l’optimiseur de requêtes. Essayer
  d’utiliser un environnement (pools de
  mémoire, par exemple) le plus proche
  possible de votre environnement de
  production.

• Si l’optimiseur utilise une table temporaire,
  ajouter Asensitive et For
  Read Only à  la déclaration du curseur.
  (On obtient encore un curseur insensitive,
  mais en codant Asensitive, on
  pourra bénéficier des futurs changements
  qu’IBM pourrait apporter aux
  règles de l’optimiseur.)

• Sinon, ajouter Sensitive et For Read
  Only. Ensuite, retester l’application.
  Si l’on constate une erreur quand le
  curseur est ouvert, changer le paramètre
  en Asensitive.

Le groupe de conseils suivant s’applique
aux procédures stockées SQL
(SP, stored-procedures), aux fonctions
définies par l’utilisateur (UDF, user-defined
functions) et aux déclencheurs
(triggers). SQL/400 convertit le code
SPL que vous écrivez en code C ILE avec SQL imbriqué puis
précompile et compile ce code en objets programme
OS/400, que le runtime SQL appellera quand on invoquera
une SP, une UDF ou un trigger.