Comme pour toutes choses, cela dépend.
Si vous utilisez OCI, je suppose que vous développez une application client / serveur. Je voudrais généralement que la base de données dans cette situation prenne en charge les connexions au serveur partagé et je voudrais demander une connexion au serveur partagé lorsque l'application se connecte à la base de données. Cela améliore les performances de l'application en limitant la quantité de travail que la base de données doit faire pour créer une nouvelle session. Cela a pour effet secondaire de laisser plus de ressources disponibles sur le serveur pour les autres. L'utilisation de connexions de serveur partagé implique un chemin de code plus long lorsque la base de données exécute des requêtes ultérieures, car la requête doit être envoyée à un processus de serveur partagé, mais ce n'est généralement pas un gros problème si le nombre de processus de serveur partagé est raisonnable.
L'ouverture d'un certain nombre de sessions pourrait également être un problème si le DBA n'utilise pas la gestion PGA automatique. Si vous utilisez la gestion PGA manuelle, PGA est configuré sur une base par session afin que chaque session puisse allouer un tri séparé SORT_AREA_SIZEpour les autres composants PGA. Si vous avez créé un grand nombre de sessions dans une base de données en utilisant la gestion PGA manuelle et que chaque session a essayé de maximiser son utilisation PGA, vous pourriez facilement affamer le serveur de RAM et causer des problèmes de performances pour tout le monde. En supposant que vous utilisez Oracle 10.1 ou version ultérieure, cependant, la gestion PGA automatique est disponible. Dans ce cas, le DBA configure un PGA_AGGREGATE_TARGET(ou inclut le PGA dans le MEMORY_TARGETin 11g) et la base de données veille à ce que le PGA agrégé sur toutes les sessions soit limité afin que la base de données manque de ressources.
Si la base de données prend en charge les connexions au serveur partagé, votre application obtient une connexion au serveur partagé et la base de données utilise la gestion PGA automatique, la plupart des administrateurs de base de données ne se soucient pas trop du nombre de sessions que vous créez.
Maintenant, si vous créez de nombreuses sessions afin de pouvoir travailler plus en parallèle, cela créerait des problèmes de performances au-delà du nombre de sessions. Il est assez facile de configurer la base de données pour prendre en charge 1000 sessions, par exemple, il est beaucoup plus difficile de configurer la base de données pour ne pas mourir dans une pile si toutes les 1000 sessions émettent simultanément une requête charnue contre un entrepôt de données. Si votre application utilise toutes les ressources disponibles dans la base de données pour vos requêtes, le DBA voudra probablement envisager d'utiliser Oracle Resource Managerpour prioriser différentes applications et / ou différents utilisateurs. Par exemple, l'administrateur de base de données peut configurer Resource Manager de sorte que si l'utilisation du processeur passe à 100%, votre application dans son ensemble obtient 50% du processeur, une autre application dans l'agrégat obtient 25% et toutes les autres obtiennent les 25% restants . Si aucune autre demande n'était en attente, votre application serait libre d'utiliser tous les 100% du CPU.
Si vous exécutez des choses en parallèle, il peut également être utile d'étudier la capacité d'Oracle à exécuter des instructions en parallèle, car cela peut impliquer moins de surcharge que d'écrire votre propre code de parallélisation. Je m'attends, par exemple, à ce qu'il soit beaucoup plus facile et probablement plus rapide d'écrire une application cliente qui soumet en série des instructions qui utilisent la requête parallèle Oracle pour exécuter plutôt que d'ouvrir plusieurs sessions et d'exécuter chaque instruction à partir d'un thread distinct de votre application tout en Oracle n'utilisait pas de requête parallèle pour exécuter l'une des instructions. Si vous utilisez une requête parallèle, la base de données peut également ajuster le nombre d'esclaves parallèles générés de sorte que lorsque la base de données est particulièrement occupée, moins d'esclaves parallèles sont démarrés et lorsque la base de données est relativement inactive, plus d'esclaves parallèles sont démarrés.