How to avoid sort when using a composite index?

Create a test table:

create table customer (first_name varchar2(20), last_name varchar2(20) not null, address varchar(20));

insert into customer select dbms_random.string('U', 20), dbms_random.string('U', 20), dbms_random.string('U', 20) from dual connect by level <= 100000;
commit;

create index i_ln_fn_0 on customer(last_name, first_name,0); — just to be sure that all rows are indexed

Now the explain plan:

explain plan for
select /*+ FIRST_ROWS(20) */ *
  from CUSTOMER
  where first_name like 'AB%'
    and first_name is not null
  order by last_name;

select * from table(dbms_xplan.display);

-------------------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |   197 | 12411 |   275   (2)| 00:00:04 |
|   1 |  SORT ORDER BY     |          |   197 | 12411 |   275   (2)| 00:00:04 |
|*  2 |   TABLE ACCESS FULL| CUSTOMER |   197 | 12411 |   274   (1)| 00:00:04 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("FIRST_NAME" LIKE 'AB%' AND "FIRST_NAME" IS NOT NULL)

But as I want only the first rows, I'd like to avoid the sort of the whole table. I'd like to have a plan like this:

SELECT STATEMENT
    TABLE ACCESS BY ROWID (customer)
        INDEX FULL SCAN (i_ln_fn_0)

How to persuade the db to avoid the sort?

The problem is even worse. Even when I use the last_name only, everywhere:

explain plan for
select /*+ FIRST_ROWS(20) */ last_name
  from CUSTOMER
  where last_name like 'AB%'
    and last_name is not null
  order by last_name;

select * from table(dbms_xplan.display);

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |    17 |   357 |     4  (25)| 00:00:01 |
|   1 |  SORT ORDER BY    |           |    17 |   357 |     4  (25)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN| I_LN_FN_0 |    17 |   357 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("LAST_NAME" LIKE 'AB%')
       filter("LAST_NAME" LIKE 'AB%')

Here the sort is really not necessary, but the db still uses it. Why?

Edit: Tested on both

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
"CORE 11.2.0.1.0 Production"
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

and

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production+
PL/SQL Release 11.2.0.2.0 - Production+
"CORE 11.2.0.2.0Production"+
TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production+
NLSRTL Version 11.2.0.2.0 - Production+

with the same plan.

Solution

The reason was in wrong value of NLS_SORT param. After changing it to BINARY, the plans began to look like I wanted.

From http://docs.oracle.com/cd/E24693_01/server.11203/e24448/initparams152.htm:

The value of NLS_SORT affects execution plans of queries. Because a standard index cannot be used as a source of values sorted in a linguistic order, an explicit sort operation must usually be performed instead of an index range scan. A functional index on the NLSSORT function may be defined to provide values sorted in a linguistic order and reintroduce the index range scan to the execution plan.

(I've got this answer from Paul Horth in forums.oracle com.)