INDEX_DESC 힌트보다는
ORDER BY alarm_time DESC 정렬구문이 필요해 보입니다.
ROWNUM 조건과 함께 사용한다면 힌트가 의미 있겠지만.
단지 정렬을 위해 추가한 힌트라면
정렬구문으로 바꾸시기를 권합니다.
정렬구문만 사용하더라도 거꾸로 읽어야 할 필요가 있다고 판단된다면
옵티마이저가 지가 알아서 인덱스 거꾸로 읽습니다.

반면에 힌트는 실행계획이 어떻게 세워지는냐에 따라
인덱스를 탈 수도 있고 안탈 수도 있으며
힌트대로 인덱스를 거꾸로 탔다고 치더라도 조인과정에서
정렬이 흐트러질 수 있습니다.
중첩루프(NL)조인의 경우엔 Driving 테이블 조회 순서대로 나오지만
해쉬나 소트머지 조인의 경우엔 그렇지 않지요.
결국 정렬을 원한다면 정렬구문을 추가하세요.

Not In 은 실행계획을 어렵게 만드는 경향이 있습니다.
다른 방식으로 바꿔보세요.
 WHERE user_id IN (SELECT a.user_id
                     FROM t_user a
                        , t_deleted_user b
                    WHERE a.user_no = 1163
                      AND a.user_id = b.user_id(+)
                      AND b.status(+) = 1
                      AND b.user_id IS NULL
                   )

마농님 답변 감사드립니다.

위 sql을 subquery 로 아래처럼 또 추출합니다.

------------------------------------------------

select to_char(seq_no) seq_no from (

select /*+index_desc( t_event  i_event_alarmtime)*/

rownum rnum, seq_no 

from t_event

where ((user_id in  (select user_id from t_user where user_no = 1163))

     and user_id not in (select user_id from t_deleted_user  where status = 1 ) )

     and alarm_time between to_date('2013-03-27 00:00:00','yyyy-mm-dd hh24:mi:ss')

) where rnum > 0 and rownum <= 10;

말씀하신것처럼 rownum 과 사용되기 때문에 hint 는 유효할 거 같습니다.

몇가지 질문이 더 있습니다.

1. 

제 생각에는 where 조건에 alarm_time is not null 을 넣어서 옵티마이저가 꼭 힌트를 타도록 하는게 어떨까 ???  합니다.

     and user_id not in (select user_id from t_deleted_user  where status = 1 ) )

     and alarm_time is not null

     and alarm_time between ~~~

시험서버에서는 정상이고 사이트 서버에서는 간헐적으로 정렬이 잘못되어져 나오는데.

위처럼 추가하면 반드시 힌트를 탈거 같은데요. 어떤가요 ??

2. 사이트 서버에서 sqlplus 사용하여 테스트 해보면 잘 나오는데, 

    애플리케이션에서 수행하면 간헐적 발생합니다. 이러한 애플리케이션에서

수행된 쿼리의 실행계획을 얻으려면 확인방법이 어떤게 있을까요??

부탁드려요 ,. 꾸벅