Votre conseil est correct, il serait préférable d'effectuer toutes les tâches de la base de données en même temps. Il y a 2 impacts majeurs sur les performances dans votre scénario
- Le changement de contexte de pro*c entre le moteur SQL et le moteur PL/SQL pour exécuter vos threads plusieurs fois. Généralement le plus gros problème dans de nombreux appels PL/SQL à partir d'une application cliente.
- La surcharge de la pile réseau (TNS) dans les communications entre votre application pro*c et le moteur de base de données, en particulier si votre application se trouve sur un hôte physique différent.
Cela dit, vous créez un pool de connexions côté application. L'écouteur TNS doit également disposer d'un pool de processus fantômes de serveur légués en attente de chaque connexion réseau (ceci est configuré sur listener.ora).
La connexion/déconnexion OCI lorsque le processus shadow attend déjà la connexion est très rapide et n'est pas un facteur de latence énorme - je ne m'en soucie pas à moins qu'un nouveau processus shadow sur le serveur ne doive démarrer - alors cela peut être un appel très cher. Comme vous utilisez le regroupement de connexions côté client, ce n'est généralement pas un problème, mais juste quelque chose à considérer en raison du threading dans vos appels. Une fois que vous avez épuisé le pool de processus d'ombre de serveur, vous remarquerez une énorme dégradation si l'écouteur TNS doit démarrer plus de processus d'ombre de serveur.
Modifier en réponse aux nouvelles questions :
-
C'est très lié. Comme indiqué précédemment, vous devez minimiser le nombre d'appels plsql et sql dans votre application C++. Chaque appel PLSQL dans votre appel d'application C++ appelle le moteur SQL qui appelle ensuite le moteur PLSQL pour l'appel de procédure. Donc, si vous divisez votre procédure en 2 - vous doublez les commutateurs de contexte SQL vers PLSQL, ce qui est le commutateur le plus coûteux, comme indiqué par l'article de Tom Kyte et ma propre expérience personnelle.
-
Est répondu en 1. Mais comme je l'ai dit précédemment, les frais généraux de communication sont secondaires, sauf si vos hôtes se trouvent sur des réseaux physiques différents et les types de données que vous transférez. Par exemple, les grands paramètres d'objet C++ et les grands ensembles de résultats Oracle avec de nombreux appels affecteront évidemment la latence des communications avec les allers-retours. N'oubliez pas qu'avec plus d'appels PLSQL, vous ajoutez également plus de trafic SQLNET pour la configuration de chaque connexion et ensemble de résultats.
-
il n'y a pas de 3ème question
-
PLSQL vers SQL dans le moteur PLSQL est négligeable, alors ne vous attardez pas dessus. Mettez tous vos appels SQL dans un seul appel PLSQL pour un débit de performance maximal. Ne divisez pas les appels simplement pour être plus éloquent au détriment des performances.
