prevent a full table scan

how can i prevent a full table scan with this query:

1 select /*+ index (wip_event_log_idx1) */ min(track_id) as BeginId, max(track_id) as EndId from wip_event_log
2* where build_id = '4321'
l06db > /

BEGINID ENDID
---------------- ----------------
LDAA140001 LDAA140005

Elapsed: 00:00:55.67

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Cost=1862 Optimizer=RULE
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'WIP_EVENT_LOG'


Statistics
----------------------------------------------------------
1036 recursive calls
0 db block gets
21272 consistent gets
18115 physical reads
6992 redo size
224 bytes sent via SQL*Net to client
335 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
28 sorts (memory)
0 sorts (disk)
1 rows processed

build_id has to be an indexed column, which it must be if you hinted the select statement that way. you're sure it is indexed (if it's 8.x Oracle it has to be the first column in the index ).

But the optimizer may use a full table scan if the entry occurs lots of times in the table. Remember, it is just a hint.

Try ANALYZE TABLE COMPUTE STATISTICS wip_event_log or ask your DBA to do it

Then change your hint to /*+ CHOOSE */
and see if things get better.

But remember, once you run a query, the results for the query are cached so run #2 can be a lot faster than run #1.

If it is NOT a production system get the DBA to run ALTER SYSTEM FLUSH SHARED POOL - this will wreck perfomance for anyone else using the same instance. But it does clear the cache, so you can compare test runs of your queries.

How big is the table (in terms of rows)?
For smaller tables (< 5000 rows) it might actually be faster to do a full table scan then bothering with the index.

Secondly (not sure about that), an index on track_id might as well help.

Why are you using the old RULE based optimizer? Read this (.doc) about the new COST based optimizer and it's tuning (i.e. why it chooses full table scans over indexes).
Also show us the table's DDL and index definition, plus the number of rows.
Follow jim mcnamara's advice, update statistics, and try different hints, I've had good results with FIRST_ROWS.
Here you can find some more informations about hints, but there is a ton of articles around.