Mycket intressant observation, även om jag inte kunde återskapa den på min Oracle-databas (version 12.1.0.2.0). Jag måste nämna att jag använder Oracle Linux 6.5 och inte Windows. Hur som helst skulle det vara bra att lägga upp exekveringsplanen också för denna enkla men intressanta fråga.
Tack så mycket för att du publicerade exekveringsplanerna, detta förklarar mycket väl hur frågan fungerar. Sedan ska jag förklara, med början med den första genomförandeplanen:
|* 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 |
Som du kan se väljer optimeraren att göra en inre koppling, istället för den vänstra kopplingen, och det visas av "HASH JOIN" och inte "HASH JOIN OUTER" som det borde vara.
För att vara ärlig har jag inte hört något om ett sådant fel (hittills), så jag skulle föreslå följande:
- Kolla in p-filen/sp-filen om den innehåller några odokumenterade parametrar.
- Det finns fall då inställning av dessa parametrar kan förbättra prestandan, men många gånger, "karma är ...", som ordspråket säger, och du kan få oväntade exekverings-/prestandabeteenden på ett riktigt riktigt dåligt sätt.