![[z/OS]](../images/ngzos.gif)
Conseils d'optimisation de DB2 for z/OS
Le réglage des performances de DB2 est généralement essentiel aux performances globales d'une application WebSphere Application Server. DB2 est souvent le magasin de données préféré pour Enterprise JavaBeans (EJB). Vous trouverez dans cette rubrique plusieurs instructions de base pour l'optimisation de DB2 ainsi que plusieurs conseils pour l'optimisation de DB2 for WebSphere Application Server. Pour de plus amples informations sur l'optimisation de DB2, reportez-vous au Guide d'administration DB2 Universal Database for OS/390 and z/OS, document numéro SC26-9931-03. Les manuels DB2 sont disponibles à l'adresse Internet suivante : http://www.ibm.com/servers/eserver/zseries/zos/.
Avantages du langage SQL dans Java™ (SQLJ)
Si vous utilisez le fournisseur de pilote JDBC DB2 Universal, vous pouvez implémenter SQJL comme langage de requête pour les beans BMP et CMP. SQLJ encourt moins de surcharge de transaction que le langage de requête par défaut des transaction JDBC, correspondant au SQL dynamique. SQLJ est statique et utilise des plans pré-préparés. Ainsi, SQLJ améliore généralement les performances des applications. Pour les administrateurs de base de données DB2 for z/OS, SQJL est facilement adopté car le modèle de sécurité et les caractéristiques de répétition de l'instruction sont similaires à ceux du SQL statique. SQLJ nécessite des étapes supplémentaires qui sont des fonctions de versions plus récentes de WebSphere Studio Application Developer et de Rational Application Developer.
Pour plus d'informations, voir la rubrique relative au développement des applications d'accès aux données.
Conseils généraux pour l'optimisation de DB2 :
Ce qui suit concerne uniquement le pilote JDBC de DB2 for z/OS, appelé pilote JDBC Legacy de DB2 for z/OS.
- Tout d'abord, assurez-vous que vos journaux DB2 sont assez grands, qu'ils sont alloués aux volumes les plus rapides que vous avez et qu'ils disposent de tailles CI optimales.
- Ensuite, veillez à avoir réglé vos pools tampons de sorte que les données les plus lues soient le plus possible en mémoire. Utilisez ESTOR et des hyperpools.
- Vous devez prendre en compte des tableaux de pré-formatage qui seront utilisés de façon intensive. Cela évite le formatage lors de l'exécution.
Conseils d'optimisation de DB2 for WebSphere :
- Assurez-vous que la fonction de traçage de DB2 sous le pilote
DB2 for z/OS Universal est arrêtée.
- Si la propriété db2.jcc.propertiesFile jvm est définie pour spécifier un fichier de propriétés jcc DB2 à WebSphere Application Server for z/OS, assurez-vous que les instructions de traçage suivantes se trouvant dans le fichier sont mises en commentaires si elles sont spécifiées :
# jcc.override.traceFile=<file name> # jcc.override.traceFile=<file name>
- Si une des sources de données du pilote JDBC Universal de DB2 utilisées par votre application est définie avec une propriété personnalisée traceLevel (niveau trace) qui n'est pas zéro, utilisez la console d'administration de WebSphere Application Server for z/OS, pour donner la valeur zéro au traceLevel.
- Si la propriété db2.jcc.propertiesFile jvm est définie pour spécifier un fichier de propriétés jcc DB2 à WebSphere Application Server for z/OS, assurez-vous que les instructions de traçage suivantes se trouvant dans le fichier sont mises en commentaires si elles sont spécifiées :
- Veillez à définir des index sur les clés primaires de tous vos objets. Si ces consignes ne sont pas respectées, vous observerez des balayages d'espaces tables coûteux.
- Veillez, une fois que vos tables sont suffisamment remplies, à faire une réorganisation pour tasser les tables. L'exécution de RUNSTATS permet de s'assurer que les statistiques de catalogue DB2 sur les tailles et les accès de table et de colonne sont les plus courantes afin que les meilleurs modèles d'accès soient choisis par l'optimiseur.
- Vous devrez définir davantage de connexions, appelées unités d'exécution dans DB2. WebSphere Application Server utilise un grand nombre d'unités d'exécution. Cela cause parfois des goulots d'étranglement dans le rendement étant donné que le serveur attend qu'une unité d'exécution soit disponible au niveau de la création d'une unité d'exécution.
- Assurez-vous que vous êtes à jour en matière de maintenance JDBC. De nombreuses améliorations de performance ont été apportées à JDBC. Pour connaître le niveau de maintenance JDBC, entrez ce qui suit à partir du shell :
java com.ibm.db2.jcc.DB2Jcc -version
Si cela vous renvoie une classe non trouvée, soit vous vous trouvez à un niveau de pilote qui est plus ancien et qui ne prend pas en charge cette commande, soit vous n'avez pas émis la commande correctement. Pratiques recommandées: Activez la mise en cache d'instruction dynamique dans DB2. Pour y parvenir, modifiez votre ZPARMS pour qu'il affiche CACHEDYN(YES) MAXKEEPD(16K). Selon votre application, vous remarquerez une amélioration significative de vos performances DB2. Cela peut aider tout particulièrement JDBC et LDAP à interroger.bprac
- Attribuez aux intervalles entre points de contrôle DB2 une valeur plus élevée. Pour ce faire, modifiez votre ZPARMS pour qu'il inclue CHKFREQ=xxxxx où xxxxx est paramétré sur une valeur élevée pour effectuer des tests de performances. Cependant, sur les systèmes de production, il existe d'autres raisons valides pour conserver les fréquences de points de contrôle plus faibles.
//DB2INSTE JOB MSGCLASS=H,CLASS=A,NOTIFY=IBMUSER /*JOBPARM SYSAFF=* //****************************************************************** //* JOB NAME = DSNTIJUZ //* //* DESCRIPTIVE NAME = INSTALLATION JOB STREAM //* //* LICENSED MATERIALS - PROPERTY OF IBM //* 5675-DB2 //* (C) COPYRIGHT 1982, 2000 IBM CORP. ALL RIGHTS RESERVED. //* //* STATUS = VERSION 7 //* //* FUNCTION = DSNZPARM AND DSNHDECP UPDATES //* //* PSEUDOCODE = //* DSNTIZA STEP ASSEMBLE DSN6.... MACROS, CREATE DSNZPARM //* DSNTIZL STEP LINK EDIT DSNZPARM //* DSNTLOG STEP UPDATE PASSWORDS //* DSNTIZP STEP ASSEMBLE DSNHDECP DATA-ONLY LOAD MODULE //* DSNTIZQ STEP LINK EDIT DSNHDECP LOAD MODULE //* DSNTIMQ STEP SMP/E PROCESSING FOR DSNHDECP //* //* NOTES = STEP DSNTIMQ MUST BE CUSTOMIZED FOR SMP. SEE THE NOTES //* NOTES PRECEDING STEP DSNTIMQ BEFORE RUNNING THIS JOB. //* //* LOGLOAD=16000000, //*********************************************************************/ //* //DSNTIZA EXEC PGM=ASMA90,PARM='OBJECT,NODECK' //STEPLIB DD DSN=ASM.SASMMOD1,DISP=SHR //SYSLIB DD DISP=SHR, // DSN=DB2710.SDSNMACS // DD DISP=SHR, // DSN=SYS1.MACLIB //SYSLIN DD DSN=&LOADSET(DSNTILMP),DISP=(NEW,PASS), // UNIT=SYSALLDA, // SPACE=(800,(50,50,2)),DCB=(BLKSIZE=800) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) //SYSUT2 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) //SYSUT3 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) //SYSIN DD * DSN6ENV MVS=XA DSN6SPRM RESTART, X . . . AUTH=YES, X AUTHCACH=1024, X BINDNV=BINDADD, X BMPTOUT=4, X CACHEDYN=YES, X . . . MAXKEEPD=16000, X . . . DSN6ARVP ALCUNIT=CYL, X . . . DSN6LOGP DEALLCT=(0), X . . . DSN6SYSP AUDITST=NO, X BACKODUR=5, X CHKFREQ=16000000, X CONDBAT=400, X CTHREAD=1200, X DBPROTCL=PRIVATE, X DLDFREQ=5, X DSSTIME=5, X EXTRAREQ=100, X EXTRASRV=100, X EXTSEC=NO, X IDBACK=1800, X . . . //*