.

실행계획을 안본 상태에서 말씀을 드리기는 어렵구요.
별다른 where 조건은 없나요? 

DATA 쪽에 Seek된 Row가 많고  USER  와 loop join 이 되어서  생긴 문제 ( USER_NAME 값을 가지고 올 때  )라는 전제 아래
아직 초보인 저라면 일차적으로 다음과 같은 방법을 떠올릴 수 있을 것 같아요.

1) LEFT JOIN USER  을  hash 같은 힌트를 주어서 해보는 방법  (물론 USER 의 데이터 량과 사이즈가 크면 좀 힘드네요. )
2) USER  에서 가지고 오는 데이터가 USER_NAME 만 있다면, inner 쿼리로

       SELECT
  .......
       FROM DATA A 
       LEFT JOIN (SELECT ID, USER_NAME FROM USER  )   AS B    ON A.ID = B.ID

  바꾸어서 한번 해 보심은....

3)  SELECT ID, USER_NAME FROM USER  이 부분을 임시테이블로 내려서  JOIN 을 해 보세요.

 SELECT ID, USER_NAME INTO #USER  FROM USER ;

 SELECT
  .....
 , A.DATA20
 , B.USER_NAME
 FROM DATA A
 LEFT JOIN #USER B   -- 임시테이블 사용.
 ON A.ID = B.ID;

4) USER 에 아예 인클루드 인덱스를 새로 만드세요.. ㅜㅜ
물론 USER_NAME 의 데이터가 크지 않다는 전제 입니다.  ( 이름인데... 설마 크진 않겠지요?? )
굳히 정렬이 될 필요는 없으니까, include option 으로  USER_NAME 을 추가하는 것을 생각할 수도 있겠네요.

5) USER table 통계정보나, 테이블 단편화를 한점 점검해 보세여.

JOIN 조건인 ID 값의 구조를 잘 몰라서 뭐라 말씀 드릴 수 없지만....
ID 가 순차적으로 발생하는 구조가 아니라면, 테이블 단편화 때문에  비슷한 경험을 한 적이 있습니다.

2번의 경우 B.USER_NAME 에 의한 키룩업이 속도저하의 원인 아닐까요.