Vos requêtes ne sont pas vraiment complètes. Bien que votre requête ne récupère que les 1 000 premières lignes, SQL Developer ne récupère que les 50 premières lignes de ces 1 000 lignes. L'IDE ne fermera pas le curseur tant que vous n'aurez pas fait défiler jusqu'à la dernière ligne. Une fois que vous avez récupéré toutes les données, ces processus parallèles disparaissent. Assurez-vous de voir "All Rows Fetched:1000 in X seconds", au lieu de ""Fetched 50 rows in Y seconds". (J'aimerais que SQL Developer rende plus évident visuellement qu'il y a des lignes supplémentaires en attente.) Vous ne le ferez pas voyez ce problème dans SQL*Plus car SQL*Plus récupère toujours toutes les lignes.
Lorsque seules les N premières lignes sont extraites, ces processus parallèles sont "ACTIFS" mais ne font rien. Vous devriez pouvoir ignorer ces sessions puisqu'elles n'utilisent pas de ressources importantes.
Si vous êtes préoccupé par le nombre de sessions parallèles, vous voudrez peut-être ajuster vos attentes. J'étais dans la même situation que vous - disant constamment aux utilisateurs que leurs requêtes (incomplètes) monopolisaient toutes les sessions parallèles. Finalement, j'ai découvert que c'était seulement un problème parce que j'avais créé une ressource artificiellement rare. Les processus parallèles Oracle sont généralement légers et les bases de données peuvent prendre en charge bien plus de processus parallèles que la plupart des gens ne le pensent.
Quelles sont vos valeurs de paramètres pour PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU et CPU_COUNT ? Regardez la valeur par défaut pour PARALLEL_MAX_SERVERS
. Selon le manuel, le nombre par défaut est :PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
La plupart des DBA voient un nombre maximum de threads parallèles dans les centaines, paniquent, puis diminuent ce nombre. Et puis nous commençons à crier après les développeurs pour avoir utilisé une ressource sans importance qui était artificiellement limitée. Au lieu de cela, nous devrions remonter le nombre à la valeur par défaut et ignorer simplement les sessions parallèles aléatoires. Si un utilisateur ne dépasse pas les limites d'E/S ou de CPU, le nombre de threads parallèles qu'il utilise ne devrait pas avoir d'importance.
(À l'exception peut-être de la prévention massive utilisation de session de requête parallèle. Mettez vos utilisateurs dans un profil différent et définissez leur SESSIONS_PER_USER sur quelques dizaines. Ne le limitez PAS à 1 ou 2. Les IDE ont besoin de sessions supplémentaires pour plusieurs onglets, de processus d'arrière-plan qui récupèrent les métadonnées et de sessions de débogage. Si vous définissez la limite à 2, vos développeurs ne pourront pas utiliser correctement un IDE.)
EDIT (réponse aux commentaires)
Je ne sais pas si vous pouvez lire beaucoup sur l'état du coordinateur des requêtes . Le CQ fait plusieurs choses, mais idéalement, il sera inactif la plupart du temps pendant que les sessions parallèles gèrent la majeure partie du travail.
Avec le modèle producteur/consommateur, la moitié des sessions parallèles peuvent recevoir des données mais ne rien faire vraiment - comme s'il s'agissait simplement de structures de mémoire dans certaines opérations. Les sessions parallèles peuvent basculer entre actives et inactives, car toutes les étapes ne nécessiteront pas autant de sessions. Mais nous ne voudrions pas qu'Oracle ferme les sessions au milieu, car elles pourraient être nécessaires plus tard et nous ne voudrions pas perdre de temps à ouvrir et à fermer les sessions.
Il existe des dizaines de facteurs qui affectent le degré de parallélisme, mais pour autant que je sache, l'augmentation de PARALLEL_MAX_SERVERS n'affectera pas le nombre de serveurs parallèles demandés pour une seule instruction. (Mais si l'instruction demandait déjà plus de serveurs que le maximum, l'augmentation du paramètre peut affecter le nombre de sessions allouées).
Il peut sembler que les instructions SQL saisissent au hasard toutes les sessions parallèles, mais en fin de compte, les calculs DOP suivent presque toujours des règles déterministes. C'est juste que les règles sont si compliquées qu'il est difficile de dire comment cela fonctionne. Par exemple, un point commun de confusion est que chaque fois qu'une requête ajoute un tri ou un regroupement, le nombre de sessions parallèles est doublé.
