Réduction des conflits d'E/S de disque dans Oracle

Parmi tous les composants configurables d'une géodatabase, le stockage est peut-être le plus fréquemment et le plus largement personnalisé. Chaque administrateur de base de données (DBA) a sa méthode préférée pour organiser les structures de stockage physique et logique de la base de données Oracle en fonction de recherches et de techniques qui ont depuis longtemps fait leurs preuves.

Vous avez toute latitude pour concevoir un modèle de stockage de votre géodatabase conforme aux besoins spécifiques de vos données et de vos applications et aux politiques de gestion existantes. ArcSDE présente peu de conditions de stockage strictes. Vous pouvez choisir de déployer un ordinateur d'entrée de gamme avec un seul disque de données et un seul tablespace pour les données SIG, ou bien un serveur haut de gamme comportant des dizaines d'unités multidisques et des centaines de fichiers Oracle, chacun prenant efficacement en charge l'environnement qui lui est destiné. Vous avez la chance de pouvoir adapter ArcSDE et Oracle pour tirer parti de toutes les ressources disponibles pour faire fonctionner votre géodatabase.

Pour réduire les conflits d'E/S de disque pour les bases de données Oracle, vous pouvez placer les fichiers fréquemment utilisés sur des disques séparés, le cas échéant, et regrouper ces fichiers et ceux rarement utilisés sur les mêmes disques. Pour cela :

1. Estimez la taille de tous les composants de base de données et déterminez leurs taux relatifs d'accès.
2. Placez les composants en fonction de l'espace disque disponible et de la taille et du nombre des lecteurs de disque.

Etablir un diagramme des lecteurs de disque et les étiqueter avec les composants permet de conserver la trace de l'emplacement de chaque composant. Ayez le diagramme à portée de main lorsque vous créez votre base de données.

Quelques recommandations sur la façon d'éviter les conflits de ressources sur une géodatabase ArcSDE stockée dans Oracle sont proposées ci-dessous. Pour obtenir une description des composants Oracle abordés ici, tels que les tablespaces et les segments, consultez votre documentation Oracle.

• Gardez une conception de base de données aussi simple que possible.

  Cela ne signifie pas que votre conception doit être fondamentalement simple, mais seulement que cette complexité éventuelle doit être due à la complexité des données que vous modélisez, et non à des décisions arbitraires. Commencez par un seul tablespace pour votre géodatabase, puis justifiez et documentez chaque tablespace supplémentaire créé. Le fait de documenter l'objectif de chaque tablespace s'avère non seulement utile pour toute personne amenée à travailler sur le système (vous compris), mais, en outre, cela vous oblige à étudier plus attentivement les avantages de chaque tablespace supplémentaire à gérer.

• Séparez les segments système des segments utilisateur.

  Séparer les segments utilisateur (par exemple, les classes d'entités) des segments système (par exemple, les dictionnaires de données ArcSDE et Oracle) simplifie la gestion du quota et évite la fragmentation qui est susceptible de réduire les performances. En outre, il est logiquement plus facile de surveiller l'activité au niveau du tablespace lorsque ces segments sont stockés indépendamment.

• Séparez les données des différents projets.

  L'utilisation de tablespaces dédiés pour les différents projets, services ou autres entités logiques peut faciliter la surveillance et la gestion. Ainsi, les opérations de restauration qui concerneront le tablespace d'un projet ne mettront pas un autre projet hors ligne. Vous pouvez attribuer des quotas illimités sur un ensemble de tablespaces des utilisateurs d'un service sans que ceux-ci ne risquent d'utiliser entièrement l'espace alloué à un autre service. Il est plus facile de faire le lien entre l'activité d'E/S ou l'augmentation du volume des fichiers et des équipes ou des personnes lorsque ces entités utilisent leurs propres tablespaces.

• Séparez les segments volumineux des petits segments.

  Vous pouvez appliquer des tailles d'étendue au niveau du tablespace plutôt qu'uniquement au niveau du segment. Utiliser une taille d'étendue uniforme pour tous les segments d'un tablespace élimine la fragmentation de l'espace libre et favorise des performances élevées. Toutefois, cela nécessite de regrouper les segments par taille d'étendue pour équilibrer le nombre d'étendues par segment, ce qui fait perdre de l'espace du fait de tailles d'étendue excessives. Une taille d'étendue de 128 Ko pour les petites tables, de 1 Mo pour les classes d'entités volumineuses et de 128 Mo pour les rasters volumineux est raisonnable, mais vous pouvez personnaliser ces valeurs en fonction de votre environnement et de vos objectifs.

• Séparez les données en lecture seule des données accessibles en écriture.

  Si un tablespace contient uniquement des données en lecture seule, vous pouvez lui attribuer explicitement le mode lecture seule. Cela réduit le volume de données à sauvegarder régulièrement. Les fichiers de données en lecture seule présentent aussi l'avantage de pouvoir être facilement stockés dans une configuration de disques RAID de type 5 et de bénéficier du stripping (entrelacement) pendant l'accès en lecture, évitant ainsi un nombre d'opérations d'écriture trop élevé qui réduirait les performances des disques.

• Utilisez plusieurs disques ou baies pour stocker les fichiers.

  Les fichiers Oracle importants, tels que les fichiers de contrôle, les fichiers journaux de restauration en ligne et les fichiers journaux de restauration archivés, doivent être multiplexés ou mis en miroir par le logiciel Oracle pour une protection maximale.

  Attention :

  Les fichiers de contrôle enregistrent les informations critiques telles qu'une liste de fichiers participant à la base de données. Les fichiers journaux de restauration en ligne et archivés conservent la trace des modifications apportées à la base de données à des fins de restauration. Il est difficile ou impossible de récupérer entièrement une base de données sans disposer de copies de ces fichiers.

  Même sur les serveurs de base de données comportant une baie de stockage à un seul volume, un disque interne autonome est habituellement disponible pour stocker le système d'exploitation, le fichier de page et les exécutables ArcSDE et Oracle. Utilisez ce disque pour stocker les fichiers journaux de restauration et les fichiers de contrôle multiplexés.

• Si vous utilisez le stockage RAID, utilisez ses types de manière appropriée.

  Le type RAID est une classe de services de gestion de stockage. Il existe plusieurs stratégies RAID générales. Ces stratégies sont signalées par un numéro, ou niveau RAID. Ces niveaux sont les suivants : RAID 0, ou entrelacement, stocke de petites portions du même système de fichiers sur différents disques physiques dans des unités appelées bandes. Ce niveau améliore les performances. En répartissant le contenu du système de fichiers sur différents périphériques, le contrôleur RAID peut lire et écrire sur plusieurs disques à la fois. L'inconvénient du niveau RAID 0 est que lorsqu'un disque de la grappe est hors ligne, l'ensemble de la grappe est indisponible.

  RAID 1, ou écriture miroir, stocke sur un disque une copie dupliquée de chaque donnée écrite sur un autre disque. L'avantage de l'écriture miroir est qu'elle protège les données. Une base de données peut perdre un disque sans perte de données ni dégradation de service au moment de la panne. C'est pourquoi le niveau RAID 1 est utilisé avec de nombreuses géodatabases, en particulier avec celles qui nécessitent un haut niveau de disponibilité. L'inconvénient de ce niveau réside dans son prix. Les données étant stockées deux fois, il faut deux fois plus de disques que nécessaire pour stocker les mêmes informations, à l'inverse des disques entrelacés ou autonomes. Ce système présente également une petite pénalité d'écriture due à la nécessité d'écrire des données dupliquées. RAID 10, également appelé RAID 1+0, combine les avantages des deux niveaux, RAID 0 et 1. RAID 10 répartit les données de bandes sur différents ensembles de disques en mode miroir. Ainsi, il offre les performances de RAID 0 et la protection des données de RAID 1. RAID 10, ainsi que les modèles développés propres aux fournisseurs basés sur la stratégie RAID 10, offre les meilleures performances d'E/S pour les géodatabases très sollicitées.

  RAID 10 coûte cher, car il nécessite du matériel supplémentaire pour stocker les données en mode miroir. Vous pouvez envisager d'utiliser RAID 10 de manière sélective pour protéger vos fichiers les plus sollicités et leur fournir de hauts niveaux de performances, et choisir d'autres configurations RAID ou autonomes pour les données en lecture seule, archivées ou moins souvent modifiées. Si vous pouvez vous permettre d'utiliser RAID 10 pour l'ensemble du stockage de vos bases de données, n'hésitez pas. Sinon, envisagez de combiner plusieurs configurations RAID et de disques autonomes pour obtenir la meilleure fiabilité et les meilleures performances pour le matériel à votre disposition. Chaque fois que vous le pouvez, stockez les fichiers en écriture les plus sollicités sur des dispositifs de type RAID 1 ou RAID 10. Ces fichiers incluent les journaux de restauration et les fichiers de données des tablespaces d'annulation. Si nécessaire, utilisez des disques autonomes avec le multiplexage Oracle et une stratégie de sauvegarde complète.

  RAID 5, également appelé entrelacement avec parité rotative, requiert l'équivalent d'un seul disque supplémentaire sur la totalité de la grappe pour le stockage des informations redondantes. Pour cela, RAID 5 entrelace les données sur plusieurs disques, puis stocke une portion d'informations de parité supplémentaire pour l'ensemble de la bande. Si un disque de la grappe est hors ligne, le processeur RAID peut reconstruire les données manquantes à partir des disques restants et des informations de parité. L'avantage de RAID 5 est qu'il améliore les performances de lecture en utilisant l'entrelacement et qu'il offre une redondance à faible coût en faisant appel aux informations de parité plutôt qu'au mode miroir complet. Etant donné que les géodatabases ont tendance à être lues de manière intensive, RAID 5 est bien adapté aux applications de géodatabase, en particulier lorsqu'une disponibilité modérément importante est requise.

  Cependant, du fait que RAID 5 ne stocke pas les informations entièrement redondantes, les pertes de données sont plus probables qu'avec RAID 10. Bien que de telles occurrences soient rares, si deux disques d'une matrice RAID 5 sont hors ligne simultanément, la matrice ne dispose pas de suffisamment d'informations pour reconstruire les données manquantes, si bien que l'ensemble du volume passe hors ligne. Les performances peuvent également être altérées dans deux cas : lors de l'écriture des données dans la grappe, les informations de parité doivent également être calculées et stockées. En outre, lorsqu'un lecteur est hors ligne, les performances de lecture et d'écriture diminuent fortement pendant que le processeur RAID reconstruit les données du disque manquant à la volée. Pour une géodatabase très active, la capacité de traitement disponible pendant ces événements peut être insuffisante pour fournir un niveau de service acceptable.

• Utilisez la fonctionnalité ASM d'Oracle.

  Oracle 10g a introduit la fonctionnalité ASM (Automated Storage Management). ASM est essentiellement un système RAID optimisé et dédié à la maintenance des bases de données Oracle. Cette fonctionnalité utilise une instance Oracle pour fragmenter les requêtes d'E/S de données en un groupe de partitions brutes géré comme un groupe de disques. Ces groupes peuvent fournir l'entrelacement, le mode miroir ordinaire et un mode miroir spécial appelé haute redondance qui stocke trois copies des données au lieu des deux habituelles.

• Utilisez une valeur PCTFREE faible pour les données en lecture seule.

  Oracle vous permet de réserver une certaine quantité d'espace libre dans chaque bloc de données lors de l'insertion de nouvelles données dans une table. Une fois que la limite d'espace libre d'un bloc est atteinte, Oracle n'insère pas de données supplémentaires dans ce bloc. Cet espace libre peut être utilisé uniquement pour les mises à jour de lignes existantes stockées dans le bloc. En réservant de l'espace uniquement pour les opérations de mise à jour, vous pouvez empêcher les lignes de dépasser l'espace disponible dans leur bloc d'origine et de devoir effectuer une migration vers un nouveau bloc. La migration est une opération coûteuse pour la ligne, à la fois lors de la mise à jour et lorsqu'elle est utilisée dans des opérations ultérieures telles que les requêtes.

  De nombreuses géodatabases sont mises à jour peu fréquemment, soit parce que les tables sont statiques (comme cela est très souvent le cas avec les rasters), soit parce qu'elles sont éditées dans un workflow multi-versionné, dans lequel les opérations doubles de suppression et d'insertion se substituent aux mises à jour réelles.

  Aussi, pour optimiser la quantité d'espace disponible dans chaque bloc pour le stockage des données de géodatabase, ArcSDE est préconfiguré pour ne pas réserver d'espace libre en définissant le paramètre PCTFREE sur 0 dans les chaînes de stockage de la table DBTUNE. Si vous souhaitez réserver de l'espace libre pour les mises à jour SQL effectuées par les applications personnalisées, modifiez les valeurs PCTFREE dans la configuration par défaut de la table DBTUNE. Pour en savoir plus sur la configuration de DBTUNE, reportez-vous aux rubriques Qu'est-ce que la table DBTUNE ?, Que sont les mots-clés et les paramètres de configuration DBTUNE ? et Paramètres de configuration DBTUNE Oracle.