|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre du Club
![]() Inscription : juin 2003 Messages : 87 ![]() |
bonjour,
je suis en oracle 10.2.0.3 standard sur aix 5L en rac j'ai une requête sur une base 8i sur de l'aix 4 qui met moins de 2 minutes la même requête n'aboutit pas sur ma base rac ! les chemins d'executions sont légérements différents, enc rac j'ai la présence de plusieurs ' merge cartesien join' alors que j'ai des loops en 8i sur ma base rac j'ai reclaculer les statistiques avec le package dbms_gather_schema_stat avec estimate à 100% et un cascade =true je suis en ALL_ROWS et tous mes parèmtres pour l'optimiseur sont en 10.2.0.3 j'ai mis à 8 le paramètre DB_FILE_MULTI_BLOCK_READ_COUNT si je passe en mode RULE (sic) sur ma base 10g rac alors ma requête abouti rapidement (moins d'une minute).(le mode RULE c'est un comble pour une base 10g rac !)( dans ce cas mon chemin d'execution est différent du mode ALL_ROW) quelqu'un a t il une idée de l'origine du problème ? merci d'avance pour vos réponse |
|
|
00
|
|
|
#2 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
c'est probablement dû des NESTED LOOP qui ne sont pas privilégiés dans la 10g. Ce serait quand même mieux d'avoir la requête et les plans d'exécutions.
T'as essayé de recalculer les stats systéme ? |
|
|
00
|
|
|
#3 |
|
Membre du Club
![]() Inscription : juin 2003 Messages : 87 ![]() |
Pour le prooblème des boucles j'ai mis à 100 le paramètre OPTIMIZER_INDEX_CACHING et le plan d'execution est resté le même. (jai de plus flasher la shared pool pour être sur qu'il recalcul le plan)
pour les stats sytème j'ai laissé uniquement le job par défaut faire le calcul, que préconise stu comme calcul supplémentaire ? ce qui me laisse pantois c'est que mon count est faible (265) mais qu'il part en vrille ( 50% de cpu pour la requête) alors qu'en mode RULE la requête passe sans problème ! |
|
|
00
|
|
|
#4 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
stop... là tu fais n'importe quoi. T'as une requête qui pose problème et tu chamboule le paramètrage
d'abord il faut absolument éviter de toucher à OPTIMIZER_INDEX_CACHING, c'est les stats systèmes qui s'occupe de ce point. En plus, il n'y a aucune raison pour qu'il ne fasse pas de NL en touchant ce paramètre. Pour les stats systeme je pensais juste à les actualiser mais laisse tomber. Encore une fois, sans la complétude des infos je ne pourrais pas t'aider |
|
|
00
|
|
|
#5 |
|
Membre du Club
![]() Inscription : juin 2003 Messages : 87 ![]() |
[QUOTE=orafrance]stop... là tu fais n'importe quoi. T'as une requête qui pose problème et tu chamboule le paramètrage
QUOTE] => je n'ai pas de problème avec une requête mais avec quasiment l'ensemble des requêtes d'ou mes modifications de paramétrage. sur le fond je ne comprend pas pourquoi alors que mon cout est faible (265)la requête par en vrille |
|
|
00
|
|
|
#6 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
sans voir le résultat de v$session_wait ni le plan d'exécution j'ai aucun espoir de te donner des pistes... le tuning c'est pas du tatonnement... il y a "un peu" trop de combinaisons possibles dans le paramètrage pour jouer à ce jeu
|
|
|
00
|
|
|
#7 |
|
Membre chevronné
![]() DBA Oracle freelance Inscription : janvier 2005 Messages : 558 ![]() |
Que donne la requête quand tu modifies optimizer_index_cost_adj (à 10 ou 20) au niveau de la session ? C'est censé favoriser les index scan.
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com