Réglage de la base de données

d’API au niveau appel prenant
en charge la base de données SQL.
L’accès SQL implique la longueur de
voie de la CPU, mais inclut également
les I/O disque et l’utilisation de la mémoire.
Voyons les différentes possibilités
de réglage de la base de données
pour en tirer une performance maximale.

Superviser les niveaux d’isolation
des transactions. Les niveaux d’isolation des transactions permettent
de s’assurer que celles-ci peuvent
accéder à  des données vitales sans aucun
problème d’intégrité/partage de
données (corruption de données, par
exemple) quand deux utilisateurs ou
plus convoitent les mêmes enregistrements
dans une base de données. Vous
pouvez configurer des applications de
manière à  ce qu’elles utilisent un niveau
d’isolation de transaction particulier
pour réduire le risque de problèmes
d’intégrité de données sans
créer un overhead excessif.

Bien entendu, plus l’isolation des
transactions est rigoureuse et plus augmente
le risque de verrouillage des
enregistrements. Le verrouillage
des enregistrements peut ralentir
les autres transactions et réduire
l’évolutivité, particulièrement dans le
cas de transactions longues et inefficaces.
En fait, le support de la base de
données OS/400 iSeries doit s’assurer
que les applications utilisant le niveau
d’isolation des transactions SERIALIZABLE
peuvent se répéter intégralement
avec exactement les mêmes données
si la transaction est inversée . De
ce fait, les autres transactions utilisant
les mêmes tables sont tenues à  l’écart
des enregistrements vitaux jusqu’à  ce
que la transaction contenant les verrous
émette une opération Commit.

Il faut utiliser les niveaux d’isolation
les plus rigoureux pour préserver
au maximum l’intégrité des données.
Mais il faut maintenir le verrouillage à 
un niveau raisonnable en n’utilisant les
niveaux d’isolation supérieurs que
pour les transactions traitant des données
pour lesquelles l’intégrité est très
importante. On peut aussi concevoir
des applications qui émettront fréquemment
des opérations Commit
pour lever les verrous et permettre
ainsi à  d’autres utilisateurs d’accéder
aux données. Pour plus d’informations
sur les niveaux d’isolation, voir DB2
Universal Database for iSeries SQL
Reference, disponible à  http://publib.
boulder.ibm.com/html/as400/v5r1/ic29
24/index.htm?info/db2/rbafzmst02.htm.

Eliminer l’accès SQL inefficace.
Comme je l’ai déjà  dit, les programmes
Java accèdent normalement
aux fichiers base de données via des
API JDBC. Les drivers JDBC utilisent SQL pour accéder à  la base de données.
Un accès JDBC inefficace et des
instructions SQL non réglées peuvent
nuire considérablement à  la performance
et à  l’évolutivité. Dans des applications où les utilisateurs luttent
pour les mêmes tables (voire les
mêmes enregistrements), un SQL inefficace
peut également entraîner de
longs délais de verrouillage. Eliminer
les opérations SQL inefficaces a le
double mérite de réduire les temps de
réponse individuels et d’améliorer
l’évolutivité.

L’utilisation inefficace des index est
un problème de performance SQL
courant. Bien que les index SQL puissent,
dans de nombreux cas, améliorer
le temps d’extraction des enregistrements
et réduire l’utilisation des ressources,
la construction d’index temporaire,
peut avoir l’effet inverse.
L’optimiseur SQL détermine la manière
de traiter les requêtes en se fondant
sur des critères comme la taille de
la table, la sélectivité des enregistrements
et la disponibilité ou non des index.
S’il n’y a pas d’index disponibles et
si l’optimiseur SQL les juge intéressants,
il peut décider de créer un index
temporaire ou d’utiliser un mécanisme
différent pour accéder aux enregistrements.
Les temps de réponse résultants
sont généralement plus longs
que ceux que l’on constate quand un
index existe déjà . La création d’index
temporaires qui ne sont pas réutilisés
ou le balayage de très grandes tables de
bases de données avec une faible sélectivité,
peuvent avoir des effets désastreux
sur l’évolutivité de l’application.
On subira alors de hauts débits d’I/O et/ou une forte consommation
de CPU, et donc un gaspillage de ressources
précieuses.

Autre problème SQL courant : un
accès inefficace aux enregistrements.
Des applications transactionnelles différentes
accèdent souvent aux mêmes
tables et, dans certains cas, aux mêmes
enregistrements. C’est ainsi qu’une application
de saisie de commandes peut
fort bien utiliser un enregistrement
unique pour stocker la valeur du prochain
numéro de commande à  utiliser.
Quand les utilisateurs de l’application
veulent commander, ils doivent extraire
la valeur de cet enregistrement et
lui ajouter un pour l’utilisateur suivant.
L’enregistrement doit être unique pour
éviter la duplication des numéros de
commandes. Au fur et à  mesure que le
nombre d’utilisateurs de l’application
augmente, il est évident que le niveau
d’isolation de transaction de cet enregistrement
doit être réglé plus haut
que Read Uncommitted. Et donc, dès
lors qu’un utilisateur de l’application
verrouille l’enregistrement, les autres
utilisateurs sont condamnés à  attendre.
C’est ce que l’on appelle le
« problème du numéro suivant ».

Pour réduire le verrouillage, on
peut recourir à  un schéma de base de
données différent. Une technique courante
consiste à  diviser l’enregistrement
unique en plusieurs enregistrements
afin que des types de
transactions différents accèdent à  des valeurs d’enregistrements différentes.
Ainsi, dans une application de saisie de
commandes, les commandes, les requêtes
et les problèmes peuvent tirer
leurs valeurs d’enregistrements distincts
. Comme ces transactions
ne partagent pas le même enregistrement,
le verrouillage est réduit.

Visual Explain d’Operations
Navigator est un outil utile qui permet
d’examiner les détails des instructions
SQL de l’application. On
peut aussi utiliser le Database Monitor.
Ces outils permettent d’optimiser les
requêtes de la base de données et de
creuser la question face à  des problèmes
d’inefficacité de l’accès SQL.