Om prestandan kommer att påverka när databasproceduren anropas från programmet många gånger?

Ditt råd är korrekt, det skulle vara bättre att utföra alla databasuppgifter på en gång. Det finns två stora prestandaeffekter i ditt scenario

1. Kontextväxlingen av pro*c mellan SQL-motorn och PL/SQL-motorn för att köra dina trådar flera gånger. Vanligtvis det största problemet i många PL/SQL-anrop från en klientapplikation.
2. Network stack overhead (TNS) i kommunikationen mellan din pro*c-app och databasmotorn - särskilt om din app finns på en annan fysisk värd.

Med det sagt skapar du en anslutningspool i applikationsänden. TNS-lyssnaren bör också ha en pool av testade serverskuggprocesser som väntar på varje nätverksanslutning (detta ställs in på listener.ora).

OCI-inloggningen/utloggningen när skuggprocessen redan väntar på anslutning är mycket snabb och inte en stor faktor i latens - jag oroar mig inte för detta om inte en ny skuggprocess på servern måste startas - då kan det vara en mycket dyrt samtal. Eftersom du använder anslutningspooling på klientsidan är detta vanligtvis inte ett problem utan bara något att tänka på på grund av trådningen i dina samtal. När du har uttömt poolen av serverskuggprocesser kommer du att märka en enorm försämring om TNS-lyssnaren måste starta upp fler serverskuggprocesser.

Redigera som svar på de nya frågorna:

1. Det är väldigt relaterat. Som påpekats tidigare bör du minimera mängden plsql- och sql-anrop i din C++-app. Varje PLSQL-anrop i ditt C++-appanrop anropar SQL-motorn som sedan anropar PLSQL-motorn för proceduranropet. Så om du delar upp din procedur i 2 - du dubblar SQL till PLSQL sammanhangsväxlarna, vilket är den dyrare växeln som beskrivs i Tom Kyte-artikeln och min egen personliga erfarenhet.

2. Besvaras i 1. Men som jag tidigare sa är kommunikationskostnaderna andra om inte dina värdar finns på olika fysiska nätverk och vilka typer av data du överför. Till exempel kommer stora C++-objektparametrar och stora Oracle-resultatuppsättningar med många anrop uppenbarligen att påverka kommunikationslatens med rundresor. Kom ihåg att med fler PLSQL-anrop lägger du också till mer SQLNET-trafik för installationen för varje anslutning och resultatuppsättning.

3. det finns ingen 3. fråga

4. PLSQL till SQL inom PLSQL-motorn är försumbar så häng inte på det. Lägg alla dina SQL-anrop inom 1 PLSQL-anrop för maximal prestandagenomströmning. Dela inte upp samtalen bara för att vara mer vältalig när det gäller det dyra resultatet.