Czy wydajność wpłynie na wielokrotne wywoływanie procedury bazy danych z aplikacji?

Twoja rada jest słuszna, lepiej byłoby wykonać wszystkie zadania bazy danych naraz. Twój scenariusz ma 2 główne wpływy na wydajność

1. Przełączanie kontekstu pro*c między silnikiem SQL a silnikiem PL/SQL w celu wielokrotnego uruchamiania wątków. Zwykle największy problem w wielu wywołaniach PL/SQL z aplikacji klienckiej.
2. Narzut stosu sieciowego (TNS) w komunikacji między Twoją aplikacją pro*c a silnikiem bazy danych – szczególnie, jeśli Twoja aplikacja znajduje się na innym fizycznym hoście.

Powiedziawszy to, tworzysz pulę połączeń na końcu aplikacji, nasłuchujący TNS powinien również mieć pulę zapisanych procesów cienia serwera oczekujących na każde połączenie sieciowe (jest to ustawione na listener.ora).

Logowanie/wylogowanie OCI, gdy proces cienia już czeka na połączenie, jest bardzo szybkie i nie ma dużego wpływu na opóźnienie - nie martwię się tym, chyba że musi się uruchomić nowy proces cienia na serwerze - wtedy może to być bardzo drogie połączenie. Ponieważ używasz puli połączeń po stronie klienta, zwykle nie jest to problem, ale po prostu coś do rozważenia ze względu na wątki w twoich wywołaniach. Po wyczerpaniu puli procesów cieniowania serwera zauważysz ogromną degradację, jeśli odbiornik TNS będzie musiał uruchomić więcej procesów cienia serwera.

Edytuj w odpowiedzi na nowe pytania:

1. To jest bardzo powiązane. Jak wskazano wcześniej, należy zminimalizować liczbę wywołań plsql i sql w aplikacji C++. Każde wywołanie PLSQL w wywołaniu aplikacji C++ wywołuje silnik SQL, który następnie wywołuje silnik PLSQL dla wywołania procedury. Więc jeśli podzielisz procedurę na 2 - podwajasz przełączniki kontekstowe SQL na PLSQL, który jest droższym przełącznikiem, jak opisano w artykule Toma Kyte'a i moim osobistym doświadczeniu.

2. Odpowiedź jest w 1. Ale, jak już powiedziałem, obciążenie komunikacyjne jest drugie, chyba że twoje hosty znajdują się w różnych sieciach fizycznych i typach przesyłanych danych. Na przykład duże parametry obiektów C++ i duże zbiory wyników Oracle z wieloma wywołaniami w oczywisty sposób wpłyną na opóźnienia komunikacji z podróżami w obie strony. Pamiętaj, że przy większej liczbie wywołań PLSQL dodajesz również większy ruch SQLNET dla konfiguracji dla każdego połączenia i zestawu wyników.

3. nie ma 3. pytania

4. PLSQL do SQL w silniku PLSQL jest znikome, więc nie rozłączaj się. Umieść wszystkie wywołania SQL w jednym wywołaniu PLSQL, aby uzyskać maksymalną przepustowość. Nie dziel rozmów tylko po to, by być bardziej elokwentnym kosztem wydajności.