Osservazione molto interessante, anche se non ho potuto riprodurla sul mio database Oracle (versione 12.1.0.2.0). Devo dire che sto usando Oracle Linux 6.5 e non Windows. Comunque, sarebbe bene pubblicare anche il piano di esecuzione, per questa query semplice ma interessante.
Grazie mille per aver pubblicato i piani di esecuzione, questo spiega molto bene il comportamento della query. Poi ti spiego, partendo dal primo piano di esecuzione:
|* 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 |
Come puoi vedere, l'ottimizzatore sceglie di fare un inner join, invece del left join, e questo viene mostrato da "HASH JOIN" e non da "HASH JOIN OUTER" come dovrebbe essere.
Ad essere onesto, non ho sentito nulla di un bug come questo (finora), quindi suggerirei quanto segue:
- Controlla pfile/spfile se contiene alcuni parametri non documentati.
- Ci sono casi in cui l'impostazione di questi parametri può migliorare le prestazioni, ma molte volte, "il karma è ...", come si suol dire, e puoi avere comportamenti di esecuzione/prestazioni imprevisti in un modo davvero davvero pessimo.
