Observation très intéressante, même si je n'ai pas pu la reproduire sur ma base de données Oracle (version 12.1.0.2.0). Je dois mentionner que j'utilise Oracle Linux 6.5 et non Windows. Quoi qu'il en soit, il serait bon de publier également le plan d'exécution, pour cette requête simple mais intéressante.
Merci beaucoup d'avoir posté les plans d'exécution, cela explique très bien le comportement de la requête. Ensuite, je vais vous expliquer, en commençant par le premier plan d'exécution :
|* 2 | HASH JOIN | | 1 | 17 | 8 (0)| 00:00:01 |
| 3 | VIEW | | 2 | 14 | 4 (0)| 00:00:01 |
| 4 | SORT UNIQUE | | 2 | | 4 (50)| 00:00:01 |
| 5 | UNION-ALL | | | | | |
| 6 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 7 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 8 | VIEW | | 2 | 20 | 4 (0)| 00:00:01 |
| 9 | SORT UNIQUE | | 2 | | 4 (50)| 00:00:01 |
| 10 | UNION-ALL | | | | | |
| 11 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 12 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
Comme vous pouvez le voir, l'optimiseur choisit de faire une jointure interne, au lieu de la jointure gauche, et cela est indiqué par le "HASH JOIN" et non "HASH JOIN OUTER" comme il se doit.
Pour être honnête, je n'ai rien entendu à propos d'un bogue comme celui-ci (jusqu'à présent), donc je suggérerais ce qui suit :
- Consultez le pfile/spfile s'il contient des paramètres non documentés.
- Il y a des cas où la définition de ces paramètres peut améliorer les performances, mais souvent, "le karma est ...", comme le dit le dicton, et vous pouvez avoir des comportements d'exécution/performance inattendus d'une très très mauvaise manière.
