ArcGIS Server Java Help - Réduction des conflits d'E/S de disque dans DB2

Les conflits d'E/S de disque dans une base de données IBM DB2 sont limités en organisant correctement les composants de la base de données dans le système de fichiers. Finalement, l'administrateur de base de données doit réduire les cas où un processus attend qu'un autre termine sa requête d'E/S. Cette situation est souvent nommée attente d'E/S.

Voici quelques recommandations pour vous aider à éviter les conflits d'E/S de disque.

Pour les tablespaces d'utilisateur temporaires, utilisez le type SMS ; pour tous les autres tablespaces, utilisez le type DMS.
Il existe deux types de modèle de stockage de tablespace dans DB2 : SMS (System Managed Space) et DMS (Database Managed Space). ESRI vous recommande d'utiliser le type SMS pour les tablespaces d'utilisateur temporaires et le type DMS pour les autres tablespaces afin d'obtenir de meilleures performances, en particulier si la quantité de vos données est amenée à augmenter régulièrement.
Remarque :

Dans DB2 9, vous avez besoin d'une table temporaire globale DB2 supplémentaire (DECLARE GLOBAL TEMPORARY TABLE). Selon la documentation DB2, la déclaration de tables temporaires globales nécessite des privilèges SYSADM ou DBADM ou le privilège USE sur un tablespace USER TEMPORARY.

Dans le cas de DB2 9, il est conseillé de recourir aux entités de stockage automatique pour les bases de données, ainsi que d'incorporer les attributs de dimensionnement automatique pour les tablespaces. Dans DB2 9, les tablespaces DMS peuvent fournir un stockage supplémentaire à mesure que les exigences physiques augmentent.
Configurez des pools de mémoires tampons.
Configurer des pools de mémoires tampons est vital pour les performances. Par défaut, DB2 fournit un groupe de zones tampons unique, appelé IBMDEFAULTBP. Dans DB2 9, le groupe de zones tampons IBMDEFAULTBP est configuré, par défaut, pour le dimensionnement automatique. Le gestionnaire de base de données règle la taille de ce groupe de zones tampons en fonction des exigences en termes de charge de travail.

Créez un pool de mémoires tampons séparé pour chaque tablespace. Dans l'instantané de base de données, vérifiez les valeurs de lectures physiques du pool de mémoires tampons. Le pool de mémoires tampons doit être suffisamment grand pour que la capture d'un retraçage de carte entraîne un petit nombre de lectures physiques. Pour déterminer l'efficacité d'un groupe de zones tampons, calculez son taux BPHR (Buffer Pool Hit Ratio). Un BPHR idéal se situe au-delà de 90 %. La formule est la suivante :
```
BPHR (%) = (1 - (("Buffer pool data physical reads" 
+ "Buffer pool index physical reads")
 / ("Buffer pool data logical reads" 
+ "Buffer pool index logical reads"))) * 100
```
Une autre méthode d'analyse des taux BPHR consiste à utiliser la vue d'administration SYSIBMADM.BP_HITRATIO. Cette vue peut renvoyer des taux d'activité, y compris le taux d'activité total, le taux d'activité de données, le taux d'activité XDA et le taux d'activité d'index pour tous les groupes de zones tampons.
```
SELECT SUBSTR(DB_NAME,1,8) AS DB_NAME, 	
SUBSTR(BP_NAME,1,140) AS BP_NAME,
TOTAL_HIT_RATIO_PERCENT, 
DATA_HIT_RATIO_PERCENT, 	
INDEX_HIT_RATIO_PERCENT, 
XDA_HIT_RATIO_PERCENT, DBPARTITIONNUM
FROM SYSIBMADM.BP_HITRATIO
ORDER BY DBPARTITIONNUM
```
Définissez la taille de table seuil.
En règle générale, stockez les petites tables ensemble dans le même tablespace et les grandes tables seules dans leurs propres tablespaces. Décidez de la taille qu'une table doit atteindre avant de nécessiter son propre tablespace. En général, le seuil correspond en partie à la taille de conteneur maximale. Les tables capables de remplir le conteneur de taille maximale doivent être stockées dans leur propre tablespace. Les tables qui approchent cette limite doivent également être considérées comme stockables. Suivez la même stratégie pour les index. Séparez les tables et les index nécessitant leur propre tablespace de ceux allant être regroupés. Ne stockez jamais les tables volumineuses ou faisant l'objet de nombreux accès et leurs index ensemble, dans le même tablespace. Si vous utilisez DB2 9, il est conseillé d'incorporer des attributs de stockage automatique (Automatic Storage) pour les tablespaces.
Stockez les petites tables et les petits index par accès.
Basez votre décision sur les petites tables à stocker ensemble dans le même tablespace selon l'accès prévu. Stockez les tables à accès élevé dans un tablespace et celles à accès faible dans un autre. Vous pouvez ainsi positionner les conteneurs des tablespaces à accès élevé avec les conteneurs à accès faible. Cette même règle s'applique aux index. Eux aussi doivent être répartis par accès. Idéalement, les journaux DB2 doivent posséder leurs propres disques, séparés des index et des données. ESRI recommande de définir la valeur MAXUPROC du paramètre de noyau du système d'exploitation sur une valeur plus élevée que la valeur par défaut afin que tous les processus dont disposent les utilisateurs des instances ArcSDE et DB2 puissent s'exécuter lorsqu'ils sont invoqués.
Pour les systèmes d'exploitation AIX, désactivez db2set DB2_MMAP_READ et db2set DB2_MMAP_WRITE.
Sur AIX, ESRI recommande de désactiver les variables suivantes pour améliorer les performances. Ces variables sont utilisées conjointement pour permettre à DB2 d'utiliser une plate-forme d'accès multi-fonctions et multi-services (MMAP) comme méthode alternative d'E/S. Ceci permet d'éviter les verrous de système d'exploitation lorsque plusieurs processus écrivent des données dans différentes sections du même fichier. La valeur par défaut est ON.
```
db2set DB2_MMAP_READ=OFF
db2set DB2_MMAP_WRITE=OFF
```
Séparez les tables STATES, STATE_LINEAGES et MVTABLES_MODIFIED des tablespaces système ArcSDE et leurs index si vous utilisez considérablement la mise à jour versionnée.
Les tablespaces système ArcSDE stockent les tables et les index système ArcSDE et de géodatabase créés par la commande ArcSDE sdesetup. Le nombre et le placement des tablespaces dépendent de l'objectif pour lequel vous projetez d'utiliser la base de données ArcSDE. Le placement de ces tables et de leurs index est contrôlé par les paramètres de stockage du mot-clé de configuration DBTUNE DATA_DICTIONARY. Le mot-clé DATA_DICTIONARY est utilisé exclusivement pour la création des tables système ArcSDE et de géodatabase. Les bases de données versionnées qui prennent en charge les applications ArcGIS présentent une arborescence d'état très active. L'arborescence d'état maintient les états de toutes les opérations de mise à jour qui se sont produites sur les tables inscrites comme versionnées. Quatre tables système ArcSDE (STATES, STATE_LINEAGES, MVTABLES_MODIFIED et VERSIONS) maintiennent les informations d'opération de l'arborescence d'état de la base de données versionnée. Dans une base de données versionnée active, la table STATES_LINEAGE peut aisément dépasser le million d'enregistrements et occuper plus de 26 Mo de tablespace. La table STATES est beaucoup plus petite et stocke approximativement 5 000 enregistrements, occupant environ 2 Mo de tablespace. La table MVTABLES_MODIFIED contient généralement autour de 50 000 enregistrements, occupant approximativement 1 Mo de tablespace. La table VERSIONS est habituellement très petite, avec moins que 100 lignes occupant environ 64 Ko. Pour les applications ArcGIS de mise à jour très actives, les tables STATES, STATE_LINEAGES et MVTABLES_MODIFIED et leurs index doivent être créés dans des tablespaces séparés et positionnés dans le système de fichiers pour minimiser les conflits d'E/S de disque.
Remarque :

Si vous n'avez pas l'intention d'utiliser une base de données versionnée, réduisez les tailles d'étendue des tables STATE_LINEAGES, STATES et MVTABLES_MODIFIED et de leurs index à 40 Ko. Créez deux tablespaces de 5 Mo sur des lecteurs de disque séparés (un pour les tables et un autre pour les index).
Créez des tablespaces assez grands pour les tables raster et un tablespace distinct pour la table de blocs raster (BLK).
La table de blocs raster peut être très grande. Assurez-vous de créer un grand tablespace séparé pour stocker cette table. Vous pouvez créer un autre tablespace pour stocker les tables raster restantes. Lorsque vous créez les tablespaces pour la table de blocs raster, il est recommandé d'utiliser une taille d'étendue de 64 Ko et une taille de page de 32 Ko. La taille d'étendue spécifie le nombre de pages de taille de page qui seront écrites dans un conteneur avant passage au conteneur suivant.
Attention :

La taille d'étendue est définie lors de la création du tablespace et est difficilement modifiable par la suite.
Lors du chargement de gros volumes de données (par exemple, des données raster), définissez la base de données pour utiliser la consignation circulaire.
La consignation circulaire utilise un jeu de fichiers journaux pour enregistrer les modifications apportées à la base de données. Lorsque le dernier fichier journal du jeu est rempli, le premier fichier est réutilisé. Les informations de transaction pouvant être remplacées, lorsque vous utilisez la consignation circulaire, la récupération de réimplémentation des modifications n'est pas possible ; toutefois, la récupération n'est généralement pas requise lors du chargement de données. La consignation circulaire est le modèle de consignation par défaut. Si vous devez utiliser la récupération de réimplémentation des modifications, utilisez la consignation d'archive. La consignation d'archive ne remplace pas les fichiers journaux mais elle crée des journaux supplémentaires pour enregistrer toutes les transactions effectuées depuis la dernière sauvegarde. Notez que vous aurez besoin de plus d'espace disque pour utiliser la consignation d'archive car les journaux ne sont pas réutilisés comme dans le cas de la consignation circulaire.

Même après avoir réglé votre base de données pour limiter les conflits d'E/S de disque, des arrêts fatals peuvent encore se produire. Pour plus d'informations sur les arrêts fatals, reportez-vous à la rubrique Arrêts fatals dans une base de données DB2.

3/6/2012