Tus consultas no están completando realmente. Aunque su consulta solo obtiene las primeras 1000 filas, SQL Developer solo obtiene las primeras 50 filas de esas 1000 filas. El IDE no cerrará el cursor hasta que se desplace a la última fila. Una vez que recupera todos los datos, esos procesos paralelos desaparecen. Asegúrese de ver "Todas las filas recuperadas:1000 en X segundos", en lugar de ""Recuperadas 50 filas en Y segundos". (Desearía que SQL Developer hiciera más evidente que hay filas adicionales esperando). vea este problema en SQL*Plus porque SQL*Plus siempre toma todas las filas.
Cuando solo se obtienen las primeras N filas, esos procesos paralelos están "ACTIVOS" pero no están haciendo nada. debería ser capaz de ignorar esas sesiones ya que no están utilizando ningún recurso significativo.
Si solo le preocupa la cantidad de sesiones paralelas, es posible que desee ajustar sus expectativas. Solía estar en la misma situación que usted:constantemente les decía a los usuarios que sus consultas (incompletas) estaban acaparando todas las sesiones paralelas. Eventualmente, descubrí que solo era un problema porque había creado un recurso artificialmente escaso. Los procesos paralelos de Oracle suelen ser ligeros y las bases de datos pueden admitir muchos más procesos paralelos de lo que la mayoría de la gente piensa que pueden.
¿Cuáles son los valores de sus parámetros para PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU y CPU_COUNT? Mire el valor predeterminado para PARALLEL_MAX_SERVERS
. Según el manual, el número predeterminado es:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
La mayoría de los DBA ven un número máximo de subprocesos paralelos de cientos, entran en pánico y luego reducen ese número. Y luego comenzamos a gritarles a los desarrolladores por usar un recurso sin importancia que fue limitado artificialmente. En su lugar, deberíamos volver a subir el número al valor predeterminado y simplemente ignorar las sesiones paralelas aleatorias. Si un usuario no excede los límites de IO o CPU, no debería importar cuántos subprocesos paralelos use.
(Con la posible excepción de prevenir masivo uso de sesiones de consultas paralelas. Ponga a sus usuarios en un perfil diferente y establezca su SESSIONS_PER_USER en unas pocas docenas. NO lo limite a solo 1 o 2. Los IDE necesitan sesiones adicionales para varias pestañas, procesos en segundo plano que capturan metadatos y sesiones de depuración. Si establece el límite en 2, sus desarrolladores no podrán usar un IDE correctamente).
EDITAR (respuesta a los comentarios)
No estoy seguro si puede leer mucho sobre el estado de coordinador de consultas . El control de calidad hace varias cosas, pero idealmente estará inactivo la mayor parte del tiempo mientras que las sesiones paralelas manejan la mayor parte del trabajo.
Con el modelo productor/consumidor, la mitad de las sesiones paralelas pueden recibir datos pero en realidad no están haciendo nada, como si fueran solo estructuras de memoria en algunas operaciones. Las sesiones paralelas pueden cambiar entre activas e inactivas, ya que no todos los pasos necesitarán tantas sesiones. Pero no queremos que Oracle cierre sesiones a la mitad, ya que pueden ser necesarias más adelante y no queremos perder el tiempo abriendo y cerrando sesiones.
Hay docenas de factores que afectan el grado de paralelismo, pero que yo sepa, aumentar PARALLEL_MAX_SERVERS no afectará la cantidad de servidores paralelos solicitados para una sola declaración. (Pero si la declaración ya solicitaba más servidores que el máximo, aumentar el parámetro puede afectar la cantidad de sesiones asignadas).
Puede parecer que las sentencias de SQL simplemente toman aleatoriamente todas las sesiones paralelas, pero, en última instancia, los cálculos de DOP casi siempre siguen reglas deterministas. Es solo que las reglas son tan complicadas que es difícil decir cómo funciona. Por ejemplo, un punto común de confusión es que cada vez que una consulta agrega clasificación o agrupación, la cantidad de sesiones paralelas se duplica.
