Indexes not work in query with paging with oracle 10g - sql

Question

I have a data recovery query in an Oracle 10g database with several indexes. When performing the pagination, oracle stops using the indexes.
For the query of the first page, only one subquery is generated:
explain plan for
select * from (
SELECT e.id, e.data, e.date, e.modifdate, e.origin, e.type, e.priority, e.view, e.state
FROM ev e
WHERE exists (
SELECT null
FROM dev d
WHERE (e.cId = d.deviceId OR e.cId = d.id) AND d.id = 152465)
ORDER BY e.date DESC )
where rownum <= 30
In the execution plan, I can see how the indexes are being used:
----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 30 | 68730 | 35616 (1)| 00:07:08 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | VIEW | | 30 | 68730 | 35616 (1)| 00:07:08 |
|* 3 | FILTER | | | | | |
| 4 | TABLE ACCESS BY INDEX ROWID | EV | 90578 | 138M| 31351 (1)| 00:06:17 |
| 5 | INDEX FULL SCAN | EV_DATE_DESC_IDX | 35291 | | 128 (6)| 00:00:02 |
|* 6 | TABLE ACCESS BY INDEX ROWID | DEV | 1 | 20 | 4 (0)| 00:00:01 |
| 7 | BITMAP CONVERSION TO ROWIDS | | | | | |
| 8 | BITMAP OR | | | | | |
| 9 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 10 | INDEX RANGE SCAN | DEV_DEVICE_ID_IDX | | | 1 (0)| 00:00:01 |
| 11 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 12 | INDEX RANGE SCAN | SYS_C00443004 | | | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------
30 rows on 0.759 seconds
For the following pages, two subqueries are generated and the indexes are no longer used:
explain plan for
select * from (
select row_.*, rownum rownum_ from (
SELECT e.id, e.data, e.date, e.modifdate, e.origin, e.type, e.priority, e.view, e.state
FROM ev e
WHERE exists (
SELECT null
FROM dev d
WHERE (e.cId = d.deviceId OR e.cId = d.id) AND d.id = 152465)
ORDER BY e.date DESC )
row_ where rownum <= 60)
where rownum_ > 30
Execution plan:
--------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 60 | 135K| | 63815 (2)| 00:12:46 |
|* 1 | VIEW | | 60 | 135K| | 63815 (2)| 00:12:46 |
|* 2 | COUNT STOPKEY | | | | | | |
| 3 | VIEW | | 77 | 172K| | 63815 (2)| 00:12:46 |
|* 4 | SORT ORDER BY STOPKEY | | 77 | 120K| 283M| 63815 (2)| 00:12:46 |
|* 5 | FILTER | | | | | | |
| 6 | TABLE ACCESS FULL | EV | 90578 | 138M| | 6798 (3)| 00:01:22 |
|* 7 | TABLE ACCESS BY INDEX ROWID | DEV | 1 | 20 | | 4 (0)| 00:00:01 |
| 8 | BITMAP CONVERSION TO ROWIDS | | | | | | |
| 9 | BITMAP OR | | | | | | |
| 10 | BITMAP CONVERSION FROM ROWIDS| | | | | | |
|* 11 | INDEX RANGE SCAN | DEV_DEVICE_ID_IDX | | | | 1 (0)| 00:00:01 |
| 12 | BITMAP CONVERSION FROM ROWIDS| | | | | | |
|* 13 | INDEX RANGE SCAN | SYS_C00443004 | | | | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------------------------
30 rows on 3.386 seconds
For paging I write the query by hand but I set the page number with the entity manager:
Query querySelect = entityManager.createNativeQuery(query, Event.class);
querySelect.setMaxResults(pageSize);
querySelect.setFirstResult(pageSize * page);
Why does not Oracle use the indexes in the second query? How can I use the indexes with the pagination in oracle?

Answer 1

Assuming these are normal heap tables, I am just speculating here.
The first query sorts the records using ev.date column and fetches the first 30 records. This favours Index Full Scan (IFS). IFS scans the ROWIDs in the same order of entries in the leaf blocks (Left to right - full scan). So the scanned records are already ordered. As you were fetching the first 30 rows out of these, the optimizer seems to have favoured IFS. Please note that there is a table access after IFS. This is already an overhead.
The second query fetches 30 rows in between the scanned records unlike the first 30 records in the first query. This creates a new starting point and ending point in between the scanned result set. Inspite of scanning in order, the query will have to discard the initially scanned rows based on the new starting point. Hence the records scanned before the starting point are redundant as they will anyway be filtered out. So it seems like IFS is considered as overhead here. This might have forced the query to favour Full Table Scan (FTS) against IFS. Also the scanned records need to be sorted to obtain the required order using 283M of temporary tablespace.
You may want to check the following details to understand the execution plan better.
The number of rows in EV
SELECT num_rows, last_analyzed, blocks, sample_size
FROM user_tables
WHERE table_name = 'EV';
The number of rows in DEV
SELECT num_rows, last_analyzed, blocks, sample_size
FROM user_tables
WHERE table_name = 'DEV';
The number of rows in DEV with ID = 152465
The number of rows in EV with ID or DEVICEID = 152465
The list of indexes in each table with columns in order, uniqueness
SELECT table_name, index_name, uniqueness, clustering_factor, last_analyzed, sample_size
FROM user_indexes
WHERE table_name in ('EV','DEV') AND status = 'VALID'
ORDER BY 1,2;
SELECT table_name,index_name,column_name
FROM user_ind_columns
WHERE table_name in ('EV','DEV')
ORDER BY 1,2,column_position;
Check if histogram statistics are available on any columns.
SELECT table_name, column_name, histogram
FROM user_tab_col_statistics
WHERE table_name in ('EV','DEV')
ORDER BY 1,2;
Also the following parameters might help.
optimizer_index_caching
optimizer_index_cost_Adj
db_file_multiblock_read_count
pga_aggregate_target
optimizer_mode
cursor_sharing