9i 까지는 진실이었는데 10g 부터 미신이 된 케이스입니다.
아래 SQL 과 trace 결과를 보시죠.

select count(ename), count(loc)
from   dept d, big_emp e
where  e.deptno = d.deptno(+)

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.000        0.002          0          0          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        2    0.656        0.764        234        238          0          1
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        4    0.656        0.765        234        238          0          1

Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user: SCOTT (ID=60)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  STATEMENT
      1   SORT AGGREGATE (cr=238 pr=234 pw=0 time=763588 us)
  38416    HASH JOIN RIGHT OUTER (cr=238 pr=234 pw=0 time=645634 us)
      5     TABLE ACCESS FULL DEPT (cr=7 pr=6 pw=0 time=15960 us)
  38416     TABLE ACCESS FULL BIG_EMP (cr=231 pr=228 pw=0 time=206029 us)

이상한 점을 발견하셨나요?

(+) 기호가 붙은 dept 테이블 즉 small table 이 먼저 드라이빙된다는 것입니다.

hash join 의 경우 드라이빙되는 테이블의 크기가 작아야 성능이 좋아지는데
outer join 의 경우 (+) 기호가 붙으면 항상 드라이빙되지 않았던 게 9i 까지의 동작이었습니다.

10g 의 경우 RIGHT OUTER JOIN 방식으로 작은 테이블을 먼저 드라이빙할 수 있도록 변경되었습니다.
Nested Loop Join 의 경우는 여러분이 테스트해 보세요.

ProDBA Cafe 에도 동일한 내용을 올립니다.