Como con todas las cosas, depende.
Si está utilizando OCI, supongo que está desarrollando una aplicación cliente / servidor. En general, me gustaría que la base de datos en esa situación admitiera conexiones de servidor compartidas y quisiera solicitar una conexión de servidor compartida cuando la aplicación se conecte a la base de datos. Eso mejora el rendimiento de la aplicación al limitar la cantidad de trabajo que la base de datos tiene que hacer para crear una nueva sesión. Eso tiene el efecto secundario de dejar más recursos disponibles en el servidor para otros. El uso de conexiones de servidor compartido implica una ruta de código más larga cuando la base de datos ejecuta consultas posteriores ya que la consulta debe enviarse a un proceso de servidor compartido, pero eso generalmente no es un gran problema si la cantidad de procesos de servidor compartido es razonable.
Abrir una serie de sesiones también podría ser un problema si el DBA no está utilizando la gestión automática de PGA. Si está utilizando la gestión manual de PGA, PGA se configura por sesión para que cada sesión pueda asignar un SORT_AREA_SIZEtipo separado entre otros componentes de PGA. Si creó una gran cantidad de sesiones en una base de datos utilizando la administración manual de PGA y cada sesión intentó maximizar su uso de PGA, fácilmente podría privar al servidor de RAM y causar problemas de rendimiento para todos. Suponiendo que esté utilizando Oracle 10.1 o posterior, sin embargo, la administración automática de PGA está disponible. En ese caso, el DBA configura un PGA_AGGREGATE_TARGET(o incluye el PGA en el MEMORY_TARGET11g) y la base de datos se asegura de que el PGA agregado en todas las sesiones sea limitado para que la base de datos se quede sin recursos.
Si la base de datos admite conexiones de servidor compartidas, su aplicación obtiene una conexión de servidor compartida y la base de datos usa la administración automática de PGA, a la mayoría de los DBA no les importará demasiado cuántas sesiones cree.
Ahora, si está creando muchas sesiones para poder hacer más trabajo en paralelo, eso crearía problemas de rendimiento por encima del número de sesiones. Es bastante fácil configurar la base de datos para admitir 1000 sesiones, por ejemplo, es mucho más difícil configurar la base de datos para que no muera en una pila si todas las 1000 sesiones emiten simultáneamente una consulta carnosa contra un almacén de datos. Si su aplicación está utilizando todos los recursos disponibles en la base de datos para sus consultas, el DBA probablemente querrá considerar el uso de Oracle Resource Managerpara priorizar diferentes aplicaciones y / o diferentes usuarios. Por ejemplo, el DBA podría configurar Resource Manager para que si la utilización de la CPU llega al 100%, su aplicación en conjunto obtiene el 50% de la CPU, alguna otra aplicación en el agregado obtiene el 25%, y todas las demás obtienen el 25% restante . Si no hubiera otras solicitudes pendientes, su aplicación sería libre de usar el 100% de la CPU.
Si está ejecutando cosas en paralelo, también podría ser útil investigar la capacidad de Oracle para ejecutar declaraciones en paralelo porque eso podría implicar menos sobrecarga que escribir su propio código de paralelización. Esperaría, por ejemplo, que sería mucho más fácil y posiblemente más rápido escribir una aplicación cliente que enviara en serie declaraciones que usaran consultas paralelas de Oracle para ejecutar en lugar de abrir varias sesiones y ejecutar cada declaración desde un hilo separado de su aplicación mientras Oracle no estaba usando una consulta paralela para ejecutar ninguna de las declaraciones. Si utiliza la consulta paralela, la base de datos también puede ajustar el número de esclavos paralelos que se generan para que cuando la base de datos esté particularmente ocupada se inicien menos esclavos paralelos y cuando la base de datos esté relativamente inactiva se inicien más esclavos paralelos.
