Optimisation de la mémoire dans Oracle

Voici quelques règles générales concernant la configuration du bloc Oracle SGA (System Global Area) et les structures de mémoire qui ont un impact sur la taille du bloc PGA (Private Global Area) d'un utilisateur Oracle. Un bloc SGA est un bloc de mémoire partagée qu'Oracle alloue et partage avec toutes les sessions. Pour plus d'informations sur le bloc SGA, reportez-vous au manuel Oracle Concepts Guide de votre version Oracle.

• Le bloc SGA ne doit pas être trop grand.

  Ne créez pas un bloc SGA dont la taille dépasse les deux tiers de la taille de la mémoire RAM physique de votre serveur. Votre mémoire virtuelle doit pouvoir traiter à la fois le bloc SGA et les besoins de tous les processus actifs du serveur.

• Evitez la pagination excessive.

  A l'aide des outils de votre système d'exploitation (vmstat sous UNIX et le Gestionnaire de tâches sous Windows), vérifiez que la pagination n'est pas excessive. Un degré élevé de pagination peut résulter en un bloc SGA trop grand.

• Configurez assez de mémoire virtuelle.

  En règle générale, Oracle recommande que l'espace d'échange soit égal à au moins trois à quatre fois la taille de la mémoire RAM physique. La taille requise du fichier d'échange sous UNIX ou du fichier de page sous Windows dépend du nombre de sessions ArcSDE actives. Pour chaque session de service (serveur d'applications) ArcSDE, un processus gsrvr et un processus Oracle correspondant sont démarrés. Pour déterminer l'utilisation de la mémoire par ces processus, utilisez la commande ps –elf sous UNIX ou l'onglet Processus du Gestionnaire de tâches sous Windows. Vous devez déduire la taille du bloc SGA Oracle à partir des processus utilisateur Oracle. La taille totale des processus gsrvr et giomgr ArcSDE, utilisateur Oracle, d'arrière-plan Oracle, du système d'exploitation et de tout autre processus s'exécutant sur le serveur doit tenir dans la mémoire virtuelle.

  Pour les applications clientes ArcSDE qui se connectent directement à une instance Oracle, le processus gsrvr n'existe pas. De plus, si le service ArcSDE n'est pas utilisé car toutes les applications clientes se connectent directement à l'instance Oracle, le processus giomgr n'est pas démarré non plus. Pour cette raison, les connexions directes ont un impact mémoire moindre sur le serveur car le processus gsrvr est absent. Les paramètres qui ont un impact sur la mémoire sont LOG_BUFFERSHARED_POOL_SIZE, DB_CACHE_SIZE, PGA_AGGREGATE_TARGET, SGA_TARGET et WORKAREA_SIZE_POLICY.

  Pour obtenir une explication de ces paramètres et connaître les valeurs qu'il est recommandé de leur attribuer, reportez-vous à la rubrique Paramètres d'initialisation Oracle.

• Utilisez des quotas explicites sur les tablespaces pour éviter d'utiliser tout l'espace de stockage disponible.

  Les utilisateurs disposant des privilèges requis pour créer des objets Oracle, tels que l'utilisateur SDE, le propriétaire d'une géodatabase stockée dans une structure d'utilisateur, et les propriétaires de données, peuvent accéder à l'espace de stockage selon deux méthodes : en possédant le privilège système UNLIMITED TABLESPACE ou en recevant un quota explicite sur un tablespace.

  Le privilège UNLIMITED TABLESPACE permet à un utilisateur d'allouer une quantité illimitée d'espace dans n'importe quel tablespace ou dans tous les tablespaces de la base de données, y compris les tablespaces SYSTEM et SYSAUX gérés par Oracle. Ceci comporte le risque qu'un utilisateur final, intentionnellement ou par accident, épuise l'espace de stockage disponible ou même provoque la panne d'une instance Oracle. Pour cette raison, il est préférable que seuls les utilisateurs administrateur (DBA) de base de données disposent de ce privilège système puissant.

  Les utilisateurs autres que les administrateurs de base de données doivent définir un quota sur un ou plusieurs tablespaces pour leur permettre de créer des objets Oracle de manière contrôlée. Par exemple, vous pouvez accorder à l'utilisateur propriétaire de données GIS_ADMIN un quota sur les tablespaces GIS_DATA et GIS_INDEX mais pas sur les tablespaces SYSTEM et SYSAUX. Vous pouvez ainsi contrôler l'emplacement dans lequel le propriétaire de données peut créer ses tables et ses index et, facultativement, la quantité d'espace que ces objets peuvent consommer.

  En général, l'administrateur de base de données attribue un quota illimité ou aucun quota sur chaque tablespace aux utilisateurs administrateurs d'instance de projet et propriétaires de données. Ainsi, l'administrateur de base de données contrôle l'emplacement dans lequel les données sont physiquement stockées (par exemple, une unité multidisques mise en miroir pour une protection améliorée des données) et peut séparer les données en les plaçant dans des conteneurs logiques isolés des données système et des données des autres projets et applications. Le quota illimité permet au propriétaire de données d'allouer autant d'espace que nécessaire dans les tablespaces auxquels il peut accéder. Cette approche est généralement appropriée car les utilisateurs pouvant accéder au compte du propriétaire de données ont généralement suivi une formation supplémentaire ou affichent généralement une plus grande expérience et en savent souvent plus sur les besoins en stockage de leurs propres données SIG que l'administrateur de base de données.

  Dans les environnements où les éditeurs de données ou les visualiseurs de données sont autorisés à créer leurs propres objets de géodatabase, tels que la sortie d'opérations de géotraitement, vous pouvez attribuer un quota limité sur les tablespaces auxquels ces utilisateurs ont accès en écriture. Par exemple, sur le tablespace GIS_DATA, un quota de 100 Mo peut être attribué aux visualiseurs de données, un quota de 500 Mo aux éditeurs de données et un quota illimité aux propriétaires de données. Personnalisez les affectations de quota en fonction des besoins spécifiques de vos données et de vos processus métier.