Variables de performance

L'avantage potentiel de définir une valeur plus élevée pour cette variable de registre est le moins d'allocations nécessaires pour atteindre une quantité de mémoire souhaitée pour un pool de mémoire tampon.

Le coût potentiel de la définition d'une valeur supérieure pour cette variable de registre est une perte de mémoire si le pool de mémoire tampon est modifié par un non-multiple de la taille d'allocation. Par exemple, si la valeur de DB2_ALLOCATION_SIZE est 8 Mo et si un pool de mémoire tampon est réduit de 4 Mo, cette valeur de 4 Mo sera gaspillée, car un segment de 8 Mo entier ne peut pas être libéré.

Si vous affectez à DB2_APM_PERFORMANCE la valeur ON, vous activez également le mode NO PACKAGE LOCK. Ce mode permet à la mémoire cache de requêtes globale de fonctionner sans l'utilisation de verrous de package, qui sont des verrous internes du système qui protègent les entrées de package mises en cache d'être supprimées. Le mode NO PACKAGE LOCK peut entraîner une amélioration des performances, mais certaines opérations de base de données ne sont pas autorisées. Ces opérations interdites peuvent inclure des opérations qui invalident des packages, des opérations qui font cesser de fonctionner des packages, et PRECOMPILE, BIND et REBIND.

L'activation de la variable de registre DB2ASSUMEUPDATE est effective sur la commande db2start .

Indique si les images de sauvegarde et de copie de chargement sont mises en cache par le système d'exploitation. Le comportement par défaut consiste à mettre en cache le fichier image. Lorsque DB2_BACKUP_USE_DIO a la valeur ON, le fichier image de sauvegarde ou de copie de chargement est directement écrit sur le disque, en contournant le cache de fichiers.

     NO_NT_SCATTER = 1

   db2set DB2BPVARS=F:\vars\bpvars.vars

Paramètres Scatter-read

Les paramètres de lecture dispersée sont recommandés pour les systèmes avec une grande quantité de lecture anticipée séquentielle par rapport au type de conteneur respectif et pour lesquels vous avez déjà affecté à DB2NTNOCACHE la valeur ON. Ces paramètres, disponibles uniquement sur les plateformes Windows, sont NT_SCATTER_DMSFILE, NT_SCATTER_DMSDEVICEet NT_SCATTER_SMS. Spécifiez le paramètre NO_NT_SCATTER pour autoriser explicitement la lecture dispersée pour n'importe quel conteneur. Des paramètres spécifiques sont utilisés pour activer la lecture dispersée pour tous les conteneurs du type indiqué. Pour chacun de ces paramètres, la valeur par défaut est zero (ou OFF) et les valeurs possibles sont les suivantes : zero (ou OFF) et 1 (ou ON).

DB2_EVALUNCOMMITTED est applicable uniquement lorsque la sémantique validée ne permet pas d'éviter les conflits de verrouillage. Lorsque cette variable est définie et qu'elle est actuellement validée pour une analyse, les lignes supprimées ne sont pas ignorées et l'évaluation du prédicat n'a pas lieu sur les données non validées ; la version actuellement validée des lignes et des données est traitée à la place.

En outre, DB2_EVALUNCOMMITTED ne s'applique qu'aux instructions utilisant les niveaux d'isolement Cursor Stability ou Read Stability. En outre, les lignes supprimées sont ignorées sans condition lors de l'accès à l'analyse de table alors que les clés supprimées ne sont pas ignorées pour les analyses d'index sauf si la variable de registre DB2_SKIPDELETED est également définie.

L'activation de la variable de registre DB2_EVALUNCOMMITTED est effective sur la commande db2start . La décision quant à savoir si le verrouillage différé est applicable est prise à l'heure de compilation ou de liaison des instructions.

• Version de la base de données: Db2 V9.1
• L'unité RAW doit être utilisée pour les conteneurs de base de données (le conteneur sur les systèmes de fichiers n'est pas pris en charge)
• Sous-système de stockage: Shark DS8000® prend en charge toutes les fonctions de performances d'E-S améliorées. Pour plus d'informations sur la configuration et les prérequis, reportez-vous à la documentation de Shark DS8000 .

Les paramètres de priorité E-S par défaut pour HIGH, MEDIUM et LOW sont respectivement 3, 8 et 12. Vous pouvez utiliser la variable de registrer DB2_IO_PRIORITY_SETTING pour changer ces paramètres.

Cette variable indique si l'optimiseur de requêtes utilise des extensions d'optimisation pour améliorer les performances des requêtes. Les valeurs indiquent des extensions d'optimisation différentes. Pour spécifier plusieurs valeurs, utilisez une liste séparée par une virgule.

   INDEX IX2:  dept    ASC
   INDEX IX3:  job     ASC

   WHERE
        dept = :hv1 OR
        (job = :hv2 AND
        years >= :hv3)

Vous pouvez utiliser l'option OPT_SORTHEAP_EXCEPT_COL valeur pour remplacer la valeur du paramètre de configuration de base de données sortheap. La valeur de substitution affecte uniquement l'optimisation des requêtes et ne détermine pas la quantité de mémoire réelle disponible lors de l'exécution. Si la requête accède à une table organisée par colonnes , cette valeur de substitution est ignorée pour permettre au compilateur de requête d'utiliser la valeur en cours du paramètre de configuration de base de données sortheap .

L'une des utilisations de OPT_SORTHEAP_EXCEPT_COL concerne les tables fantômes. Les tables ombrées facilitent BLU Acceleration® pour les requêtes analytiques dans l'environnement OLTP. Les tables fantômes sont des tables organisées par colonnes . Les exigences relatives à la mémoire de tri sont supérieures à ce que vous devez normalement posséder pour les bases de données dans les environnements OLTP. Pour augmenter la mémoire de tri sans affecter les plans d'accès existants pour les requêtes OLTP, ajoutez OPT_SORTHEAP_EXCEPT_COL à DB2_EXTENDED_OPTIMIZATION pour remplacer la valeur du paramètre de configuration de base de données sortheap.

Les paramètres DB2_EXTENDED_OPTIMIZATION risquent de ne pas améliorer les performances des requêtes dans tous les environnements. Vous devez tester pour déterminer les améliorations de performances des requêtes individuelles.

Lorsque cette variable est définie sur CONNECTION, un verrou de table est libéré pour une application jusqu'à ce que l'application annule la transaction ou que la connexion soit réinitialisée. Le verrou de table continue à être détenu entre les validations et les demandes d'application pour supprimer le verrou de table sont ignorés par la base de données. Le verrou de table reste alloué à l'application. Ainsi, lorsque l'application redemande le verrou de table, le verrou est déjà disponible.

Pour les charges de travail d'application pouvant optimiser cette optimisation, les performances doivent s'améliorer. Toutefois, les charges de travail d'autres applications en cours d'exécution peuvent être affectées. D'autres applications peuvent être bloquées à l'accès à une table donnée, ce qui entraîne une faible concurrence. Les tables de catalogue SQL Db2 ne sont pas impactées par ce paramètre. Le paramètre CONNECTION inclut également le comportement décrit avec la valeur ON ou TRANSACTION.

Cette variable de registre est vérifiée lors de la compilation de l'instruction ou de la liaison.

Lorsque vous utilisez de grandes pages ou de très grandes pages pour la mémoire de base de données (DB), la diminution dynamique de la mémoire de la base de données est limitée et le paramètre db_mem_thresh est ignoré. Le gestionnaire de mémoire à réglage automatique (STMM) ne permet pas d'ajuster la taille globale de la zone de base de données. Cependant, STMM élague les zones à l'intérieur de la région de mémoire de la base de données sous réserve de configuration. Pour plus d'informations, voir la rubrique database_memory dans la section des liens connexes.

Les applications intensives d'accès à la mémoire qui utilisent de grandes quantités de mémoire virtuelle peuvent obtenir des améliorations de performances en utilisant de grandes ou de grandes pages. Pour permettre au système de base de donnéesDb2 de les utiliser, vous devez d'abord configurer le système d'exploitation pour qu'il utilise des pages volumineuses ou volumineuses.

Pour activer les grandes pages pour la mémoire privée de l'agent sur Db2 for AIX 64 bits (paramètre DB2_LARGE_PAGE_MEM=PRIVATE ), vous devez configurer les grandes pages sur le système d'exploitation et le propriétaire de l'instance doit posséder les fonctions CAP_BYPASS_RAC_VMM et CAP_PROPAGATE.

Sous Linux, pour vérifier que de très grandes pages de noyau sont disponibles, exécutez la commande suivante :

   cat ⁄proc/meminfo

Si de grandes pages de noyau sont disponibles, les trois lignes suivantes doivent être affichées (avec des nombres différents selon la quantité de mémoire configurée sur votre serveur) :

HugePages_Total:   200
HugePages_Free:    200
Hugepagesize:    16384 kB

Si vous ne voyez pas ces lignes, ou que la valeur de HugePages_Total est 0, vous devez configurer le système d'exploitation ou le noyau.

Sous Windows, la quantité de mémoire de grandes pages disponible sur le système est inférieure à la quantité totale de mémoire disponible. Une fois que le système est en cours d'exécution depuis un certain temps, la mémoire peut se fragmenter, et la quantité de mémoire de grande page diminue. La variable de registre DB2_ALLOCATION_SIZE doit être définie sur une valeur élevée, telle que 256 Mo, afin d'obtenir des performances cohérentes lors de l'allocation de grandes pages de mémoire sous Windows. (Notez que DB2_ALLOCATION_SIZE vous demande d'arrêter et de redémarrer l'instance.)

Le segment de mémoire du moniteur système peut être épuisé si une application contient un nombre très élevé d'instructions dans une unité de travail ou qu'un grand nombre d'applications s'exécutent simultanément.

• Aucun déploiement - Si OFF est spécifié
• Déploiement immédiat - Si IMMEDIAT est spécifié.
• Déploiement avec nettoyage d'index différé - Si DEFER est spécifié

Si seuls les index RID non partitionnés existent sur la table, le déploiement du nettoyage d'index différé est pris en charge.

La valeur YES DB2MEMDISCLAIM génère moins de besoins en espace de pagination et peut-être moins d'activité de disque à partir de la pagination. La valeur No DB2MEMDISCLAIM génère de plus grandes besoins en espace de pagination, et peut-être davantage d'activité sur le disque à partir de la pagination. Dans certains cas, par exemple si l'espace de pagination est abondant et que la mémoire réelle est si abondante que la pagination n'a jamais lieu, NO améliore faiblement les performances.

Si cette variable n'est pas définie, le gestionnaire de base de données Db2 calcule les valeurs pour minfree et maxfree en fonction de la quantité de mémoire sur le serveur. Dans les environnements instance_memory limités, le gestionnaire de base de données Db2 calcule les valeurs pour minfree et maxfree en fonction du paramètre instance_memory . Le paramètre de cette variable n'a aucun effet à moins que le gestionnaire de mémoire à réglage automatique (STMM) soit activé et que database_memory ait la valeur AUTOMATIC.

A partir de version 10.5, une mémoire tampon supplémentaire de 5% est ajoutée, qui est incluse dans les valeurs du tableau précédent. Cette mémoire tampon supplémentaire permet de tenir compte de la volatilité des besoins en mémoire dans un plus large éventail d'environnements tout en maintenant la résilience attendue des environnements STMM automatiquement réglés. Cependant, la mémoire tampon supplémentaire de 5 % est disponible pour les bases de données nouvellement activées afin de réduire au minimum le décodage (redimensionnement) lors de l'activation. Si un tuner STMM version 10.5 ou ultérieure détecte la présence de tuners STMM des éditions précédentes (qui sont en concurrence avec eux pour la mémoire système), la mémoire tampon supplémentaire de 5% est supprimée du calcul pour les bases de données qui s'exécutent sur version 10.5 ou ultérieure. Cette suppression de la mémoire tampon de 5 % supplémentaire permet d'éviter une allocation de mémoire secondaire vers les bases de données qui s'exécutent sur les versions précédentes (ce qui aurait tendance à avoir des cibles de mémoire libre inférieures).

Les gains de performances peuvent être obtenus en réduisant les paramètres minfree, maxfree dans un environnement STMM. Cependant, il faut veiller à ce que la volatilité des besoins en mémoire ne se traduit-elle pas par une pagination ou un épuisement de la mémoire.

Les modifications apportées à cette variable prennent effet immédiatement pour toutes les opérations d'optimisation STMM. Il n'est pas nécessaire de redémarrer l'instance ou d'exécuter la commande db2set avec le paramètre -immediate.

Lorsque ces variables sont définies sur ON, les données sont lues et écrites dans les pools de mémoire tampon Db2 à l'aide des E-S mappées en mémoire, puis supprimées du cache du système de fichiers. Cela évite la double mise en cache des données Db2 . Toutefois, la méthode recommandée pour ignorer le cache du système de fichiers est de spécifier la clause NO FILE SYSTEM CACHING au niveau de l'espace table et conserver les valeurs par défaut OFF des variables.

Lorsque ces variables sont définies sur ON, les données sont lues et écrites dans les pools de mémoire tampon Db2 à l'aide des E-S mappées en mémoire, puis supprimées du cache du système de fichiers. Cela évite la double mise en cache des données Db2 . Toutefois, la méthode recommandée pour ignorer le cache du système de fichiers est de spécifier la clause NO FILE SYSTEM CACHING au niveau de l'espace table et conserver les valeurs par défaut OFF des variables.

1. Mémoires tampon FCM parallèles : la taille par défaut est de 512 Mo sur les plateformes 32 bits, 4,5 Go sur les plateformes 64 bits ; l'option de substitution est FCM:nombre_octets
2. Communication en mode isolé : la taille par défaut est de 80 Mo sur les plateformes 32 bits, 512 Mo sur les plateformes 64 bits ; l'option de substitution est APLD:ombre_octets
3. Mémoire de requête de message: la taille par défaut est de 4 Mo sur les plateformes 32 bits et 64 bits ; l'option de substitution est QUE :<number of bytes>.

db2set DB2NTMEMSIZE=FCM:1073741824;APLD:268435456

db2set DB2NTMEMSIZE=QUE:67108864

Dans Windows, les fichiers sont mis en cache lorsqu'ils sont ouverts, ce qui est le comportement par défaut. Un Mo est réservé dans un pool système pour chaque 1 Go du fichier. Utilisez cette variable de registre pour remplacer la limite non documentée de 192 Mo pour le cache. Lorsque la limite de mémoire cache est atteinte, une erreur de non-ressource est donnée.

• NORMAL_PRIORITY_CLASS (classe de priorité par défaut)
• REALTIME_PRIORITY_CLASS (défini à l'aide de R)
• HIGH_PRIORITY_CLASS (défini à l'aide de H)

Cette variable est utilisée conjointement avec les priorités d'unité d'exécution individuelles (définies à l'aide de DB2PRIORITIES) pour déterminer la priorité absolue des unités d'exécution Db2 par rapport aux autres unités d'exécution du système.

Pour plus d'informations, reportez-vous à l'API SetPriorityClass() dans la documentation Win32.

Indiquez DB2NTWORKSET à l'aide de la syntaxe DB2NTWORKSET=min, max, où min et max sont exprimés en mégaoctets.

Vous pouvez également utiliser <entry>[;<entry>...], où <entry> =<buffer pool ID>,<number of pages> pour modifier temporairement la taille de tout ou un sous-ensemble des pools de mémoire tampon afin qu'ils puissent démarrer.

Sous Linux, outre la modification de cette variable de registre, la bibliothèque libcap.so.1 est également requise.

Si vous affectez à cette variable la valeur YES, l'optimisation de la mémoire partagée de la base de données (activée en affectant au paramètre de configuration database_memory la valeur AUTOMATIC) ne peut pas être activée.

Pour HP-UX dans un environnement 64 bits, en plus de la modification de cette variable de registre, le groupe d'instances Db2 doit disposer du privilège MLOCK. Pour ce faire, un utilisateur disposant des droits d'accès root effectue les actions suivantes:

Sur les systèmes AIX dotés de processeurs POWER7® ou plus récents, ou tout système Linux ou Windows, cette variable peut être définie sur AUTOMATIC. Lorsque l'option AUTOMATIC est spécifiée, le système de base de données Db2 détermine automatiquement la topologie matérielle et crée un groupe de ressources pour chaque ensemble de ressources associées (processeurs et mémoire) qui sont visibles dans la topologie matérielle. Selon la topologie matérielle, il peut y avoir un ou plusieurs groupes de ressources, chacun contenant une ou plusieurs ressources.

Le paramètre AUTOMATIC active l'affinité de processeur, par laquelle le système de base de données Db2 affecte des unités de répartition du moteur (EDU) à des groupes de ressources et des ressources spécifiques. En outre, le paramètre AUTOMATIC détermine également s'il convient d'activer l'affinité de mémoire, en vertu de laquelle les EDU tentent d'allouer de la mémoire locale pendant le traitement, afin d'améliorer l'affinité de mémoire. L'affectation d'EDU à des ressources se fait de façon circulaire et suppose que chaque ressource est équivalente. Sur les systèmes utilisant POWER7 et les processeurs plus récents, l'utilisation du paramètre AUTOMATIC n'est pas recommandée lorsque la distribution des ressources est biaisée et / ou susceptible d'être modifiée, par exemple dans les systèmes comportant plusieurs partitions logiques. Sur les systèmes POWER ® exécutant AIX, l'allocation de ressources peut être déterminée à l'aide de la commande lssrad -av . Sur les systèmes POWER exécutant Linux, l'allocation de ressources peut être déterminée à l'aide de la commande numactl -H .

Ce paramètre est destiné aux systèmes qui exposent plusieurs groupes de ressources et / ou ressources dans leur topologie matérielle et peut améliorer les performances des requêtes pour certaines charges de travail. Pour valider les améliorations de performances, il est recommandé d'exécuter une analyse des performances de la charge de travail avant et après avoir défini la variable DB2_RESOURCE_POLICY sur AUTOMATIC.

Vous pouvez également définir la variable de registre pour indiquer le chemin d'accès à un fichier de configuration qui définit une règle pour la liaison d'EDU Db2 à des groupes de ressources et des ressources spécifiques. Cela est utile dans les cas où la configuration souhaitée ne peut pas être obtenue à l'aide du paramètre AUTOMATIC .

Exemples de fichiers de configuration :

Exemple 1: Liaison de tous les processus Db2 à l'unité centrale 1 ou 3.

<RESOURCE_POLICY>  	
		<GLOBAL_RESOURCE_POLICY>  
			<METHOD>CPU</METHOD> 
			<RESOURCE_BINDING> 
  		<RESOURCE>1</RESOURCE>	
			</RESOURCE_BINDING>
			<RESOURCE_BINDING>
				<RESOURCE>3</RESOURCE>
			</RESOURCE_BINDING>
		</GLOBAL_RESOURCE_POLICY>
	</RESOURCE_POLICY> 

Exemple 2: (AIX uniquement) Liaison de processus Db2 à l'un des ensembles de ressources suivants: sys/node.03.00000, sys/node.03.00001, sys/node.03.00002, sys/node.03.00003

<RESOURCE_POLICY>
		<GLOBAL_RESOURCE_POLICY> 
			<METHOD>RSET</METHOD> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00000</RESOURCE> 
			</RESOURCE_BINDING> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00001</RESOURCE> 
			</RESOURCE_BINDING> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00002</RESOURCE> 
			</RESOURCE_BINDING> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00003</RESOURCE> 
			</RESOURCE_BINDING> 
		</GLOBAL_RESOURCE_POLICY> 
	</RESOURCE_POLICY> 

Exemple 3: (Linux uniquement) Lier toute la mémoire des ID de pool de mémoire tampon 2 et 3 associés à la base de données SAMPLE au noeud NUMA 3. Utilisez également 80 % de la mémoire totale de la base de données pour la liaison au nœud NUMA 3 et laissez 20 % segmenté sur tous les nœuds pour la mémoire spécifique à un pool de non-mémoire tampon.

<RESOURCE_POLICY>
		<DATABASE_RESOURCE_POLICY>
			<DBNAME>sample</DBNAME>
			<METHOD>NODEMASK</METHOD>
			<RESOURCE_BINDING>
				<RESOURCE>3</RESOURCE>
				<DBMEM_PERCENTAGE>80</DBMEM_PERCENTAGE>
				<BUFFERPOOL_BINDING>
					<BUFFERPOOL_ID>2</BUFFERPOOL_ID>
					<BUFFERPOOL_ID>3</BUFFERPOOL_ID>
 			</BUFFERPOOL_BINDING>
			</RESOURCE_BINDING>
		</DATABASE_RESOURCE_POLICY>
	</RESOURCE_POLICY>

Exemple 4: (Pour Linux et Windows uniquement) Définissez deux ensembles de processeurs distincts spécifiés par les masques d'UC 0x0F et 0xF0. Liez les processus Db2 et l'ID de pool de mémoire tampon 2 au jeu de processeurs 0x0F et les processus Db2 et l'ID de pool de mémoire tampon 3 au jeu de processeurs 0xF0. Pour chaque ensemble de processeurs, utilisez 50 % de la mémoire totale de la base de données pour la liaison.

Cette règle de ressource est utile lorsqu'un mappage entre des processeurs et des nœuds NUMA est souhaité. Un exemple de ce scénario est un système avec 8 processeurs et 2 nœud NUMA où les processeurs 0 à 3 appartiennent au nœud NUMA 0 et les processeurs 4 à 7 appartiennent au nœud NUMA 1. Cette règle de ressource permet la liaison de processeur tout en conservant implicitement la localisation de la mémoire (c'est-à-dire une méthode hybride de la méthode CPU et de la méthode NODEMASK).

 <RESOURCE_POLICY>
   <DATABASE_RESOURCE_POLICY>
     <DBNAME>sample</DBNAME>
     <METHOD>CPUMASK</METHOD>
     <RESOURCE_BINDING>
       <RESOURCE>0x0F</RESOURCE>
       <DBMEM_PERCENTAGE>50</DBMEM_PERCENTAGE>
       <BUFFERPOOL_BINDING>
         <BUFFERPOOL_ID>2</BUFFERPOOL_ID>
       </BUFFERPOOL_BINDING>
     </RESOURCE_BINDING>
     <RESOURCE_BINDING>
       <RESOURCE>0xF0</RESOURCE>
       <DBMEM_PERCENTAGE>50</DBMEM_PERCENTAGE>
       <BUFFERPOOL_BINDING>
         <BUFFERPOOL_ID>3</BUFFERPOOL_ID>
       </BUFFERPOOL_BINDING>
     </RESOURCE_BINDING>
   </DATABASE_RESOURCE_POLICY>
 </RESOURCE_POLICY>

Exemple 5: (systèmes d'exploitationAIX uniquement) Vous pouvez activer manuellement la fonction de découverte de groupe de ressources en spécifiant des groupes de ressources dans le fichier de stratégie de ressource. Utilisez l'élément RESOURCE_GROUP pour spécifier les ressources appartenant à un groupe de ressources particulier. Les groupes de ressources définis n'ont pas à s'aligner sur les limites NUMA. La colonne RESOURCE_GROUP de la fonction de table ENV_GET_DB2_EDU_SYSTEM_RESOURCES identifie le groupe de ressources auquel un EDU est associé.

<RESOURCE_POLICY>
  <GLOBAL_RESOURCE_POLICY>

    <METHOD>SRAD</METHOD>

    <RESOURCE_GROUP>
      <RESOURCE_GROUP_NAME>TESTGROUP1</RESOURCE_GROUP_NAME>

      <RESOURCE_BINDING>
        <RESOURCE>0</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>1</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>2</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>3</RESOURCE>
      </RESOURCE_BINDING>

    </RESOURCE_GROUP>

    <RESOURCE_GROUP>
      <RESOURCE_GROUP_NAME>TESTGROUP2</RESOURCE_GROUP_NAME>

      <RESOURCE_BINDING>
        <RESOURCE>4</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>5</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>6</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>7</RESOURCE>
      </RESOURCE_BINDING>

    </RESOURCE_GROUP>

  </GLOBAL_RESOURCE_POLICY>
</RESOURCE_POLICY>

Vous pouvez également utiliser les variables de registre DB2PRIORITIES et DB2NTPRICLASS pour contrôler la règle de planification du système d'exploitation et définir les priorités de l'agent Db2 . Toutefois, la spécification d'un élément SCHEDULING_POLICY dans le fichier de configuration de la règle de ressource fournit un emplacement unique pour spécifier à la fois la règle de planification et les priorités d'agent associées.

Exemple 1: Sélection de la règle de planification AIX SCHED_FIFO2 avec une pondération de priorité pour les processus Db2 Log writer and reader.

	<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>

Exemple 2: Remplacement de DB2NTPRICLASS=H sous Windows.

	<RESOURCE_POLICY> 
		<SCHEDULING_POLICY>
			<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
		</SCHEDULING_POLICY>
	</RESOURCE_POLICY>

Cette variable de registre n'est pas prise en charge lorsque le parallélisme intrapartition est activé.

Les modifications apportées à cette variable peuvent prendre effet immédiatement pour toutes les futures instructions SQL compilées si la commande db2set est émise avec le paramètre -immediate . Vous n'avez pas besoin de redémarrer l'instance.

DB2_SKIPDELETED est applicable uniquement lorsque la sémantique validée ne permet pas d'éviter les conflits de verrouillage. Lorsque cette variable est définie et qu'elle est actuellement validée pour une analyse, les lignes supprimées ne seront pas ignorées ; leur version actuellement validée sera traitée à la place

Cette variable de registre n'a pas d'impact sur le comportement des curseurs sur les tables de catalogue Db2 .

Cette variable de registre est activée à l'aide de la commande db2start .

Cette variable de registre n'a aucun effet si des sémantiques actuellement validées sont utilisées. En d'autres cas, même si DB2_SKIPINSERTED a la valeur OFF et que le comportement validé est activé, les lignes insérées non validées sont toujours ignorées.

DB2_SMP_INDEX_CREATE n'a un effet que lorsqu'il est défini sur une valeur différente de zéro. Lorsque vous augmentons le nombre d'agents utilisés pour analyser et trier les données d'index, il est important de s'assurer que les paramètres de configuration de base de données sortheap et sheapthres_shr sont correctement définis. Plus la mémoire est disponible pour le tri (spécifié par le paramètre sheapthres_shr ), le tri moins probable des données d'index requiert l'écriture de résultats temporaires dans un espace table temporaire système. Si le tri ne s'effectue pas sur le disque, il est beaucoup plus rapide. De plus, pour s'assurer que chaque agent participant au tri obtient une quantité égale de mémoire, le paramètre sortheap doit être affecté d'une valeur qui n'est pas supérieure à sheapthres_shr/n, où n est le nombre d'agents utilisés pour analyser et trier la table d'index.

La valeur par défaut de cette variable est -2, ce qui signifie qu'il n'existera pas d'accès au système de fichiers inutile pour les objets temporaires SMS déversés dont la taille est inférieure ou égale à 1 extension * nombre de conteneurs. Les objets temporaires de taille supérieure seront tronqués à l'espace alloué 0.

Lorsque cette variable a la valeur 0, aucun traitement de seuil spécial n'est effectué. En fait, une fois qu'une table temporaire n'est plus nécessaire, ce fichier est tronqué à 0 exstension. Lorsque la valeur de cette variable est supérieure à 0, un fichier plus volumineux est conservé. Les objets plus grands que le seuil seront tronqués à la taille de seuil. Cela réduit les frais généraux du système impliqués dans la suppression et la recréation du fichier chaque fois qu'une table temporaire est utilisée.

Si cette variable a la valeur -1, le fichier n'est pas tronqué et il est autorisé à croître indéfiniment, limité uniquement par les ressources système.

Lorsque DB2_SORT_AFTER_TQ=NO, l'optimiseur a tendance à trier à l'extrémité d'envoi et à fusionner les lignes à la fin de la réception.

Lorsque DB2_SORT_AFTER_TQ=YES, l'optimiseur tend à transmettre les lignes non triées, à ne pas fusionner à la fin de la réception, et à trier les lignes à la fin de la réception après avoir reçu toutes les lignes.

Les modifications apportées à cette variable peuvent prendre effet immédiatement pour toutes les futures instructions SQL compilées si la commande db2set est émise avec le paramètre -immediate . Vous n'avez pas besoin de redémarrer l'instance.

L'espace de travail SQL contient des allocations, sous forme de sections, pour l'exécution de SQL. Chaque instruction SQL (statique ou dynamique) exécutée pour le compte d'une application doit conserver une copie unique de la section dans l'espace de travail SQL pour la durée d'exécution de cette instruction. Une fois l'exécution de l'instruction terminée, la section devient inactive et les allocations de mémoire associées à une section inactive peuvent être libérées ou elles peuvent rester mises en cache dans l'espace de travail SQL. Lorsqu'une nouvelle exécution de la même instruction SQL se produit à partir de n'importe quelle connexion, elle peut trouver une copie en mémoire cache de la section dans l'espace de travail SQL à partir d'une exécution précédente, ce qui permet de réduire les coûts associés à l'allocation et à l'initialisation d'une nouvelle copie de la section. De cette manière, l'espace de travail SQL contient à la fois des sections actives, correspondant aux instructions SQL en cours d'exécution, et des sections mises en cache qui ne sont pas en cours d'exécution.

Lorsque la variable DB2_TRUST_MDC_BLOCK_FULL_HINT est définie, Db2 ignore la recherche d'espace libre dans tout bloc marqué avec le bit Full_Block dans l'index de bloc composite. Ce bit Full_Block n'est qu'un indice car il n'est effacé que lorsque le bloc entier est supprimé et que l'index de bloc composite est régénéré à l'aide de la commande REORG . En contrepartie une partie de l'espace libre peut être gaspillée si les suppressions sont exécutées de manière à vider partiellement les blocs plutôt que de les vider complètement avec la suppression par déploiement. Pour plus d'informations sur les suppressions de déploiement, voir la rubrique « Suppression de déploiement » dans la rubrique « Stratégies d'optimisation pour les tables MDC ».

Lorsque cette variable est activée, il n'y a pas de conversion du format SQLDA externe vers un format Db2 interne lors de la liaison des instructions SQL et XQuery contenues dans une procédure mémorisée non isolée intégrée. Cela accélère le traitement des instructions SQL et XQuery imbriquées.

Les types de données suivants ne sont pas pris en charge dans les procédures mémorisées non isolées lorsque cette variable est activée :

• DATE_TYPE_SQ
• SQL_TYP_TIME
• SQL_TYP_STAMP
• SQL_TYP_CGSTR
• SQL_TYP_BLOB
• SQL_TYP_CLOB
• SQL_TYP_DBCLOB
• SQL_TYP_CSTR
• SQL_TYP_LSTR
• SQL_TYP_BLOB_LOCATOR
• SQL_TYP_CLOB_LOCATOR
• SQL_TYP_DCLOB_LOCATOR
• SQL_TYP_BLOB_FILE
• SQL_TYP_CLOB_FILE
• SQL_TYP_DCLOB_FILE
• SQL_TYP_BLOB_FILE_OBSOLETE
• SQL_TYP_CLOB_FILE_OBSOLETE
• SQL_TYP_DCLOB_FILE_OBSOLETE

Si ces types de données sont rencontrés, une erreur SQLCODE -804, SQLSTATE 07002 est renvoyée.

Pour désactiver la préallocation rapide, affectez à DB2_USE_FAST_PREALLOCATION la valeur OFF. Cela peut améliorer les performances d'exécution, au prix de temps de création d'espace table et de restauration de base de données plus lents, sur certains systèmes d'exploitation, en particulier AIX, lorsqu'il existe un volume important d'insertions et de sélections sur le même espace table. Notez qu'une fois la préallocation rapide désactivée, la base de données doit être redémarrée.

Pour activer la préallocation rapide des journaux, affectez à DB2_USE_FAST_LOG_PREALLOCATION la valeur ON.

• L'utilisation des espaces table gérés par la base de données (DMS) configurés pour l'accès direct au disque (brut) n'est pas prise en charge.
• L'utilisation des espaces table gérés par le système (SMS) configurés avec NO FILESYSTEM CACHING n'est pas prise en charge.
• Il peut exister un impact sur les performances lors de l'accès aux données LOB, en fonction des caractéristiques de charge de travail.
• Il peut exister un impact sur les performances lors de la restauration d'images de sauvegarde ou de fichiers de copie de chargement qui ont été créés avant l'activation de la prise en charge du secteur de 4 Ko.
• Les images de sauvegarde et les fichiers de copie de chargement seront légèrement plus volumineux.
• Cette fonction n'est pas prise en charge pour les instances pureScale® .