Observación muy interesante, aunque no pude reproducirla en mi base de datos Oracle (versión 12.1.0.2.0). Debo mencionar que estoy usando Oracle Linux 6.5 y no Windows. De todos modos, también sería bueno publicar el plan de ejecución para esta consulta simple pero interesante.
Muchas gracias por publicar los planes de ejecución, esto explica muy bien el comportamiento de la consulta. Luego explicaré, comenzando con el primer plan de ejecució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 |
Como puede ver, el optimizador elige hacer una combinación interna, en lugar de la combinación izquierda, y eso se muestra mediante "HASH JOIN" y no "HASH JOIN OUTER" como debería ser.
Para ser honesto, no escuché nada sobre un error como este (hasta ahora), por lo que sugeriría lo siguiente:
- Revise el pfile/spfile si contiene algunos parámetros no documentados.
- Hay casos en los que configurar estos parámetros puede mejorar el rendimiento, pero muchas veces, "el karma es...", como dice el refrán, y puede tener comportamientos inesperados de ejecución/rendimiento de una manera muy, muy mala.
