Il tuo consiglio è corretto, sarebbe meglio eseguire tutte le attività del database contemporaneamente. Ci sono 2 principali impatti sulle prestazioni nel tuo scenario
- Il cambio di contesto di pro*c tra il motore SQL e il motore PL/SQL per eseguire i thread più volte. Di solito il problema più grande in molte chiamate PL/SQL da un'applicazione client.
- Il sovraccarico dello stack di rete (TNS) nelle comunicazioni tra la tua app pro*c e il motore di database, in particolare se la tua app si trova su un host fisico diverso.
Detto questo, stai creando un pool di connessioni all'estremità dell'applicazione, il listener TNS dovrebbe anche avere un pool di processi shadow del server legati in attesa di ogni connessione di rete (questo è impostato su listener.ora).
L'accesso/disconnessione da OCI quando il processo ombra è già in attesa di connessione è molto rapido e non è un fattore di latenza enorme - non me ne preoccupo a meno che non debba essere avviato un nuovo processo ombra sul server, quindi può essere un chiamata molto costosa. Poiché stai utilizzando il pool di connessioni sul lato client, questo di solito non è un problema ma solo qualcosa da considerare a causa del threading nelle tue chiamate. Una volta esaurito il pool di processi shadow del server, noterai un enorme degrado se il listener TNS deve avviare più processi shadow del server.
Modifica in risposta alle nuove domande:
-
È molto correlato. Come sottolineato in precedenza, dovresti ridurre al minimo la quantità di chiamate plsql e sql all'interno della tua app C++. Ogni chiamata PLSQL all'interno della chiamata all'app C++ richiama il motore SQL che quindi richiama il motore PLSQL per la chiamata di procedura. Quindi, se dividi la tua procedura in 2, stai raddoppiando le opzioni di contesto da SQL a PLSQL, che è l'opzione più costosa come delineato dall'articolo di Tom Kyte e dalla mia esperienza personale.
-
La risposta è 1. Ma come ho detto in precedenza, il sovraccarico delle comunicazioni è il secondo a meno che i tuoi host non si trovino su reti fisiche diverse e sui tipi di dati che stai trasferendo. Ad esempio, parametri di oggetti C++ di grandi dimensioni e set di risultati Oracle di grandi dimensioni con molte chiamate influiranno ovviamente sulla latenza delle comunicazioni con round trip. Ricorda che con più chiamate PLSQL stai anche aggiungendo più traffico SQLNET per l'installazione per ogni connessione e set di risultati.
-
non c'è 3. domanda
-
Da PLSQL a SQL all'interno del motore PLSQL è trascurabile, quindi non rimanere bloccato su di esso. Inserisci tutte le tue chiamate SQL all'interno di 1 chiamata PLSQL per il massimo throughput delle prestazioni. Non dividere le chiamate solo per essere più eloquenti a scapito delle prestazioni.
