Как и во всем, это зависит.
Если вы используете OCI, я предполагаю, что вы разрабатываете клиент-серверное приложение. Как правило, я бы хотел, чтобы база данных в этой ситуации поддерживала соединения с общим сервером, и я хотел бы запросить соединение с общим сервером, когда приложение подключилось к базе данных. Это повышает производительность приложения за счет ограничения объема работы базы данных, необходимой для создания нового сеанса. Это имеет побочный эффект, оставляя больше ресурсов, доступных на сервере для других. Использование соединений с общим сервером требует более длинного пути кода, когда база данных выполняет последующие запросы, поскольку запрос должен быть отправлен процессу общего сервера, но это, как правило, не имеет большого значения, если число процессов общего сервера разумно.
Открытие нескольких сессий также может быть проблемой, если администратор БД не использует автоматическое управление PGA. Если вы используете ручное управление PGA, PGA настраивается для каждого сеанса, поэтому каждый сеанс может выделять отдельный SORT_AREA_SIZEдля сортировки среди других компонентов PGA. Если вы создали большое количество сеансов в базе данных, используя ручное управление PGA, и каждый сеанс пытался максимизировать его использование PGA, вы могли бы просто истощить сервер ОЗУ и вызвать проблемы с производительностью для всех. Однако при условии, что вы используете Oracle 10.1 или новее, доступно автоматическое управление PGA. В этом случае DBA настраивает PGA_AGGREGATE_TARGET(или включает PGA в MEMORY_TARGETin 11g), а база данных заботится о том, чтобы совокупная PGA во всех сеансах была ограничена, чтобы в базе данных заканчивались ресурсы.
Если база данных поддерживает подключения к общему серверу, ваше приложение получает подключение к общему серверу, а база данных использует автоматическое управление PGA, большинству администраторов баз данных не слишком важно, сколько сеансов вы создаете.
Теперь, если вы создаете много сеансов, чтобы можно было выполнять больше работы параллельно, это могло бы создать проблемы с производительностью сверх количества сеансов. Достаточно просто настроить базу данных для поддержки 1000 сеансов, например, гораздо сложнее настроить базу данных так, чтобы она не умирала в куче, если все 1000 сеансов одновременно выдают сложный запрос к хранилищу данных. Если ваше приложение использует все ресурсы, доступные базе данных для ваших запросов, администратор базы данных, возможно, захочет рассмотреть возможность использования Oracle Resource Manager.расставить приоритеты для разных приложений и / или разных пользователей. Например, администратор базы данных может настроить Resource Manager таким образом, чтобы при использовании ЦП до 100% ваше приложение в совокупности получало 50% ЦП, какое-то другое приложение в совокупности получало 25%, а все остальные - оставшиеся 25%. , Если бы другие запросы не ожидали, ваше приложение могло бы свободно использовать все 100% ЦП.
Если вы выполняете вещи параллельно, также может быть полезно изучить способность Oracle выполнять операторы параллельно, потому что это может потребовать меньше затрат, чем написание собственного кода параллелизации. Я ожидаю, например, что было бы намного проще и, возможно, быстрее написать клиентское приложение, которое последовательно отправляло бы операторы, которые выполняли параллельный запрос Oracle, вместо того, чтобы открывать несколько сессий и выполнять каждый оператор из отдельного потока вашего приложения, в то время как Oracle не использовал параллельный запрос для выполнения каких-либо операторов. Если вы используете параллельный запрос, база данных также может регулировать количество порождаемых параллельных ведомых устройств, чтобы при особенно интенсивном использовании базы данных запускалось меньше параллельных подчиненных устройств и когда база данных находилась относительно в режиме ожидания, запускались параллельные ведомые устройства.
