Tak jak w przypadku wszystkich rzeczy, to zależy.
Jeśli używasz OCI, zakładam, że tworzysz aplikację klient / serwer. Zasadniczo chciałbym, aby baza danych w tej sytuacji obsługiwała połączenia z serwerem współużytkowanym i chciałbym poprosić o połączenie z serwerem współużytkowanym, gdy aplikacja łączy się z bazą danych. Poprawia to wydajność aplikacji, ograniczając ilość pracy, jaką musi wykonać baza danych, aby utworzyć nową sesję. Ma to efekt uboczny polegający na pozostawieniu większej ilości zasobów dostępnych na serwerze dla innych. Korzystanie z połączeń z serwerem współużytkowanym wymaga dłuższej ścieżki kodu, gdy baza danych wykonuje kolejne zapytania, ponieważ zapytanie musi być wysłane do procesu serwera współużytkowanego, ale ogólnie nie jest to wielka sprawa, jeśli liczba procesów serwera współużytkowanego jest rozsądna.
Otwarcie pewnej liczby sesji może również stanowić problem, jeśli DBA nie korzysta z automatycznego zarządzania PGA. Jeśli korzystasz z ręcznego zarządzania PGA, PGA jest konfigurowany dla każdej sesji, więc każda sesja może przydzielić osobne SORT_AREA_SIZEdla różnych elementów PGA. Jeśli utworzono dużą liczbę sesji w bazie danych przy użyciu ręcznego zarządzania PGA, a każda sesja próbowała zmaksymalizować wykorzystanie PGA, można łatwo zagłodzić serwer pamięci RAM i spowodować problemy z wydajnością dla wszystkich. Zakładając, że korzystasz z Oracle 10.1 lub nowszej wersji, dostępne jest automatyczne zarządzanie PGA. W takim przypadku DBA konfiguruje a PGA_AGGREGATE_TARGET(lub zawiera PGA w MEMORY_TARGET11g), a baza danych dba o to, aby zagregowane PGA we wszystkich sesjach było ograniczone, tak aby baza danych wyczerpała zasoby.
Jeśli baza danych obsługuje połączenia z serwerem współużytkowanym, aplikacja otrzymuje połączenie z serwerem współużytkowanym, a baza danych korzysta z automatycznego zarządzania PGA, większość DBA nie będzie dbać o to, ile sesji utworzysz.
Teraz, jeśli tworzysz wiele sesji, abyś mógł wykonywać więcej pracy równolegle, spowodowałoby to problemy z wydajnością ponad liczbę sesji. Na przykład skonfigurowanie bazy danych do obsługi 1000 sesji jest dość łatwe, na przykład znacznie trudniej jest skonfigurować bazę danych, aby nie zginęła w stosie, jeśli wszystkie 1000 sesji jednocześnie wyśle mięsiste zapytanie do hurtowni danych. Jeśli twoja aplikacja zużywa wszystkie zasoby dostępne w bazie danych na twoje zapytania, DBA prawdopodobnie zechce rozważyć użycie Oracle Resource Managerw celu ustalenia priorytetów dla różnych aplikacji i / lub różnych użytkowników. Na przykład DBA może skonfigurować Resource Managera, aby jeśli wykorzystanie procesora spadło do 100%, twoja aplikacja w agregacie otrzyma 50% procesora, niektóre inne aplikacje w agregacji otrzymają 25%, a wszystkie pozostałe dostaną pozostałe 25% . Jeśli żadne inne żądania nie byłyby w toku, aplikacja będzie mogła swobodnie wykorzystywać wszystkie 100% procesora.
Jeśli działasz równolegle, przydatne może być zbadanie zdolności Oracle do równoległego uruchamiania instrukcji, ponieważ może to wiązać się z mniejszym nakładem pracy niż pisanie własnego kodu równoległego. Spodziewałbym się na przykład, że o wiele łatwiej i być może szybciej byłoby napisać aplikację kliencką, która seryjnie przesyłała instrukcje wykorzystujące równoległe zapytanie Oracle do wykonania zamiast otwierania wielu sesji i wykonywania każdej instrukcji z osobnego wątku aplikacji, podczas gdy Oracle nie używało równoległego zapytania do wykonania żadnej z instrukcji. Jeśli korzystasz z równoległego zapytania, baza danych może również dostosować liczbę równoległych slaveów, które są odradzane, tak że gdy baza danych jest szczególnie zajęta, uruchamianych jest mniej równoległych slave, a gdy baza danych jest stosunkowo bezczynna, uruchamianych jest więcej równoległych slave.
