Limitez le degré de parallélisme (DOP) disponible pour toute requête

Sur Oracle Exadata (11gR2), nous avons une base de données relativement solide.

• cpu_count a 24 ans
• parallel_server_instances est 2
• parallel_threads_per_cpu vaut 2

Nous avons remarqué, en observant dans Oracle Enterprise Manager (OEM), que les performances étaient terribles en raison des requêtes exécutées en série. Pour résoudre ce problème, toutes les tables, vues matérialisées et index ont été modifiés pour tirer parti du parallélisme. par exemple:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

Le système a été modifié pour activer la parallélisation:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Cela a entraîné de meilleures performances, mais nous avons parfois observé dans OEM qu'une seule requête bloquait un DOP de 96 (toutes les ressources disponibles). Cela a entraîné la rétrogradation des requêtes suivantes à un DOP de 1 (pas de parallélisation). Il en résulte des performances médiocres jusqu'à la fin de la requête de monopolage.

Pour résoudre ce problème, nous avons essayé de limiter le DOP disponible à toute requête avec:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Cela n'a eu aucun effet. Nous observons fréquemment des requêtes qui utiliseront plus que la limite (généralement 48 ou 96, mais aucun modèle réel).

Comment empêcher une seule requête de monopoliser toutes les ressources disponibles?

Ensembles de serveurs parallèles: PARALLEL_DEGREE_LIMIT limite le degré de parallélisme, mais si votre requête trie ou regroupe le nombre de processus parallèles peut être deux fois plus (deux ensembles de serveurs pour activer le parallélisme inter-processus). Cela explique pourquoi vous verrez 48 processus parallèles même avec une limite de 24. Cela se produit également si vous utilisez le gestionnaire de ressources pour limiter le DOP.

Conseils parallèles: PARALLEL_DEGREE_LIMIT s'applique uniquement aux instructions qui utilisent le degré automatique de parallélisme. Toutes les instructions qui utilisent un degré codé en dur, ou même n'importe quel type d'indication parallèle au niveau de l'objet, ignoreront la limite. Si vous avez ces indices, cela pourrait expliquer pourquoi vous voyez 96 fois.

Calibrate IO: Peut - être que le DOP automatique n'est pas utilisé, et donc la limite n'est pas respectée, car le IO n'a pas été calibré . Cette requête vous dira si l'IO a été calibré:

select * from V$IO_CALIBRATION_STATUS;

J'ai déjà vu cela causer des problèmes, mais mon système actuel n'est pas calibré et le DOP automatique semble fonctionner correctement. Vous pouvez savoir si c'est vraiment un problème en consultant la section Notes du plan d'explication. Si vous voyez quelque chose comme si - automatic DOP: Computed Degree of Parallelism is 2vous allez bien, mais vous ne voulez pas voir automatic DOP: skipped because of IO calibrate statistics are missing.

Augmenter PARALLEL_MAX_SERVERS: au lieu de vous soucier de manquer de serveurs parallèles, je vous recommande d'augmenter considérablement PARALLEL_MAX_SERVERS. Vous devez au moins essayer de revenir à la valeur par défaut , PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, entre 240 et 960 selon vos paramètres de mémoire.

Ces chiffres élevés semblent ridicules pour de nombreux administrateurs de base de données, mais ils ont en fait beaucoup de sens pour les raisons suivantes:

• Les serveurs parallèles Oracle sont plus légers que la plupart des gens ne le pensent. (Et presque personne ne le teste jamais, ils trouvent juste une situation où un grand DOP cause un problème et supposent qu'un DOP élevé est toujours mauvais.)
• Il est courant d'exécuter une requête ad hoc dans un outil GUI qui ne récupère que les 50 premières lignes, mais utilise toujours des dizaines de serveurs parallèles. Ces requêtes ne consomment PAS de ressources importantes, sauf si PARALLEL_MAX_SERVERS est trop faible. Ensuite, les gens sont criés pour avoir exécuté des requêtes parfaitement raisonnables, ce qui peut conduire à des situations laides.
• Un très grand DOP pour une seule requête n'est pas toujours mauvais. Tout le monde suppose que si vous continuez d'augmenter le DOP, le temps système deviendra trop élevé et les performances diminueront considérablement. Mais sur de nombreux systèmes, j'ai trouvé que même un DOP ridiculement élevé conduirait à de meilleures performances, bien qu'il y ait certainement des rendements décroissants, et cela peut être très injuste pour d'autres sessions. Mais ne vous contentez pas de deviner, testez-le; prendre une requête et l'exécuter avec toutes sortes de DOP, jusqu'à 1000. Vous pourriez être surpris.
• Oui, trop de parallélisme peut être mauvais. Mais qu'est-ce qui est pire pour le système, avoir un nombre légèrement supérieur au nombre optimal de sessions, ou forcer une requête en série et tuer un travail important? Vous devez surveiller le système avant d'introduire des limites arbitraires.