Вашият съвет е правилен, би било по-добре да изпълнявате всички задачи на базата данни наведнъж. Във вашия сценарий има 2 основни въздействия върху производителността
- Превключването на контекста на pro*c между SQL машината и PL/SQL машината за изпълнение на нишките ви многократно. Обикновено най-големият проблем при много PL/SQL извиквания от клиентско приложение.
- Овърхедът на мрежовия стек (TNS) в комуникациите между вашето pro*c приложение и машината на базата данни - особено ако приложението ви е на различен физически хост.
Като каза това, вие създавате пул за свързване в края на приложението, слушателят на TNS също трябва да има пул от завещани сървърни shadow процеси, чакащи всяка мрежова връзка (това е настроено в listener.ora).
OCI влизането/излизането, когато shadow процесът вече чака свързване, е много бърз и не е огромен фактор за забавяне - не се тревожа за това, освен ако не трябва да стартира нов shadow процес на сървъра - тогава може да е много скъпо обаждане. Тъй като използвате групиране на връзки от страна на клиента, това обикновено не е проблем, а просто нещо, което трябва да имате предвид поради нишките във вашите повиквания. След като изчерпите набора от процеси в сянка на сървъра, ще забележите огромно влошаване, ако слушателят на TNS трябва да стартира още процес в сянка на сървъра.
Редактиране в отговор на новите въпроси:
-
Много е свързано. Както беше посочено по-рано, трябва да минимизирате количеството plsql и sql извиквания във вашето C++ приложение. Всяко PLSQL извикване в рамките на извикването на вашето C++ приложение извиква SQL машината, която след това извиква PLSQL машината за извикването на процедурата. Така че, ако разделите процедурата си на 2 - вие удвоявате контекстните превключвания от SQL към PLSQL, което е по-скъпият превключвател, както е посочено в статията на Tom Kyte и моя личен опит.
-
Отговаря се в 1. Но както казах по-рано, комуникационните разходи са на второ място, освен ако вашите хостове не са в различни физически мрежи и типовете данни, които прехвърляте. Например големите обектни параметри на C++ и големите набори от резултати на Oracle с много извиквания очевидно ще повлияят на забавянето на комуникациите с двупосочни пътувания. Не забравяйте, че с повече PLSQL извиквания вие също добавяте повече SQLNET трафик за настройката за всяка връзка и набор от резултати.
-
няма 3. въпрос
-
PLSQL към SQL в рамките на PLSQL двигателя е незначителен, така че не се вкопчвайте в него. Поставете всичките си SQL извиквания в рамките на 1 PLSQL извикване за максимална производителност. Не разделяйте обажданията само за да сте по-красноречиви на цената на изпълнението.
