ArcGIS 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 sous le répertoire ou dossier ORACLE_BASE/admin/<ORACLE_SID>/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<oracle SID>.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.
Voici des suggestions pour vous aider à définir des paramètres lors de la mise en œuvre d'une géodatabase volumineuse, très utilisée, dans Oracle :
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 à la documentation Oracle 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, ArcGIS 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. N'oubliez pas qu'ArcGIS va ouvrir 80 % du nombre spécifié de curseurs ouverts, ce qui permet aux processus Oracle d'utiliser les 20 % restants.
- Divers curseurs de gestion de données ArcGIS (20) +
- Différents blocs PL/SQL anonymes (20) +
- Requêtes spatiales : 6 requêtes potentielles par classe d'entités +
- Requêtes du fichier journal (11) +
- Diverses requêtes utilisées lors de la mise à jour de tables versionnées—12 par table ou couche versionnée
Par conséquent, si vous modifiez 10 couches dans ArcMap, 231 curseurs sont potentiellement ouverts (20 + 20 + 60 + 11 + 120 = 231). Dans ce cas, le paramètre par défaut 300 OPEN_CURSORS est suffisant, car ArcGIS va maintenir ouverts 240 curseurs avec ce paramètre. Toutefois, si vous manquez souvent de curseurs, vous pouvez augmenter la valeur du paramètre OPEN_CURSORS par incréments de 50 ou 100.
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.
SESSIONS
La géodatabase est configurée de sorte à autoriser des connexions illimitées à la géodatabase. Si vous prévoyez un nombre important de connexions simultanées à la géodatabase, vous devrez sans doute modifier le paramètre SESSIONS Oracle en conséquence.
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 de géodatabase 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.
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. Vérifiez que le paramètre PROCESSES est au moins aussi élevé que le nombre de connexions simultanées prévues à la géodatabase plus 25 pour prendre en compte le nombre habituel de processus Oracle en arrière-plan.
Paramètre affectant les statistiques Oracle
OPTIMIZER_MODE
Conservez la valeur par défaut (all_rows) du paramètre Oracle OPTIMIZER_MODE. 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. En règle générale, il est déconseillé d'allouer plus de 70 % de la mémoire physique du serveur aux bases de données sur le serveur.
SHARED_POOL_SIZE
Le groupe partagé est un composant du bloc SGA (System Global Area) 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 peuvent bénéficier d'un plus grand groupe partagé que celui d'autres applications Oracle. ArcGIS conserve en mémoire un cache d'instructions SQL soumises par les applications clientes. Un groupe partagé plus grand permet à un plus grand nombre de curseurs de rester ouverts, ce qui réduit les opérations de gestion de curseur et améliore les performances. La taille du groupe partagé est contrôlé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.
Utiliser la gestion automatique de la zone de travail et de la mémoire partagée
Vous devriez tirer parti des mécanismes qu'Oracle propose pour gérer automatiquement la zone de travail et l'allocation de mémoire. Pour plus d'informations sur la configuration de la zone de travail et de la gestion de la mémoire, reportez-vous au Guide de l'administrateur de la base de données d'Oracle correspondant à la version d'Oracle que vous utilisez.
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 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.