Як і у всьому, це залежить.
Якщо ви використовуєте OCI, я припускаю, що ви розробляєте програму для клієнта / сервера. Як правило, я хочу, щоб база даних у цій ситуації підтримувала спільні з'єднання з сервером, і я хотів би подати запит на спільне підключення до сервера, коли програма підключилася до бази даних. Це покращує продуктивність програми, обмежуючи обсяг роботи, яку повинна виконати база даних, щоб створити новий сеанс. Це має побічний ефект: залишає більше ресурсів, доступних на сервері для інших. Використання підключень до спільного сервера передбачає довший шлях коду, коли база даних виконує наступні запити, оскільки запит повинен бути відправлений на процес спільного використання сервера, але це, звичайно, не є великою справою, якщо кількість спільних процесів сервера є розумною.
Відкриття декількох сеансів також може бути проблемою, якщо DBA не використовує автоматичне управління PGA. Якщо ви використовуєте ручне управління PGA, PGA налаштовується на сеансі, так що кожен сеанс може виділяти окремі SORT_AREA_SIZEдля сортування серед інших компонентів PGA. Якщо ви створили велику кількість сеансів у базі даних, використовуючи керування вручну PGA, і кожен сеанс намагався максимально використовувати його PGA, ви могли легко голодувати сервером оперативної пам’яті та викликати проблеми з продуктивністю для всіх. Якщо припустити, що ви використовуєте Oracle 10.1 або новішу версію, доступне автоматичне управління PGA. У цьому випадку DBA конфігурує PGA_AGGREGATE_TARGET(або включає PGA в MEMORY_TARGET11g), і база даних бере на себе увагу, щоб сукупна PGA протягом усіх сеансів була обмежена, так що в базі даних не вистачає ресурсів.
Якщо база даних підтримує спільні з'єднання з сервером, ваша програма отримує спільне з'єднання з сервером, а база даних використовує автоматичне управління PGA, більшість DBA не надто дбає, скільки сеансів ви створюєте.
Тепер, якщо ви створюєте багато сеансів, щоб ви могли паралельно виконувати більшу роботу, це створювало б проблеми з продуктивністю понад та більше сесій. Досить просто налаштувати базу даних для підтримки 1000 сеансів, наприклад, набагато складніше налаштувати базу даних, щоб не загинути в купі, якщо всі 1000 сеансів одночасно видають м'який запит на сховище даних. Якщо ваша програма використовує всі наявні в базі даних ресурси для ваших запитів, DBA, ймовірно, захоче розглянути можливість використання Oracle Resource Managerвизначити пріоритет для різних програм та / або різних користувачів. Наприклад, DBA може налаштувати диспетчер ресурсів так, що якщо використання процесора перейде на 100%, ваша програма в сукупності отримує 50% ЦП, деяка інша програма в агрегаті отримує 25%, а всі інші отримують решту 25% . Якщо жодних інших запитів не було, ваш додаток може безкоштовно використовувати всі 100% ЦП.
Якщо ви працюєте паралельно, можливо, також буде корисно вивчити здатність Oracle паралельно запускати оператори, оскільки це може спричинити менше накладних витрат, ніж написання власного коду паралелізації. Я б очікував, наприклад, що набагато простіше і цілком можливо швидше написати клієнтську програму, яка послідовно надсилала заяви, які використовували паралельний запит Oracle для виконання, а не відкриття декількох сеансів і виконання кожного оператора з окремої нитки вашої програми. Oracle не використовував паралельний запит для виконання жодного з операторів. Якщо ви використовуєте паралельний запит, база даних також може регулювати кількість паралельних ведених, які породжуються таким чином, що коли база даних особливо зайнята, починається менше паралельних ведених, і коли база даних відносно простоює, запускається більше паралельних рабів.