Suas consultas não estão realmente completando. Embora sua consulta busque apenas as primeiras 1.000 linhas, o SQL Developer está buscando apenas as primeiras 50 linhas dessas 1.000 linhas. O IDE não fechará o cursor até que você role até a última linha. Depois de recuperar todos os dados, esses processos paralelos desaparecem. Certifique-se de ver "Todas as linhas buscadas:1000 em X segundos", em vez de "" Buscadas 50 linhas em Y segundos". (Eu gostaria que o SQL Developer tornasse mais visualmente óbvio que há linhas adicionais esperando.) veja esse problema no SQL*Plus porque o SQL*Plus sempre pega todas as linhas.

Quando apenas as primeiras N linhas são buscadas, esses processos paralelos estão "ATIVOS", mas não estão fazendo nada. Você deveria ser capaz de ignorar essas sessões, pois elas não estão usando nenhum recurso significativo.

Se você está preocupado apenas com o número de sessões paralelas, convém ajustar suas expectativas. Eu costumava estar na mesma situação que você - constantemente dizendo aos usuários que suas consultas (incompletas) estavam monopolizando todas as sessões paralelas. Eventualmente, descobri que era apenas um problema porque eu havia criado um recurso artificialmente escasso. Os processos paralelos da Oracle geralmente são leves e os bancos de dados podem suportar muito mais processos paralelos do que a maioria das pessoas pensa que podem.

Quais são seus valores de parâmetro para PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU e CPU_COUNT? Veja o valor padrão para PARALLEL_MAX_SERVERS . De acordo com o manual, o número padrão é:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .

A maioria dos DBAs vê um número máximo de threads paralelos na casa das centenas, entra em pânico e diminui esse número. E então começamos a gritar com os desenvolvedores por usarem um recurso sem importância que era limitado artificialmente. Em vez disso, devemos aumentar o número de volta ao padrão e simplesmente ignorar sessões paralelas aleatórias. Se um usuário não está excedendo os limites de E/S ou CPU, não importa quantos threads paralelos ele usa.

(Com a possível exceção de evitar massivos uso da sessão de consulta paralela. Coloque seus usuários em um perfil diferente e defina seu SESSIONS_PER_USER para algumas dezenas. NÃO o limite a apenas 1 ou 2. IDEs precisam de sessões extras para várias guias, processos em segundo plano que capturam metadados e sessões de depuração. Se você definir o limite para 2, seus desenvolvedores não poderão usar um IDE corretamente.)

EDITAR (resposta aos comentários)

Não tenho certeza se você pode ler muito sobre o status do coordenador de consultas . O QC faz várias coisas, mas idealmente ele ficará ocioso a maior parte do tempo enquanto as sessões paralelas lidam com a maior parte do trabalho.

Com o modelo produtor/consumidor, metade das sessões paralelas podem estar recebendo dados, mas não fazendo nada - como se fossem apenas estruturas de memória em algumas operações. As sessões paralelas podem alternar entre ativa e inativa, pois nem todas as etapas precisarão de tantas sessões. Mas não queremos que a Oracle feche as sessões no meio, pois elas podem ser necessárias mais tarde e não queremos perder tempo abrindo e fechando sessões.

Existem dezenas de fatores que afetam o grau de paralelismo, mas pelo que sei, aumentar PARALLEL_MAX_SERVERS não afetará o número de servidores paralelos solicitados para uma única instrução. (Mas se a declaração já estava pedindo mais servidores que o máximo, aumentar o parâmetro pode afetar o número de sessões alocadas).

Pode parecer que as instruções SQL estão apenas capturando aleatoriamente todas as sessões paralelas, mas, em última análise, os cálculos DOP quase sempre seguem regras determinísticas. É só que as regras são tão complicadas, é difícil dizer como funciona. Por exemplo, um ponto comum de confusão é que sempre que uma consulta adiciona classificação ou agrupamento, o número de sessões paralelas é dobrado.