Oracle: Différence dans les plans d'exécution entre les bases de données

Question

Je compare les requêtes de ma base de données de développement et de production.

Ils sont tous les deux Oracle 9i, mais presque chaque requête a un plan d'exécution complètement différent selon la base de données.

Tous les tableaux/index sont les mêmes, mais la base de données dev a environ 1/10ème les lignes pour chaque table. En production, le plan d'exécution de la requête qu'il choisit pour la plupart des requêtes est différent du développement, et le coût est parfois 1 000 fois plus élevé. Les requêtes sur la production semblent également ne pas utiliser les index corrects pour les requêtes dans certains cas (accès à la table complète). J'ai déjà lancé le schéma dbms_utility.analyze sur les deux bases de données récemment, dans l'espoir que l'OBC trouverait quelque chose.

Y a-t-il une autre configuration Oracle sous-jacente qui pourrait être à l'origine de cela?

Je suis un développeur surtout si ce type d'analyse DBA est assez déroutant au premier abord ..

Answer 1

1) La première chose que je voudrais vérifier est si les paramètres de base de données sont équivalentes dans Prod et Dev. Si l'un des paramètres affectant les décisions de l'Optimiseur basé sur les coûts est différent, tous les paris sont désactivés. Vous pouvez voir le paramètre dans v $ parameter view;

2) Avoir des statistiques d'objets à jour est super mais gardez à l'esprit la grande différence que vous avez signalée - Dev a 10% des rangées de Prod. Ce nombre de lignes est pris en compte dans la façon dont le CBO décide de la meilleure façon d'exécuter une requête. Compte tenu de la grande différence dans le nombre de lignes, je ne m'attendrais pas à ce que les plans soient les mêmes. En fonction des circonstances, l'optimiseur peut choisir de Table complète Analyser une table avec 20 000 lignes (Dev) où il peut décider qu'un index est moins cher sur la table qui a 200 000 lignes (Prod). (Numéros juste pour la démonstration, le CBO utilise des algorithmes de calcul des coûts pour déterminer ce que FTS et ce que l'index numérise, et non des valeurs absolues).

3) Les statistiques du système tiennent également compte des plans d'explication. Il s'agit d'un ensemble de statistiques représentant les caractéristiques d'E/S du processeur et du disque. Si votre matériel sur les deux systèmes est différent, je m'attendrais à ce que vos statistiques système soient différentes et cela peut affecter les plans. Une bonne discussion de Jonathan Lewis here Vous pouvez voir les statistiques du système via la vue sys.aux_stats $. Maintenant, je ne sais pas pourquoi les différents plans sont une mauvaise chose pour vous ... si les statistiques sont à jour et les paramètres correctement définis, vous devriez obtenir des performances décentes de l'un ou l'autre système, peu importe la différence de taille ..

mais il est possible d'exporter des statistiques de votre système Prod et de les charger dans votre système de développement. Cela rend vos statistiques Prod disponibles pour votre base de données Dev.

Vérifiez la documentation Oracle pour le package DBMS_STATS, en particulier les procédures EXPORT_SCHEMA_STATS, EXPORT_SYSTEM_STATS, IMPORT_SCHEMA_STATS, IMPORT_SYSTEM_STATS. Gardez à l'esprit que vous devrez peut-être désactiver les tâches de statistiques nocturnes de 10pm sur 10g/11g ... ou vous pouvez examiner les statistiques de verrouillage après l'importation afin qu'elles ne soient pas mises à jour par les tâches nocturnes.