Velmi zajímavý postřeh, i když jsem jej nemohl reprodukovat v mé databázi Oracle (verze 12.1.0.2.0). Musím zmínit, že používám Oracle Linux 6.5 a ne Windows. Každopádně by bylo dobré zveřejnit plán provedení také pro tento jednoduchý, ale zajímavý dotaz.
Velice vám děkuji za zveřejnění prováděcích plánů, velmi dobře to vysvětluje chování dotazu. Poté vysvětlím, počínaje prvním plánem provádění:
|* 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 můžete vidět, optimalizátor se rozhodne provést vnitřní spojení namísto levého spojení, což se projevuje „HASH JOIN“ a nikoli „HASH JOIN OUTER“, jak by mělo být.
Abych byl upřímný, o takové chybě (zatím) jsem nic neslyšel, takže bych navrhl následující:
- Podívejte se na soubor pfile/spfile, zda neobsahuje nějaké nezdokumentované parametry.
- Jsou případy, kdy nastavení těchto parametrů může zlepšit výkon, ale často se stává, že „karma je...“, jak se říká, a můžete mít neočekávané chování při provádění/výkonu opravdu velmi špatným způsobem.