Les solutions techniques


Plate-forme MVS : DB2


Recommandations générales sur les performances


Avant de d'analyser les performance de DB2, vous devez vous assurer des bonnes performances du CICS qui héberge votre base de données, reportez vous au chapitre :

Recommandations générales sur les performances CICS.


Pour obtenir un temps de réponse satisfaisant, deux conditions sont nécessaires :


1) La conception et l'optimisation des programmes et des dialogues.


S'il existe plusieurs façons d'écrire un ordre SQL pour obtenir le résultat souhaité, la

performance des ordres SQL dépendra du chemin d'accès choisi par l'optmiseur DB2.


Les chemins d'accès assurant les meilleurs performances sont les accès par la structure

d'arbre d'index :

  - La première condition est l'existence d'un INDEX défini sur les  colonnes des prédicats

    de la clause WHERE d'un ordre SQL.

  - La seconde condition est l'utilisation de prédicats dits  « indexables »  .

    (DB2 © Administration Guide fournit une liste complète des prédicats  indexables)


. Quelques exemples de règles de codage des ordres SQL :

  - Les colonnes d'un ordre select doivent êtres nommées explicitement  éviter le SELECT *

  - La fonction NOT doit être restreinte au NOT EXIST

  - Utiliser des jointures plutôt que des SUB-SELECT 

  - L'ordre SQL LOCK TABLE IN SHARE (exclusive) à éviter en mode transactionnel

  - Placer les mises à jour des tables en fin de transaction  pour éviter les risques de

    DEADLOCKS et les effets du LOGING


2) L'optimisation des objets et des ressources.


Il n'y a pas de statistique indiquant directement le besoin de réorganisation, cependant les

règles suivantes aident à la compréhension du besoin de réorganisation, Il faut donc mettre

en oeuvre une politique de prévention  sur l'état des INDEX et des TABLESPACES en fixant un seuil de tolérance et organiser les OBJETS concernés.


- Les TABLESPACES se désorganisent par insertion de lignes hors de la page optimum.

- Les INDEXS sont tries et compacts par ordres de clé, ils se désorganisent suite à l'insertion ou de la suppressions de lignes, si le pourcentage de désorganisation est trop important l'optimiseur risque de ne plus utiliser l'index.

- La « relocalisation » des lignes provoque l'écriture des données en dehors des limites des pages optimum pour les TABLESPACES et les INDEXS (PAGES SPLITS), le paramètre

LEAFDIST fournit la distance entre ces pages. (Ex. LEAFDIST > 200 distance moyenne en deux pages successives supérieur à 0.2.)


- Les contrôles et les actions sont à effectuer périodiquement :

  (la semaine est une bonne fréquence)

     

Les requêtes SQL :   

  . Les pages hors limites (LEAFDIST) sur les TABLESPACES

  . Les pages hors limites (LEAFDIST) sur les INDEXS

  . L'ordre de séquence des cles d'INDEXS (ORDERED)

  . L'espace des pages occupées par les TABLESPACES

  . L'espace des pages occupées par les INDEXS

  Les utilitaires :

  . La réorganisations des TABLESPACES (REORG)

  . La réorganisations des INDEXS (REORG)

  . La mise à jour des statistiques du CATALOGUE (RUNSTATS, STOSPACE)

  . La mise à jour des PLANS (BIND, REBIND)


Les problèmes rencontrés, les réponses apportées.

Recommandations sur la sécurité des données.

Quelques requêtes sur le catalogue à télécharger

L'expérience des « uns » aux profits des  « autres »

MemoHost.com © référencé par  AltaVista  Ecila   Excite  Google  HotBot  MSN  Lokace  Nomade Yahoo Voila