Meget interessant observation, selvom jeg ikke kunne gengive den på min Oracle (version 12.1.0.2.0) database. Jeg er nødt til at nævne, at jeg bruger Oracle Linux 6.5 og ikke Windows. Under alle omstændigheder ville det være godt at poste udførelsesplanen også for denne enkle, men interessante forespørgsel.
Mange tak fordi du har lagt udførelsesplanerne ud, dette forklarer meget godt forespørgslens opførsel. Så vil jeg forklare, begyndende med den første udførelsesplan:
|* 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ælger optimizeren at lave en indre joinforbindelse, i stedet for den venstre joinforbindelse, og det fremgår af "HASH JOIN" og ikke "HASH JOIN OUTER", som det burde være.
For at være ærlig har jeg ikke hørt noget om en fejl som denne (indtil videre), så jeg vil foreslå følgende:
- Tjek p-filen/sp-filen, hvis den indeholder nogle udokumenterede parametre.
- Der er tilfælde, hvor indstilling af disse parametre kan forbedre ydeevnen, men mange gange, "karma er ...", som man siger, og du kan have uventet eksekverings-/ydelsesadfærd på en rigtig dårlig måde.