Como com todas as coisas, isso depende.
Se você estiver usando OCI, presumo que você esteja desenvolvendo um aplicativo cliente / servidor. Geralmente, eu gostaria que o banco de dados nessa situação suportasse conexões de servidor compartilhadas e gostaria de solicitar uma conexão de servidor compartilhado quando o aplicativo se conectasse ao banco de dados. Isso melhora o desempenho do aplicativo, limitando a quantidade de trabalho que o banco de dados precisa realizar para criar uma nova sessão. Isso tem o efeito colateral de deixar mais recursos disponíveis no servidor para outros. O uso de conexões de servidor compartilhado envolve um caminho de código mais longo quando o banco de dados executando consultas subsequentes, pois a consulta deve ser enviada para um processo de servidor compartilhado, mas isso geralmente não é importante se o número de processos de servidor compartilhado for razoável.
Abrir várias sessões também pode ser um problema se o DBA não estiver usando o gerenciamento automático de PGA. Se você estiver usando o gerenciamento manual da PGA, a PGA é configurada por sessão, para que cada sessão possa alocar uma classificação separada SORT_AREA_SIZEentre outros componentes da PGA. Se você criou um grande número de sessões em um banco de dados usando o gerenciamento manual de PGA e cada sessão tentou maximizar seu uso de PGA, você poderia facilmente passar fome no servidor de RAM e causar problemas de desempenho para todos. Supondo que você esteja usando o Oracle 10.1 ou posterior, no entanto, o gerenciamento automático de PGA está disponível. Nesse caso, o DBA configura um PGA_AGGREGATE_TARGET(ou inclui o PGA no MEMORY_TARGET11g) e o banco de dados se encarrega de garantir que o PGA agregado em todas as sessões seja limitado para que o banco de dados fique sem recursos.
Se o banco de dados suportar conexões de servidor compartilhadas, seu aplicativo obterá uma conexão de servidor compartilhada e o banco de dados usará gerenciamento automático de PGA, a maioria dos DBAs não se importará muito com quantas sessões você criar.
Agora, se você estiver criando muitas sessões para poder trabalhar mais em paralelo, isso criaria problemas de desempenho além do número de sessões. É fácil o suficiente configurar o banco de dados para suportar 1000 sessões, por exemplo, é muito mais difícil configurar o banco de dados para não morrer em uma pilha, se todas as 1000 sessões emitirem simultaneamente uma consulta simples em um data warehouse. Se seu aplicativo estiver usando todos os recursos disponíveis no banco de dados para suas consultas, o DBA provavelmente desejaria considerar o uso do Oracle Resource Managerpriorizar aplicativos diferentes e / ou usuários diferentes. Por exemplo, o DBA pode configurar o Gerenciador de Recursos para que, se a utilização da CPU for de 100%, seu aplicativo no agregado obtenha 50% da CPU, algum outro aplicativo no agregado obtenha 25% e os demais 25%. . Se não houver outras solicitações pendentes, seu aplicativo estará livre para usar todos os 100% da CPU.
Se você estiver executando coisas em paralelo, também poderá ser útil investigar a capacidade do Oracle de executar instruções em paralelo, pois isso pode envolver menos sobrecarga do que escrever seu próprio código de paralelização. Eu esperaria, por exemplo, que seria muito mais fácil e possivelmente mais rápido escrever um aplicativo cliente que enviasse em série instruções que usassem a consulta paralela Oracle para executar, em vez de abrir várias sessões e executar cada instrução a partir de um segmento separado do seu aplicativo enquanto O Oracle não estava usando a consulta paralela para executar nenhuma das instruções. Se você usar a consulta paralela, o banco de dados também poderá ajustar o número de escravos paralelos gerados para que, quando o banco de dados esteja particularmente ocupado, menos escravos paralelos sejam iniciados e quando o banco de dados esteja relativamente ocioso, mais escravos paralelos sejam iniciados.
