Version imprimable
* Bonjour, *
Ma requête fait une jointure entre une table T1 , une table T2 et une table T3.
Que fait l’optimiseur si :
T1 stats calculés.
T2 stats fixées (non à jour)
T3 stats NON calculés mais :
Cas 1 : dynamic sampling activé
Cas 2 : dynamic sampling désactivé
Dans quel cas l’optimiseur devient moins fiable et risque de donner de mauvais résultats ?
* Merci *
Pourquoi n'essayez-vous pas vous-même en procédant à l'analyse des plans d'exécution et/ou des traces d'exécution ?
Il essai d’accomplir sa tache : T1 et T2 ont des statistiques il le prend, T3 n’a pas il utilise dynamic sampling. Si ce mécanisme est désactivé il utilise des valeurs par défaut pour les statistiques manquantes.
Moins les statistiques sont à jour ou indisponible plus des chances d’avoir des mauvais estimations ce qui implique des mauvais ordres de jointure et donc des mauvais plans.
Est ce que le plan peut changer entre une requete utilisant une jointure classique de type (+) et la meme avec jointure normalisee SQL 1999 de type OUTER JOIN ?
Les requêtes ANSI sont transformées à la sauce Oracle avant d’être optimisées donc en principe non.
J'ai pu optimiser cette semaine une requête jointure OUTER JOIN qui fonctionne à merveille en 10g mais déconne en 11g.
J"ai donc JUSTE réécrit en requête en format NON normalisée c'est ok en 11g : est-ce normal ?
J’ai pu dépasser hier la vitesse de la lumière en mettant dans mon réservoir à essence, du miel mélangé aux œufs de crocodile. J’ai juste croisé les doigts deux fois et toucher ma peluche avant de démarrer. C’est normal ou c’était juste 12/12/12 ?Citation:
Envoyé par tropiko