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

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

Tech - Par iTPro - Publié le 24 juin 2010
email

Quand on déclare un curseur, on l'assortit de l'un des trois mots-clés indiquant si le curseur est « sensible » aux changements dans les lignes du jeu de résultats :

Sensitive - Les changements apportés aux données après que le curseur ait été ouvert, sont visibles par le programme.
Insensitive

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.

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

Tech - Par iTPro - Publié le 24 juin 2010