Много интересно наблюдение, въпреки че не можах да го възпроизведа в моята база данни Oracle (версия 12.1.0.2.0). Трябва да спомена, че използвам Oracle Linux 6.5, а не Windows. Както и да е, би било добре да публикувам и плана за изпълнение за тази проста, но интересна заявка.
Благодаря ви много, че публикувахте плановете за изпълнение, това обяснява много добре поведението на заявката. След това ще обясня, започвайки с първия план за изпълнение:
<предварителен код>|* 2 | ХЕШ ПРИСЪЕДИНЯВАНЕ | | 1 | 17 | 8 (0)| 00:00:01 || 3 | ПРЕГЛЕД | | 2 | 14 | 4 (0)| 00:00:01 || 4 | СОРТИРАНЕ УНИКАЛНО | | 2 | | 4 (50)| 00:00:01 || 5 | СЪЮЗ-ВСИЧКИ | | | | | || 6 | БЪРЗ ДВОЙЕН | | 1 | | 2 (0)| 00:00:01 || 7 | БЪРЗ ДВОЙЕН | | 1 | | 2 (0)| 00:00:01 || 8 | ПРЕГЛЕД | | 2 | 20 | 4 (0)| 00:00:01 || 9 | СОРТИРАНЕ УНИКАЛНО | | 2 | | 4 (50)| 00:00:01 || 10 | СЪЮЗ-ВСИЧКИ | | | | | || 11 | БЪРЗ ДВОЙЕН | | 1 | | 2 (0)| 00:00:01 || 12 | БЪРЗ ДВОЙЕН | | 1 | | 2 (0)| 00:00:01 |Както можете да видите, оптимизаторът избира да направи вътрешно присъединяване, вместо ляво присъединяване, и това се показва от „HASH JOIN“, а не от „HASH JOIN OUTER“, както би трябвало да бъде.
Честно казано, не съм чувал нищо за подобен бъг (досега), така че бих предложил следното:
- Проверете pfile/spfile, ако съдържа някои недокументирани параметри.
- Има случаи, когато задаването на тези параметри може да подобри производителността, но много пъти „кармата е ...“, както се казва, и можете да имате неочаквано поведение при изпълнение/производителност по наистина много лош начин.
