Lorsque vous activez la variable de registre DB2_FORCE_FCM_BP, le nombre de |segments de mémoire partagée disponibles pour d'autres usages diminue, et |notamment en ce qui concerne les pools de mémoire tampon des bases de données. Par |conséquent, l'activation de cette variable de registre réduit la taille |maximale des pools de mémoire tampon des bases de données. Cette réduction du |nombre de segments s'avère être un problème spécifique aux environnements |32 bits puisque les environnements 64 bits disposent d'un grand nombre de segments de mémoire partagée.
| | |Lorsqu'une table est créée, les statistiques du catalogue système sont |définies sur -1 afin d'indiquer que la table n'a pas encore de statistiques. DB2 UDB utilise les valeurs par |défaut pour l'optimisation et la compilation des instructions SQL jusqu'à |ce que des statistiques soient recueillies. | La mise à jour de la table ou des statistiques d'index peut échouer si les |nouvelles valeurs sont incohérentes avec les valeurs par défaut. Par |conséquent, exécutez la commande runstats sur une table ou un index avant de mettre à jour manuellement |les statistiques de l'une ou l'autre.
| | |Le message d'erreur SQL SQL1169N dispose d'un nouveau code raison 5 |afin d'indiquer qu'une table EXPLAIN contient une colonne trop petite.
|Le texte suivant est une mise à jour du manuel |Administration |Guide: Performance, Chapter 6. Understanding the SQL compiler.
|Vous pouvez utiliser le transfert MDC même si un index RID fait partie |du programme d'optimisation sans tenir compte de la présence ou non d'une |clause WHERE dans l'instruction DELETE. |En conséquence, lorsque vous établissez la liste des conditions à remplir |pour autoriser le transfert et l'utilisation d'une méthode plus efficace de |suppression de lignes, la condition «Index RID non sélectionné par |l'optimiseur pour trouver les lignes à supprimer, sauf en cas d'absence de |clause WHERE dans l'instruction DELETE» doit être supprimée.
|Ensuite, la phrase «Suppression de cellule» affichée par la sortie |db2expln confirme que le transfert MDC est en vigueur. | La sortie db2exfmt n'affiche pas cette information.
|Le texte suivant est une mise à jour de |l'annexe A. |Variables d'environnement et de registre DB2:
|La description de DB2_MDC_ROLLOUT doit être modifiée afin que la condition |«Index RID non sélectionné par l'optimiseur pour trouver les lignes à |supprimer, sauf en cas d'absence de clause WHERE dans l'instruction DELETE» |soit supprimée de la liste.
| | |Si vous mettez à jour les valeurs des |paramètres de configuration newlogpath, |mirrorpath ou overflowlogpath dans un environnement DB2 UDB Enterprise |Server Edition, le numéro du noeud sera ajouté au nom de chemin sans tenir |compte du numéro des noeuds du système. Cette configuration s'applique aux |systèmes à partition unique ou à partitions multiples dans un environnement DB2 |UDB Enterprise Server Edition.
| | |La valeur par défaut de la variable DB2_COLLECT_TS_REC_INFO est définie sur |ACTIVEE. Dans la version 8.1 de DB2 UDB, FixPak 7, la valeur de la variable |de registre DB2_COLLECT_TS_REC_INFO a été définie par défaut |sur ACTIVEE. La documentation actuelle |indique à tort que la valeur par défaut de cette variable est DESACTIVEE.
Une instance de gouverneur se compose d'un utilitaire frontal et d'un ou de plusieurs démons. Chaque instance du gouverneur que vous démarrez est spécifique à une instance du gestionnaire de base de données. Par défaut, lorsque vous démarrez le gouverneur, un démon du gouverneur démarre sur chaque partition d'une base de données partitionnée. Toutefois, vous pouvez spécifier qu'un démon doit être démarré sur une seule partition, celle que vous souhaitez gérer.
Chaque démon du gouverneur collecte des informations à propos des applications qui s'exécutent sur la base de données. Le démon du gouverneur vérifie alors ces informations par rapport aux règles que vous avez indiquées dans le fichier de configuration du gouverneur pour cette base de données.
Lorsque vous envisagez une réorganisation de table interne (au lieu d'une réorganisation de table classique), souvenez-vous qu'elle nécessite davantage d'espace journal.
La réorganisation de table interne enregistre ses activités afin de permettre une reprise après un incident imprévu ; par conséquent, elle nécessite davantage d'espace journal que la réorganisation classique.
La réorganisation interne peut avoir besoin d'un espace journal équivalent à plusieurs fois la taille de la table réorganisée. La quantité d'espace nécessaire dépend du nombre de lignes qui sont déplacées et du nombre et de la taille des index de la table.
Recommandation : choisissez une réorganisation de table interne pour des opérations 24h/24 et 7j/7 avec des fenêtres de maintenance minimales.
Une réorganisation de table en ligne d'une table DMS permet de démarrer une opération de sauvegarde en ligne d'un espace table dans lequel réside la table au moment de la réorganisation. L'opération de réorganisation peut connaître des attentes sur verrouillage au cours de la phase de troncature.
Pour obtenir des informations détaillées sur l'exécution de ces méthodes de réorganisation de table, consultez les descriptions syntaxiques REORG TABLE.
Sous AIX 5L 64 bits, la variable de registre DB2_LARGE_PAGE_MEM prend désormais en charge le mot clé FCM.
Par défaut, sous AIX 5L 64-bits, la mémoire FCM se trouve dans l'ensemble des mémoires du système de gestion de base de données (DBMS). Toutefois, lorsque la variable de registre DB2_FORCE_FCM_BP est activée, la mémoire FCM se situe dans son propre ensemble de mémoires. Sous AIX 5L 64-bits, DB2_LARGE_PAGE_MEM prend en charge la spécification de l'ensemble des mémoires du système de gestion de base de données (DBMS). Lorsque la mémoire FCM se trouve dans l'ensemble des mémoires du DBMS, et que la prise en charge de page volumineuse est activée pour cet ensemble de mémoires, la mémoire FCM se situe dans des pages volumineuses. Lorsque la mémoire FCM se trouve dans son propre ensemble de mémoires, le mot clé FCM doit être ajouté à la valeur de la variable de registre DB2_LARGE_PAGE_MEM afin d'activer les pages volumineuses pour la mémoire FCM.
Avec la version 8.2.2 de DB2 Universal Database, UDB, (équivalente de la version 8.1, FixPak 9) le fichier de configuration indiqué par la variable de registre DB2_RESOURCE_POLICY accepte désormais un élément SCHEDULING_POLICY. L'élément SCHEDULING_POLICY peut être utilisé sur certaines plateformes pour sélectionner :
Les variables de registre DB2PRIORITIES et DB2NTPRICLASS peuvent être utilisées séparément pour contrôler le principe d'organisation du système d'exploitation et définir les priorités d'agent DB2.
Cependant, la spécification d'un élément SCHEDULING_POLICY dans le fichier de configuration des règles de ressource fournit un emplacement unique pour indiquer le principe d'organisation et les priorités d'agent associées.
Sélection du principe d'organisation AIX SCHED_FIFO2 avec un accroissement de priorité pour les processus d'écriture et de lecture du journal db2 :
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Remplacement par DB2NTPRICLASS=H sous Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Les variables d'environnement système DB2_MAPPED_BASE et DB2DBMSADDR ont été ajoutées au FixPack 8.
L'utilisation des variables de registre n'est recommandée que pour les utilisateurs expérimentés.
DB2 UDB tentera de replacer les bibliothèques partagées à l'adresse virtuelle 0x10000000 si cette variable n'est pas définie.
La variable de registre peut aussi être définie pour n'importe quelle adresse virtuelle (au format hexadécimal) dans la tranche d'espace adresse 31 et 32 bits.
db2set DB2_MAPPED_BASE=
Il se peut que le message suivant apparaisse plusieurs fois dans le fichier db2diag.log, car ce changement doit survenir pour chaque noeud logique :
ADM0506I DB2 a automatiquement mis à jour la valeur du paramètre "mapped_base" du noyau de "0x40000000(hex) 1073741824(dec)" à la valeur recommandée "0x10000000(hex) 268435456(dec)".
Ce message ne s'affiche que si la définition de la variable de registre a abouti et indique la nouvelle adresse des bibliothèques partagées.
db2set DB2DBMSADDR=
Vous pouvez définir cette variable conjointement avec DB2_MAPPED_BASE ou seule afin d'affiner la disposition de l'espace adresse des processus DB2 UDB. Cette variable modifie l'emplacement de la mémoire partagée d'instance en remplaçant son emplacement courant à l'adresse virtuelle 0x20000000 par la nouvelle valeur indiquée.
La variable de registre DB2TCP_CLIENT_RCVTIMEOUT a été ajoutée dans la version 8.2.
La variable de performances DB2_LARGE_PAGE_MEM a été ajoutée dans la version 8.2.
| Nom de variable | Systèmes d'exploitation | Valeurs |
|---|---|---|
| Description | ||
| DB2_LARGE_PAGE_MEM |
AIX 5.x 64 bits uniquement Linux |
Valeur par défaut = NULL
Utilisez le signe * pour dénoter que toutes les zones de mémoire applicables doivent utiliser une mémoire page volumineuse ou une liste séparée par des virgules de zones de mémoire spécifiques de mémoire page volumineuse. Les zones disponibles diffèrent en fonction du système d'exploitation. Sous AIX 5.x 64 bits, les zones suivantes peuvent être spécifiées : DB, DBMS ou PRIVATE. Sous Linux, la zone suivante peut être spécifiée : DB. |
|
La mémoire page volumineuse est prise en charge uniquement pour DB2 Universal Database (UDB) pour AIX 5L, 64-bit Edition, et DB2 UDB pour Linux. La variable de registre DB2_LARGE_PAGE_MEM est utilisée pour permettre la prise en charge des pages volumineuses lors de l'exécution sous AIX 5.x ou dans toute architecture Linux disposant du support de noyau approprié. Cette variable de registre déprécie la variable de registre DB2_LGPAGE_BP, qui peut uniquement être utilisée pour activer la mémoire page volumineuse pour la zone de mémoire partagée de la base de données. Ceci est désormais possible en spécifiant DB2_LARGE_PAGE_MEM=DB. Dans toute documentation, la mention de l'activation de pages volumineuses avec la variable de registre DB2_LGPAGE_BP peut être considérée comme synonyme de la définition de DB2_LARGE_PAGE_MEM=DB. L'utilisation d'une page volumineuse est principalement destinée à améliorer les performances des applications de calcul à hautes performances. Grâce aux pages volumineuses, il est possible d'améliorer les performances des applications intensives d'accès à la mémoire qui utilisent une grande quantité de mémoire virtuelle. Pour permettre à DB2 UDB d'utiliser des pages volumineuses, vous devez préalablement configurer le système d'exploitation en ce sens. L'activation de pages privées volumineuses augmente de manière significative la quantité de mémoire DB2 UDB utilisée, étant donné que chaque agent DB2 UDB utilise au moins 1 page volumineuse (16 Mo) de mémoire physique. Pour activer ces pages pour la mémoire privée de l'agent sur DB2 UDB 64 bits pour AIX (le paramètre DB2_LARGE_PAGE_MEM=PRIVATE), les conditions suivantes doivent être remplies, outre la configuration des pages volumineuses sur le système d'exploitation :
Si vous activez cette variable sur DB2 UDB 64 bits pour AIX, vous réduisez au minimum la taille de la mémoire de base de données de secours du segment de mémoire partagée. Par défaut, créez un segment à 64 Go : consultez le paramètre de configuration de la base de données (base de données_mémoire) de la mémoire partagée de la taille de la base de données pour obtenir plus de détails. Ainsi, vous évitez de réserver plus de mémoire partagée dans la mémoire RAM que vous ne serez susceptible d'utiliser. En attribuant une valeur à cette variable, vous limitez la possibilité d'augmenter de manière dynamique la configuration globale de la mémoire partagée de la base de données (pour augmenter la taille des pools de mémoire tampon, par exemple). Sous Linux, une configuration requise supplémentaire est nécessaire pour rendre la bibliothèque libcap.so disponible. Cette bibliothèque doit être installée pour que cette option puisse fonctionner. Si cette option est activée et que la bibliothèque n'est pas installée sur le système, DB2 UDB désactive les pages de noyau volumineuses et continue de fonctionner comme précédemment. Sous Linux, pour vérifier que les pages de noyau volumineuses sont disponibles, émettez la commande suivante : cat /proc/meminfo Si elles sont disponibles, les trois lignes suivantes doivent apparaître (avec des numéros différents en fonction de la quantité de mémoire configurée sur votre poste) : HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Si ces lignes n'apparaissent pas, ou si HugePages_Total est 0, la configuration du système d'exploitation ou du noyau est requise. |
||
La mise à jour suivante s'applique à la rubrique «SQL compiler variables» de l'annexe A «DB2 registry and environment variables» du guide Administration Guide: Performance:
Si les variables de compilateur DB2, DB2_MINIMIZE_LISTPREFETCH et DB2_INLIST_TO_NLJN ont chacune ou toutes deux la valeur ON, elles restent actives même si REOPT(ONCE) est spécifié.
Voici les mises à jour de la documentation relative au paramètre de configuration :
Le paramètre de type d'authentification (authentication) de la configuration du gestionnaire de base de données admet les valeurs suivantes :
Le serveur accepte les méthodes d'authentification chiffrée du serveur et le chiffrement des données utilisateur. L'authentification fonctionne exactement comme SERVER_ENCRYPT.
Les données utilisateur suivantes sont chiffrées lors de l'utilisation de ce type d'authentification :
Le serveur accepte les méthodes d'authentification chiffrée du serveur et le chiffrement des données utilisateur. En outre, ce type d'authentification permet la compatibilité avec des produits antérieurs qui ne prennent pas en charge le type d'authentification DATA_ENCRYPT. Ces produits sont autorisés à se connecter avec le type d'authentification SERVER_ENCRYPT et sans chiffrement des données utilisateur. Les produits qui prennent en charge le nouveau type d'authentification doivent l'utiliser. Ce type d'authentification n'est valable que dans le fichier de configuration du gestionnaire de base de données du serveur, il ne l'est pas s'il est utilisé sur la commande CATALOG DATABASE.
A partir de DB2 Universal Database version 8.2, la valeur par défaut du paramètre Instance impact policy ( util_impact_lim) de configuration du gestionnaire de base de données n'est plus 100 mais 10.
Les paramètres de configuration du gestionnaire de base de données suivants admettent tous des noms de groupe de 30 octets (ou moins) sur l'ensemble des plateformes :
Le tableau de la rubrique "Database manager configuration parameter summary" contient des types de données incorrects pour ces paramètres de configuration du gestionnaire de base de données. Dans tous les cas, la valeur correcte est char(30).
La valeur maximum du paramètre de configuration Extended storage memory segment size database (estore_seg_size) sur les plateformes Windows est 16 777 216.
La valeur maximum du paramètre HADR timeout value (hadr_timeout) de configuration de la base de données est 4 294 967 295.
La documentation relative au paramètre Maximum storage for locklist (locklist) de configuration de la base de données indique que sa valeur maximum est de 60 000 pour les serveurs 64 bits et 32 bits Windows destinés aux seuls clients locaux. Cette information est erronée : la valeur correcte est 524 288.
La plage de valeurs du paramètre Number of database backups (num_db_backups de configuration de la base de données est incorrecte. La plage de valeurs correcte est 0 - 32 767.
Après la migration de la version 8.1 à la version 8.2 de DB2 Universal Database (UDB), DB2 UDB utilise un nouveau fichier de paramètres de configuration de la base de données intitulé SQLDBCONF (16 ko). Dans la version 8.1, le fichier de paramètres de configuration de la base de données s'intitulait SQLDBCON et n'était que de 4 ko.
A partir de la version 8.1, la valeur ON est attribuée par défaut à la variable de registre DB2_HASH_JOIN.
La variable hash-join doit être utilisée, mais aussi ajustée pour optimiser les performances.
Les performances de la jointure par hachage sont meilleures si vous évitez les boucles par hachage et le dépassement de capacité du disque. Pour ajuster les performances de la jointure par hachage, évaluez l'espace mémoire maximum disponible pour le paramètre sheapthres, puis ajustez le paramètre sortheap. Augmentez sa valeur de façon à éviter autant que possible les boucles par hachage et les dépassements de capacité du disque, mais sans atteindre la limite spécifiée par le paramètre sheapthres.
Pour plus d'informations, voir la rubrique "Join methods" du manuel Administration Guide: Performance.
Les fonctionnalités préalablement réalisées via DB2NTNOCACHE peuvent l'être au niveau de l'espace de tables en spécifiant la clause NO FILE SYSTEM CACHING dans l'instruction CREATE TABLESPACE ou ALTER TABLESPACE. Reportez-vous à SQL Reference pour obtenir des détails sur son utilisation. La variable de registre DB2NTNOCACHE sera supprimée dans l'édition suivante.
Les tables d'explication doivent être communes à plusieurs utilisateurs. Toutefois, les tables d'explication peuvent être définies pour un utilisateur et des alias peuvent être définis pour chaque utilisateur supplémentaire utilisant le même nom pour pointer vers les tables définies. Par ailleurs, les tables d'explication peuvent être définies sous le schéma SYSTOOLS. La fonction Explain accède par défaut au schéma SYSTOOLS si aucune autre table d'explication ou aucun alias n'a été trouvé sous l'ID session de l'utilisateur pour les SQL dynamiques ou l'ID utilisateur de l'instruction pour les SQL statiques. Chaque utilisateur partageant des tables d'explication communes doit insérer des droits d'accès à ces tables. Les droits de lecture des tables d'explication communes doivent également être limités, en principe aux utilisateurs qui analysent les informations d'explication.
Les données d'explication sont capturées à votre demande lors de la compilation d'une l'instruction SQL. Réfléchissez à la manière dont vous souhaitez utiliser les informations capturées lorsque vous demandez des données d'explication.
Les informations de table d'explication sont capturées dans l'un des cas suivants :
Le paramètre d'informations d'interclassement peut uniquement être affiché à l'aide de l'API db2CfgGet. Il ne peut pas être affiché à l'aide du interpréteur de commandes ou du Centre de contrôle.
Ce paramètre offre 260 octets d'informations d'interclassement de base de données. Les 256 premiers octets spécifient la séquence de classement des informations, dans laquelle l'octet «n» contient le poids de tri du point de code dont la représentation décimale sous-jacente est «n» dans la page de codes de la base de données.
Les 4 derniers octets contiennent des informations internes relatives au type de séquence de classement. Les 4 derniers octets de collate_info sont un entier. L'entier est sensible à l'ordre endian de la plateforme. Les valeurs possibles sont les suivantes :
Si vous utilisez des informations sur le type internes, vous pouvez prendre en compte l'inversion d'octets lors de l'extraction des informations d'une base de données sur une plateforme différente.
Vous pouvez spécifier la séquence de classement au moment de la création de la base de données.
A partir de DB2 Universal Database (UDB) version 8.2, vous pouvez utiliser la taille de lecture anticipée automatique (AUTOMATIC) pour un espace table. DB2 UDB met automatiquement à jour la taille de lecture anticipée lorsque le nombre de conteneurs de l'espace table change.
La syntaxe de la variable de registre DB2_PARALLEL_IO est étendue pour reconnaître les conteneurs aux différentes caractéristiques de parallélisme d'E/S. Grâce à cette syntaxe étendue, les conteneurs d'espaces table différents peuvent comporter des caractéristiques différentes de parallélisme d'E/S. La caractéristique de parallélisme d'E/S de chaque espace table est utilisée lorsqu'une taille de lecture anticipée AUTOMATIC est spécifiée pour l'espace table. Si la variable de registre DB2_PARALLEL_IO est activée sans que soit utilisée la syntaxe étendue qui identifie des caractéristiques spécifiques de parallélisme d'E/S pour les espaces table, un niveau de parallélisme par défaut est supposé. Il s'agit de RAID 5 (6+1).
Les informations de taille de lecture anticipée utilisées par l'optimiseur ne sont régénérées qu'en cas d'émission de l'instruction ALTER TABLESPACE, qui modifie la taille de lecture anticipée d'un espace table ou le nombre de conteneurs (à l'aide de ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET). Si le paramètre de registre relatif au nombre de disques physiques par conteneur change, une instruction ALTER TABLESPACE <nom espace table > PREFETCHSIZE AUTOMATIC doit être émise pour régénérer les informations de l'optimiseur (sauf si une instruction ALTER TABLESPACE qui régénère les informations de l'optimiseur est déjà émise).
Si un espace table est redirigé ou restauré en vue de l'utilisation d'un nombre de conteneurs différent, régénérez les informations de l'optimiseur en émettant l'instruction ALTER TABLESPACE <nom espace table> PREFETCHSIZE AUTOMATIC. Si l'espace table comprend plusieurs ensembles de segments, le nombre maximum de conteneurs figurant parmi ces derniers est utilisé pour calculer la taille de lecture anticipée. Si la taille de lecture anticipée dépasse la valeur maximum (32 767 pages), elle est remplacée par le plus grand multiple du nombre de conteneurs, qui est inférieur à la taille maximum de la lecture anticipée.
Dans un environnement DB2 UDB Enterprise Server Edition, si un espace table utilise une taille de lecture anticipée automatique (AUTOMATIC), celle-ci peut varier sur les diverses partitions de base de données. Ceci peut se produire car des partitions de base de données différentes peuvent comporter des nombres de conteneurs différents, utilisés pour le calcul de la taille de lecture anticipée. Pour générer le plan d'accès à la requête, l'optimiseur utilise la taille de lecture anticipée de la première partition d'un groupe de partitions de base de données.
[ Début de page |Page précédente | Page suivante | Table des matières ]