ce qui pourrait provoquer une fusion cartésienne jointe

Question

J'ai une requête super simple dans un schéma en étoile. Un fait, deux dimensions. J'ai vérifié que je fais les jointures correctement. Mais lorsque j'exécute le plan de requête, j'obtiens une fusion cartésienne de fusion juste avant les étapes pour ajouter les dimensions. Si je change de rechercher par l'ID de dimension au lieu du code, mon plan est bien - pas cartésien.

explain plan for 
select * from fact f 
inner join dim1 d1 
    on d1.id = f.d1_id 
inner join dim2 d2 
    on d2.id = f.d2_id 
where d1.id= '1' and d2.id = '2'; 

Des idées qui pourraient causer le cartésien?

EDIT: Je viens de créer les tables et les index aujourd'hui. Je vais vérifier que j'ai fait des «statistiques de calcul» sur eux pour être sûr que tout est à jour.

plus d'informations sur les tables maintenant que je les ai édités et se sont débarrassés de la cartésienne:

Table de fait:

index bitmap sur dim1.id

index bitmap sur dim2.id

(et beaucoup d'autres indices de bitmap)

Dim1

index unique sur l'ID

index bitmap sur le code - ceci est nouveau, mais il n'a pas semblé changer le plan de requête any.

Dim2

index unique sur id

d'index unique sur le code --Quand j'ai ajouté cela, le cartésienne est parti.

Ma table de faits a 50 millions d'enregistrements, dim1 a 44 enregistrements et dim2 a 6 enregistrements. Je n'avais donc pas d'index sur des tables aussi courtes. Mais l'ajout de l'index unique à dim2 est ce qui s'est débarrassé de la jointure cartésienne et a fait passer l'estimation du temps du plan de requête de 5 minutes à quelques secondes.

Answer 1

Il semble que "ID" soit beaucoup plus sélectif que "code", donc l'optimiseur décide d'appliquer les conditions après la jointure. Essayez si l'ajout d'index sur le code (si possible, uniques) change quelque chose et vous donne des résultats plus rapides.

Answer 2

Il y a plusieurs choses à voir ici.

Premièrement, comment les plans d'exécution se comparent-ils en termes de cardinalités estimées? Cela peut être un facteur très important de changements de plan. Si vos statistiques sont obsolètes (essayez d'utiliser l'échantillonnage dynamique), les cardinalités des ensembles de résultats de dimension peuvent être incorrectement très faibles ou très élevées. Deuxièmement, dans cette dernière requête Oracle utilise probablement la transitivité pour appliquer ces prédicats directement à la table de faits, auquel cas il peut avoir une estimation beaucoup plus précise de la taille du jeu de résultats de cette table (en particulier avec l'échantillonnage dynamique) ou statistiques multicolonnes dans 11g).

Cependant, les plans d'explication sont critiques pour l'analyse.