Version imprimable
Bonjour à tous,
je rencontre un petit soucis sur l'exécution d'une requête dont le temps d'exécution en PRODUCTION est très long (entre 15s et près d'1 minute) alors qu'en VALIDATION cette requête s'exécute en moins d'1s.
On est 10gR2.
Y'aurait-il des paramètres qui jouent sur le temps d'exécution d'un requête?
merci pour votre aide.:D
Il y a au moins les paramètres documentés dans le Performance and Tuning Guide. La façon dont les statistiques sont calculées avec DBMS_STATS jouent aussi un rôle, comme la version exacte d'Oracle installée (y compris le niveau de patch de sécurité "CPU PATCH").
Pour analyser ce genre de problème, il faut aussi pouvoir comparer les plans d'exécution dans les 2 environnements (EXPLAIN PLAN).
Je suppose que vous avez bien le même modèle physique de données (tables, index, contraintes), les mêmes données, des machines de puissances identiques et avec une charge comparable...
S'il n'y avait que les paramètres qui entrent en ligne de compte !
Il y a aussi la volumétrie, les statistiques, les structures (index, partitionnement), les capacités des serveurs (cpu, ram, disques), les versions d'Oracle.
Décidément les problèmes de performances d'un même objet entre divers environnements est monnaie courante...
Comparer les deux EXPLAIN PLAN permettra avant tout de choisir entre problème physique ou bien problème de logique.
Généralement c'est le deuxième qui l'emporte, les statistiques de production et/ou les volumétries de données et/ou les volumétries de stress étant différentes entre deux environnements, l'un donne de meilleurs résultats que l'autre et inversement.
Première chose à comparer entre les deux bases, la configuration de l'OPTIMIZER et la date de mise à jour des statistiques (95% des cas).
Alors, concernant l'optimizer, le paramètre optimizer_index_cost_adj a été modifié ce amtin pour mise à l'identique à la valeur de l'environemment de validation qui ne rencontre pas de pb.
Pour le calcul des stats, c'est effectué tous les 3 jours.
je ne suis pas du tout expert Oracle...
Je vais jeter un oeil pour l'explain plan et voir comment ça fonctionne.
je vous tiens au courant.
Merci pour vos pistes.
paramètres de l'optimizer en VALIDATION:
_optimizer_join_sel_sanity_check boolean TRUE
_optimizer_sortmerge_join_enabled boolean FALSE
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 10
optimizer_mode string first_rows_100
optimizer_secure_view_merging boolean TRUE
paramètres de l'optimizer en PRODUCTION:
------------------------------------ ----------- ---------
_optimizer_join_sel_sanity_check boolean TRUE
_optimizer_sortmerge_join_enabled boolean FALSE
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 10
optimizer_mode string all_rows
optimizer_secure_view_merging boolean TRUE
La valeur de paramètre qui change est l'optimizer_mode
Mets déjà le paramétrage en phase avec ta production et testes à nouveau. Le mode FIRST_ROWS_N permet de choisir le meilleur plan d'exécution pour retourner les N premières lignes (N = 1 ou 10 ou 100 ou 1000).
Maintenant si toucher à ce paramètre dégrade ta validation au point d'être en phase avec ta production ce sera déjà mieux (C'est un point de vue).
Restera à tester divers modes (ALL_ROWS ou bien FIRST_ROWS_N) et voir ce qui te donne de meilleurs réponses.
Ton OPTIMIZER_INDEx_COST_ADJ est à 10, cela veut dire qu'il a été touché (100 par défaut). Généralement on essai par dichotomie (50 puis 25, ...) afin de trouver le meilleurs poids pour les indexs. Tu peux aussi regarder là.
Une êtite précision.
je rencontre mon pb depuis 2 semaines en production.
Auparavant, la requête incriminé s'effectuait sans pb.
Et entre temps, rien n'a été modifié dans l'environnement de production (si ce n'est lapplication de patches de sécurité Microsoft)
Un patch Microsoft qui influerait l'Optimizer, ce coups ci on est au fond...
:mouarf:
Le fait que ta requête s'effectuait sans problème il y a deux semaines et plus depuis peut témoigner d'une fragmentation élevée de tes blocks. Il faut en premier lieu mettre ta validation au même niveau que la production. Le mieux étant un export/import voir une restauration.
surtout, en principe on calcule les stats systéme pour rendre ce paramétre inutile.Citation:
Envoyé par philcero
Si j'ai bien compris tu es passé de all_rows à first_rows_100, on peut donc imaginer que tu utilises désormais des indexes au lieu de FTS ce qui peut dans certains cas être défavorable.
En ce qui concerne l'export, depuis que le pb s'est manifesté, j'ai fait un export du schéma de production vers la validation.
Après cet export, aucun pb d'exécution de la requête en validation.
Si tu as fait un export tu as les mêmes données, mais as-tu les mêmes statistiques ?
Mon pb est résolu.
j'ai remis les paramètres de PROD à l'équivalence de ceux qu'il y avait en VAL.
Je ne sais pas pourquoi du jour au lendemain j'ai eu ce pb!
<en tout cas, tout est rentré dans l'ordre.
merci à vous.:yaisse2:
all_rows ça change les plan d'exécution faut pas chercher plus loin :mouarf: