Bardzo ciekawa obserwacja, chociaż nie mogłem jej odtworzyć w mojej bazie danych Oracle (wersja 12.1.0.2.0). Muszę wspomnieć, że używam Oracle Linux 6.5, a nie Windows. W każdym razie dobrze byłoby opublikować plan wykonania również dla tego prostego, ale interesującego zapytania.
Bardzo dziękujemy za opublikowanie planów wykonania, to bardzo dobrze wyjaśnia zachowanie zapytania. Następnie wyjaśnię, zaczynając od pierwszego planu wykonania:
|* 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 |
Jak widać, optymalizator wybiera sprzężenie wewnętrzne zamiast lewego, co jest sygnalizowane przez „HASH JOIN”, a nie „HASH JOIN OUTER”, jak powinno być.
Szczerze mówiąc, nie słyszałem nic o takim błędzie (jak na razie), więc sugerowałbym następujące:
- Sprawdź plik pfile/spfile, jeśli zawiera jakieś nieudokumentowane parametry.
- Zdarzają się przypadki, w których ustawienie tych parametrów może poprawić wydajność, ale często, jak to się mówi, „karma to...”, co może prowadzić do nieoczekiwanych zachowań związanych z wykonywaniem/wydajnością w naprawdę bardzo zły sposób.
