Sehr interessante Beobachtung, obwohl ich sie auf meiner Oracle-Datenbank (Version 12.1.0.2.0) nicht reproduzieren konnte. Ich muss erwähnen, dass ich Oracle Linux 6.5 und nicht Windows verwende. Wie auch immer, es wäre gut, auch den Ausführungsplan für diese einfache, aber interessante Abfrage zu posten.
Vielen Dank für das Posten der Ausführungspläne, dies erklärt sehr gut das Verhalten der Abfrage. Dann werde ich erklären, beginnend mit dem ersten Ausführungsplan:
|* 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 |
Wie Sie sehen können, entscheidet sich der Optimierer für einen inneren Join anstelle des linken Joins, und das wird durch "HASH JOIN" und nicht durch "HASH JOIN OUTER" angezeigt, wie es sein sollte.
Um ehrlich zu sein, habe ich (bisher) nichts über einen solchen Fehler gehört, daher würde ich Folgendes vorschlagen:
- Schauen Sie sich die pfile/spfile an, wenn sie undokumentierte Parameter enthält.
- Es gibt Fälle, in denen die Einstellung dieser Parameter die Leistung verbessern kann, aber oft gilt „Karma ist …“, wie das Sprichwort sagt, und Sie können unerwartetes Ausführungs-/Leistungsverhalten auf wirklich sehr, sehr schlechte Weise haben.
