Desktop Help 10.0 - Paramètres d'initialisation Oracle

ArcSDE ne nécessite pas de modifier la configuration par défaut de l'instance Oracle pour que cette dernière s'exécute. Toutefois, pour les systèmes volumineux, vous pouvez apporter des changements à la configuration de l'instance Oracle.

Chaque fois que vous démarrez une instance Oracle, Oracle lit ses paramètres d'initialisation dans le fichier init.ora ou le fichier de paramètres du serveur, spfile.ora. Ces deux fichiers définissent les caractéristiques de l'instance mais sont gérés différemment.

Le fichier init.ora se trouve dans le répertoire ou dossier ORACLE_BASE/admin/<SID_ORACLE>/pfile. init.ora est généralement un nom attribué au fichier d'initialisation d'une instance de base de données Oracle, mais, pour toute instance donnée, le fichier est en fait nommé init<SID.oracle>.ora. Par exemple, si l'ID du système Oracle (SID) est SIG, le fichier init.ora de cette instance est initGIS.ora.

La modification de paramètres à l'aide de la commande ALTER SYSTEM est automatiquement reflétée dans le fichier de paramètres du serveur si l'instance a été démarrée par cette méthode. Si l'instance a été démarrée à l'aide d'un fichier init.ora, vous devez modifier manuellement le fichier avec un éditeur de texte si vous souhaitez que les changements apportés aux paramètres système affectent plus que l'instance actuelle de la base de données.

Paramètres concernant la mémoire partagée

Cette section décrit certains des paramètres qui contrôlent l'allocation de la mémoire partagée. Pour obtenir une description détaillée des paramètres d'initialisation Oracle, reportez-vous au manuel Oracle Server Tuning de votre version Oracle.

OPEN_CURSORS

Le paramètre d'initialisation OPEN_CURSORS Oracle spécifie le nombre de curseurs pouvant être ouverts simultanément dans une session. La valeur par défaut est 300. Si la session essaie d'ouvrir un nouveau curseur alors que le nombre maximal de curseurs pouvant être ouverts a déjà été atteint, l'erreur -1000 d'Oracle est retournée. Pour améliorer les performances, ArcSDE maintient ouverts les curseurs exécutés fréquemment. Si votre paramètre OPEN_CURSORS Oracle n'est pas défini sur une valeur assez élevée, l'erreur mentionnée ci-dessus se produit. La documentation d'Oracle indique que définir ce paramètre sur une valeur élevée n'entraîne pas d'effets négatifs. Par conséquent, vous pouvez définir une valeur très élevée (par exemple, 2000) ; cela supprime efficacement toute limite affectant le nombre de curseurs ouverts tout en apportant encore une mesure de protection contre un processus malveillant tentant de consommer une quantité excessive de ressources de curseur. Si, à la place, vous souhaitez calculer le nombre potentiel de curseurs ouverts par une session, vous pouvez vous inspirer de la formule suivante, basée sur le modèle de données de votre organisation :

Divers curseurs de gestion de données ArcSDE (20) +
Différents blocs PL/SQL anonymes (20) +
Requêtes spatiales—6 requêtes potentielles par couche +
Requêtes du fichier journal (11) +
Diverses requêtes utilisées lors de la mise à jour de tables multi-versionnées—12 par table ou couche multi-versionnée

Par conséquent, une application ArcMap comportant 10 couches en cours d'édition dans le document peut avoir potentiellement 231 curseurs ouverts (20 + 20 + 60 + 11 + 120 = 231). Si vous manquez souvent de curseurs, vous pouvez augmenter la valeur du paramètre OPEN_CURSORS par incréments de 50 ou 100.

Remarque :

Oracle 10g est préconfiguré pour générer une alerte de serveur lorsque le nombre de curseurs ouverts de l'instance dépasse 1 200. 1 200 curseurs étant souvent ouverts pour la géodatabase, vous pouvez augmenter le seuil de cette alerte pour éliminer la file d'attente d'avertissements non pertinents.

Une situation dans laquelle il peut être nécessaire de diminuer la valeur du paramètre est celle dans laquelle les ressources mémoire du serveur qui exécute l'instance Oracle ne sont pas suffisantes pour chaque processus Oracle dédié. Pour connaître la mémoire requise par les processus dédiés, il est nécessaire de concevoir un prototype de l'application. Plusieurs paramètres Oracle et le comportement de l'application (par exemple, une instruction SQL) peuvent affecter les besoins en mémoire des processus.

SESSION_CACHED_CURSORS

Oracle surveille les instructions SQL qui sont envoyées pour chaque session. S'il détecte que la même instruction a été soumise plusieurs fois, il transfère l'instruction dans le cache de curseurs et maintient le curseur ouvert pour qu'il soit réutilisé. Le paramètre SESSION_CACHED_CURSORS détermine le nombre de curseurs autorisés dans le cache de curseur. La valeur par défaut de SESSION_CACHED_CURSORS varie en fonction de la version d'Oracle. Si votre instance n'est pas configurée pour mettre en cache au moins 50 curseurs, augmentez la valeur de ce paramètre à 50.

UNDO_MANAGEMENT et UNDO_TABLESPACE

Oracle stocke plusieurs copies des données en cours de modification par un utilisateur. Pendant une opération de modification de données, une copie des données d'origine est utilisée afin de fournir une vue cohérente de la base de données pour d'autres sessions. De plus, les utilisateurs effectuant des modifications peuvent annuler leur travail en exécutant une instruction ROLLBACK ou leur processus peut se bloquer au milieu d'une opération, nécessitant qu'Oracle annule leur travail en cours pour restaurer la base de données à un état cohérent.

Pour prendre en charge chacun de ces scénarios, Oracle stocke les données pré-éditées dans une structure de données spéciale ou un segment d'annulation. Vous pouvez définir les paramètres UNDO_MANAGEMENT et UNDO_TABLESPACE de sorte qu'Oracle crée et gère automatiquement les segments d'annulation. Pour activer la gestion automatique des segments d'annulation, définissez d'abord le paramètre UNDO_MANAGEMENT sur auto. Définissez ensuite le paramètre UNDO_TABLESPACE sur le nom du tablespace allant stocker les segments d'annulation gérés par le système.

Sachez que vous ne pouvez utiliser aucun tablespace arbitraire pour stocker les segments d'annulation gérés par le système. Vous devez désigner le tablespace comme tablespace d'annulation lors de la création. Pour plus d'informations sur la surveillance et la gestion du comportement d'annulation automatique, reportez-vous au Guide de l'administrateur de la base de données Oracle.

SESSIONS

ArcSDE est configuré pour autoriser par défaut 48 ou 64 connexions simultanées, selon votre système d'exploitation. Si vous configurez la table de dictionnaire de données SDE.SERVER_CONFIG pour autoriser un plus grand nombre de connexions, il peut être nécessaire de modifier le paramètre SESSIONS Oracle pour prendre en compte le nouveau paramètre.

Le paramètre SESSIONS limite directement le nombre total de sessions simultanées autorisées par Oracle. Si la valeur par défaut est insuffisante pour prendre en charge le nombre de connexions ArcSDE que vous prévoyez, augmentez ce paramètre en le définissant sur le nombre de connexions simultanées anticipées plus un minimum de 10 pour cent supplémentaire pour prendre en charge les fonctions Oracle internes.

Remarque :

Si vous utilisez la configuration de serveur partagée Oracle, le paramètre SHARED_SERVER_SESSIONS se comporte comme le paramètre SESSIONS décrit ci-dessus, à la différence qu'il ne s'applique qu'aux connexions de serveur partagées. Toutes les sessions (de serveur partagées et de serveur dédiées) sont limitées par le paramètre plus global SESSIONS.

PROCESSES

Vous pouvez également limiter le nombre maximal de processus qu'Oracle peut créer à l'aide du paramètre PROCESSES. Lors de l'utilisation de la configuration de serveur dédiée, ce processus correspond approximativement au nombre de sessions simultanées que la base de données prend en charge. Si vous augmentez le nombre de connexions autorisées par ArcSDE, vérifiez que le paramètre PROCESSES est au moins aussi élevé que le nombre de connexions ArcSDE plus 25 pour un ensemble standard de processus d'arrière-plan Oracle.

Paramètre affectant les statistiques Oracle

OPTIMIZER_MODE

Conservez la valeur par défaut du paramètre Oracle OPTIMIZER_MODE. Pour Oracle 10get 11g, la valeur par défaut est all_rows. Ce paramètre fonctionne parfaitement pour la plupart des géodatabases et améliore l'évolutivité globale de votre géodatabase.

Paramètres affectant la mémoire

Soyez prudent lorsque vous définissez les paramètres d'initialisation qui affectent la mémoire. Définir ces paramètres sur une valeur dépassant les limites imposées par les ressources de mémoire physique de la machine hôte dégrade considérablement les performances.

LOG_BUFFER

La zone tampon de journal est un composant du bloc SGA (Oracle System Global Area) qui conserve en mémoire les changements non validés apportés à la base de données jusqu'à ce que les processus d'arrière-plan Oracle puissent écrire ces changements dans une zone de stockage permanent sur le disque. Etant donné que ces écritures sont très fréquentes (au moins toutes les trois secondes), la zone tampon de journal ne requiert pas beaucoup d'espace et sa taille peut être configurée avec une valeur inférieure à un méga-octet. La taille de la zone tampon de journal est déterminée par le paramètre LOG_BUFFER. La taille de la zone tampon de journal par défaut convient à la plupart des géodatabases. Toutefois, dans le cas des géodatabases présentant une activité d'écriture importante, les performances peuvent être affectées par plusieurs utilisateurs tentant d'accéder simultanément à la zone tampon de journal. Diagnostiquer et atténuer cette condition requiert des compétences avancées, telles que la surveillance des verrous et des événements d'attente. Pour plus d'informations, reportez-vous au manuel Oracle Database Performance Tuning Guide et à la base de connaissances MetaLink.

Remarque :

Définir le paramètre LOG_BUFFER sur une valeur élevée pour traiter des opérations de chargement volumineuses peut en fait réduire les performances. Des conflits de verrou entre les opérations peuvent se produire si la zone tampon de journal est définie sur une valeur trop élevée.

SHARED_POOL_SIZE

Le groupe partagé est un autre composant du bloc SGA Oracle contenant à la fois le cache de dictionnaire de données et le cache de bibliothèque. Le cache de dictionnaire de données contient des informations sur les objets de données, l'espace libre et les privilèges. Le cache de bibliothèque contient les instructions SQL analysées le plus récemment. En général, si le groupe partagé est assez grand pour satisfaire les besoins en ressources du cache de bibliothèque, il est déjà assez grand pour contenir le cache de dictionnaire de données. Les géodatabases ArcSDE peuvent bénéficier d'un plus grand groupe partagé que celui d'autres applications Oracle. ArcSDE conserve en mémoire un cache d'instructions SQL soumises par les applications clientes. Un grand groupe partagé permet à plus de curseurs de rester ouverts, ce qui se traduit par une réduction des opérations de gestion des curseurs et une amélioration des performances. La taille du groupe partagé est déterminée par le paramètre SHARED_POOL_SIZE. ESRI vous recommande de définir le paramètre SHARED_POOL_SIZE sur un multiple de 16 Mo pour permettre les prises en charge système ESRI et de définir ce paramètre sur au moins 128 Mo :

shared_pool_size = 128,000,000

Les géodatabases très actives qui prennent en charge les utilitaires volatiles ou les systèmes d'édition de parcelles peuvent nécessiter que SHARED_POOL_SIZE soit défini sur une valeur aussi élevée que 250 Mo

Parmi les trois zones tampon SGA, le groupe partagé est le plus important. Si le bloc SGA est déjà grand au point de pouvoir avoir la taille de votre mémoire physique, réduisez la taille du cache de zone tampon pour prendre en compte un groupe partagé plus grand.

DB_CACHE_SIZE

Le cache de zone tampon est un autre composant du bloc SGA Oracle et stocke les blocs de données utilisés le plus récemment. Les blocs de données constituent l'unité atomique d'Oracle pour le transfert de données. Oracle lit et écrit des blocs de données vers et depuis la base de données chaque fois que l'utilisateur édite ou interroge la base de données. La taille du cache de zone tampon est contrôlée par le paramètre DB_CACHE_SIZE.

Contrairement au groupe partagé et à la zone tampon de journal, aucune taille minimale n'est particulièrement recommandée pour le cache de zone tampon. Dans la mesure o_, lorsque vous choisissez la taille du cache de zone tampon, votre objectif est de conserver en mémoire une partie aussi grande que possible de la base de données, envisagez d'allouer toute la mémoire restante au cache de zone tampon une fois les besoins des autres composants du système pris en compte. Pour estimer ceci, suivez ces étapes :

Déterminez combien de mémoire RAM physique votre serveur possède.
Multipliez ce nombre par 0,66 pour déterminer la taille cible du bloc SGA.
Déduisez les valeurs de SHARED_POOL_SIZE et LOG_BUFFER pour retourner la quantité de mémoire disponible au cache de zone tampon.
Réduisez ce nombre de 10 pour cent pour prendre en compte l'utilisation interne de mémoire par Oracle.
Divisez le nombre par la taille de bloc de la base de données pour déterminer la valeur du paramètre DB_BLOCK_BUFFERS.

Par exemple :

memory available to SGA = physical RAM * 2/3

memory available to buffer cache
= (memory available to SGA - (shared_pool_size + log_buffer)) * 0.9

db_block_buffers 

= memory available to buffer cache / db_block_size

PGA_AGGREGATE_TARGET

Allouez de l'espace au bloc PGA (Private Global Area) des processus de serveur Oracle. Cet espace est généralement utilisé comme zone tampon temporaire pour trier et fusionner des données pendant une opération de jointure de table. Définissez le paramètre WORKAREA_SIZE_POLICY sur AUTO, puis le paramètre PGA_AGGREGATE_TARGET sur la mémoire RAM physique totale multipliée par 0,16. Après avoir utilisé l'application pendant un certain temps, configurezle paramètre PGA_AGGREGATE_TARGET selon la procédure décrite dans le manuel Oracle Performance Tuning Guide and Reference.

workarea_size_policy = auto
pga_aggregate_target = <total physical RAM * 0.16)

Remarque :

Oracle utilise le paramètre PGA_AGGREGATE_TARGET afin d'allouer la mémoire uniquement pour le tri si le paramètre WORKSPACE_POLICY est défini sur AUTO. Si cela n'est pas le cas, Oracle utilise la méthode manuelle la plus ancienne de gestion de surface de tri, qui inclut la définition des paramètres SORT_AREA_SIZE et HASH_AREA_SIZE.

Utiliser la gestion automatique de zone de travail

Oracle peut gérer la mémoire privée pour les processus serveur qui traitent automatiquement les sessions utilisateur, de manière très similaire à la manière dont il gère la mémoire partagée avec la gestion automatique de la mémoire partagée (ASMM). Les zones de travail SQL de tri, de hachage et de traitement d'index de bitmaps peuvent être allouées dynamiquement par Oracle à partir d'un regroupement de mémoire volumineux disponible pour tous les blocs PGA plutôt que d'être configurées avec une taille fixe par l'administrateur de base de données. Pour activer la gestion automatique de zone de travail, définissez le paramètre WORKAREA_SIZE_POLICY sur AUTO. Configurez ensuite la quantité de mémoire totale disponible pour tous les blocs PGA en spécifiant la taille comme valeur pour le paramètre PGA_AGGREGATE_TARGET. Par défaut, Oracle configure la taille globale de bloc PGA sur 20 pour cent de la taille du bloc SGA. Ceci constitue un bon point de départ, même si le bloc PGA devrait être dimensionné selon le type de travail effectué par les processus serveur et pas strictement par rapport à la taille du bloc SGA. Une fois que votre base de données s'exécute sous une charge normale, vous pouvez surveiller et configurer avec précision la taille de la cible PGA selon la charge de travail réelle. Pour en savoir plus sur ce processus, reportez-vous au manuel Oracle Database Performance Tuning Guide.

Utilisation de la gestion automatique de la mémoire partagée

Si vous utilisez Oracle 10g, vous avez la possibilité de configurer une taille totale pour le bloc SGA et de laisser Oracle gérer automatiquement la distribution de la mémoire parmi ses groupes constituants. Il s'agit du processus de gestion ASMM, appelé avec le paramètre SGA_TARGET. En plus de simplifier la tâche de l'administrateur de base de données liée à la configuration individuelle des groupes, la gestion ASMM permet à Oracle de surveiller continuellement les demandes au niveau de chaque groupe et d'ajuster dynamiquement la taille des groupes pendant que l'instance s'exécute. Exécuter ce même niveau de supervision de manière continue ne serait pas pratique pour l'administrateur de base de données. Vous pouvez fournir des directives pour la gestion ASMM en configurant à la fois le paramètre SGA_TARGET pour spécifier la taille totale du bloc SGA et un ou plusieurs paramètres pour les groupes individuels. Lorsque le paramètre SGA_TARGET et une taille de groupe sont spécifiés, Oracle interprète la taille de groupe comme valeur minimale que la gestion ASMM conserve pour ce cache.

En raison de l'importance du groupe partagé pour les performances de géodatabase, lorsque vous utilisez la gestion ASMM, définissez la taille de groupe partagé minimale (le paramètre d'initialisation SHARED_POOL_SIZE) sur au moins 128 Mo comme recommandé ci-dessus, en plus de définir SGA_TARGET.

Remarque :

Pour que vous puissiez utiliser la gestion automatique de zone de travail et de mémoire partagée, le paramètre STATISTICS_LEVEL doit être défini sur TYPICAL (la valeur par défaut et recommandée) ou ALL.

Autres modifications

Bien qu'il ne s'agisse pas d'un paramètre d'initialisation, le paramètre de gestionnaire de ressources de base de données UNDO_POOL peut être défini pour allouer à un groupe de consommateurs d'un utilisateur sde un grand espace d'annulation pour les opérations de compression.

Pour ce faire, vous devez configurer un groupe de consommateurs pour l'utilisateur sde et modifier le paramètre UNDO_POOL afin d'autoriser un groupe d'annulation illimité pour ce groupe de consommateurs.

UNDO_POOL identifie la quantité totale d'espace d'annulation que les membres d'un groupe de ressources, collectivement, peuvent allouer simultanément.

Lorsque vous utilisez une géodatabase multi-versionnée pour la mise à jour, vous devez exécuter une opération de compression périodiquement pour purger les informations anciennes et simplifier le contenu de la géodatabase. Si un grand nombre de mises à jour ont été effectuées depuis la dernière opération de compression, la nouvelle procédure de compression peut générer des opérations importantes nécessitant un espace d'annulation volumineux. Si UNDO_POOL est défini sur une valeur trop faible, l'opération de compression peut échouer et les performances peuvent devenir médiocres. Si possible, définissez un groupe d'annulation illimité pour le groupe de consommateurs de l'utilisateur sde. Dans le cas contraire, vous devrez surveiller la taille des opérations de compression et choisir une taille de groupe d'annulation appropriée.

7/10/2012