Pengamatan yang sangat menarik, meskipun saya tidak dapat mereproduksinya di database Oracle (versi 12.1.0.2.0) saya. Saya harus menyebutkan bahwa saya menggunakan Oracle Linux 6.5 dan bukan Windows. Bagaimanapun, akan lebih baik untuk memposting rencana eksekusi juga, untuk kueri yang sederhana namun menarik ini.
Terima kasih banyak telah memposting rencana eksekusi, ini menjelaskan dengan sangat baik perilaku kueri. Kemudian saya akan menjelaskan, dimulai dengan rencana eksekusi pertama:
|* 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 |
Seperti yang Anda lihat, pengoptimal memilih untuk melakukan gabungan dalam, bukan gabungan kiri, dan itu ditunjukkan oleh "HASH JOIN" dan bukan "HASH JOIN OUTER" sebagaimana mestinya.
Sejujurnya, saya tidak mendengar apa pun tentang bug seperti ini (sejauh ini), jadi saya akan menyarankan yang berikut:
- Periksa pfile/spfile jika berisi beberapa parameter yang tidak terdokumentasi.
- Ada kasus ketika pengaturan parameter ini dapat meningkatkan kinerja, tetapi sering kali, "karma adalah ...", seperti kata pepatah, dan Anda dapat memiliki perilaku eksekusi/kinerja yang tidak terduga dengan cara yang benar-benar buruk.
