Oracle
 sql >> Datenbank >  >> RDS >> Oracle

Ob die Leistung beeinträchtigt wird, wenn die Datenbankprozedur viele Male von der Anwendung aufgerufen wird?

Ihr Rat ist richtig, es wäre besser, alle Datenbankaufgaben auf einmal auszuführen. In Ihrem Szenario gibt es zwei wesentliche Auswirkungen auf die Leistung

  1. Der Kontextwechsel von pro*c zwischen der SQL-Engine und der PL/SQL-Engine, um Ihre Threads mehrmals auszuführen. Normalerweise das größte Problem bei vielen PL/SQL-Aufrufen von einer Client-Anwendung.
  2. Der Netzwerkstapel-Overhead (TNS) in der Kommunikation zwischen Ihrer pro*c-App und der Datenbank-Engine – insbesondere, wenn sich Ihre App auf einem anderen physischen Host befindet.

Allerdings erstellen Sie einen Verbindungspool auf der Anwendungsseite. Der TNS-Listener sollte auch einen Pool von vererbten Server-Schattenprozessen haben, die auf jede Netzwerkverbindung warten (dies wird in listener.ora eingerichtet).

Die OCI-Anmeldung/-Abmeldung, wenn der Schattenprozess bereits auf die Verbindung wartet, ist sehr schnell und kein großer Latenzfaktor - ich mache mir darüber keine Gedanken, es sei denn, ein neuer Schattenprozess auf dem Server muss gestartet werden - dann kann es sein a Sehr teurer Anruf. Da Sie das Verbindungspooling auf der Clientseite verwenden, ist dies normalerweise kein Problem, sondern nur etwas, das Sie aufgrund des Threadings in Ihren Aufrufen berücksichtigen sollten. Sobald Sie den Pool der Server-Schattenprozesse erschöpft haben, werden Sie eine enorme Verschlechterung feststellen, wenn der TNS-Listener mehr Server-Schattenprozesse starten muss.

Als Antwort auf die neuen Fragen bearbeiten:

  1. Es ist sehr verwandt. Wie bereits erwähnt, sollten Sie die Anzahl der plsql- und sql-Aufrufe in Ihrer C++-App minimieren. Jeder PLSQL-Aufruf innerhalb Ihres C++-App-Aufrufs ruft die SQL-Engine auf, die dann die PLSQL-Engine für den Prozeduraufruf aufruft. Wenn Sie also Ihre Prozedur in 2 aufteilen, verdoppeln Sie die Kontextwechsel von SQL zu PLSQL, was der teurere Wechsel ist, wie im Artikel von Tom Kyte und meiner eigenen persönlichen Erfahrung beschrieben.

  2. Wird in 1 beantwortet. Aber wie ich bereits sagte, ist der Kommunikationsaufwand zweitrangig, es sei denn, Ihre Hosts befinden sich in unterschiedlichen physischen Netzwerken und die Arten von Daten, die Sie übertragen. Beispielsweise wirken sich große C++-Objektparameter und große Oracle-Ergebnismengen mit vielen Aufrufen offensichtlich auf die Kommunikationslatenz bei Roundtrips aus. Denken Sie daran, dass Sie mit mehr PLSQL-Aufrufen auch mehr SQLNET-Datenverkehr für das Setup für jede Verbindung und Ergebnismenge hinzufügen.

  3. es gibt keine 3. Frage

  4. PLSQL to SQL innerhalb der PLSQL-Engine ist vernachlässigbar, also hängen Sie sich nicht daran auf. Platzieren Sie alle Ihre SQL-Aufrufe in einem PLSQL-Aufruf für maximalen Leistungsdurchsatz. Teilen Sie die Anrufe nicht auf, nur um auf Kosten der Leistung eloquenter zu sein.