Ovlivní výkon, když je procedura databáze volána z aplikace mnohokrát?

Vaše rada je správná, bylo by lepší provádět všechny databázové úlohy najednou. Ve vašem scénáři jsou 2 hlavní dopady na výkon

1. Přepínání kontextu pro*c mezi SQL enginem a PL/SQL enginem pro vícenásobné spuštění vašich vláken. Obvykle největší problém v mnoha voláních PL/SQL z klientské aplikace.
2. Režie síťového zásobníku (TNS) v komunikaci mezi vaší profesionální aplikací a databázovým strojem – zejména pokud je vaše aplikace na jiném fyzickém hostiteli.

Když už bylo řečeno, že vytváříte fond připojení na konci aplikace, posluchač TNS by měl mít také fond odkázaných stínových procesů serveru čekajících na každé síťové připojení (toto se nastavuje na listener.ora).

Přihlášení/odhlášení OCI, když stínový proces již čeká na připojení, je velmi rychlé a nepředstavuje velký faktor v latenci – nedělám si s tím starosti, pokud se nemusí spustit nový stínový proces na serveru – pak to může být velmi drahé volání. Protože používáte sdružování připojení na straně klienta, obvykle se nejedná o problém, ale pouze o něco, co je třeba zvážit kvůli vláknům ve vašich voláních. Jakmile vyčerpáte zásobu stínových procesů serveru, všimnete si obrovského zhoršení, pokud bude muset posluchač TNS spustit další stínový proces serveru.

Upravit v odpovědi na nové otázky:

1. Je to velmi příbuzné. Jak bylo uvedeno dříve, měli byste minimalizovat množství volání plsql a sql v rámci vaší aplikace C++. Každé volání PLSQL v rámci vašeho volání aplikace C++ vyvolá stroj SQL, který pak vyvolá stroj PLSQL pro volání procedury. Takže pokud rozdělíte svůj postup na 2 - zdvojnásobíte kontextové přepínače SQL na PLSQL, což je dražší přepínač, jak je uvedeno v článku Toma Kytea a mé vlastní osobní zkušenosti.

2. Je zodpovězeno 1. Ale jak jsem již řekl, komunikační režie je až na druhém místě, pokud se vaši hostitelé nenacházejí v různých fyzických sítích a typech dat, která přenášíte. Například velké parametry objektů C++ a velké sady výsledků Oracle s mnoha voláními zjevně ovlivní komunikační latenci s okružními cestami. Pamatujte, že s více voláními PLSQL také přidáváte více provozu SQLNET pro nastavení pro každé připojení a sadu výsledků.

3. neexistuje žádná 3. otázka

4. PLSQL to SQL v enginu PLSQL je zanedbatelné, takže se na něm nenechte zavěsit. Pro maximální výkonovou propustnost vložte všechna vaše SQL volání do 1 volání PLSQL. Nerozdělujte hovory jen proto, abyste byli výmluvnější při drahém výkonu.