Zeer interessante observatie, hoewel ik het niet kon reproduceren op mijn Oracle (versie 12.1.0.2.0) database. Ik moet vermelden dat ik Oracle Linux 6.5 gebruik en niet Windows. Hoe dan ook, het zou goed zijn om ook het uitvoeringsplan te posten voor deze eenvoudige, maar interessante vraag.
Hartelijk dank voor het plaatsen van de uitvoeringsplannen, dit verklaart heel goed het gedrag van de query. Dan zal ik het uitleggen, te beginnen met het eerste uitvoeringsplan:
|* 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 |
Zoals je kunt zien, kiest de optimizer ervoor om een inner join te doen, in plaats van de left join, en dat wordt weergegeven door de "HASH JOIN" en niet door "HASH JOIN OUTER" zoals het hoort.
Om eerlijk te zijn, heb ik (tot nu toe) niets gehoord over een bug als deze, dus ik zou het volgende willen voorstellen:
- Bekijk het pfile/spfile als het enkele ongedocumenteerde parameters bevat.
- Er zijn gevallen waarin het instellen van deze parameters de prestatie kan verbeteren, maar vaak, "karma is ...", zoals het gezegde luidt, en je kunt onverwacht uitvoerings-/prestatiegedrag hebben op een heel erg slechte manier.