Use index_desc

常見的例子，表中記錄按照creation_date作purge，且該欄位上有個索引。

如果不加index_desc hint，purge job執行時間長了可能會越來越慢。如下consistent read明顯要比current read多很多。是因為Index range scan從index tree的最左面開始掃描，掃描了很多空塊。

SQL> DELETE FROM  vltb_data_0   where creation_date < (SYSDATE - 3)  and rownum < 1000;
999 rows deleted.

———————————————————-
| Id  | Operation          | Name                        |
———————————————————-
|   0 | DELETE STATEMENT   |                             |
|   1 |  DELETE            | RULE_OBJECT_ATTR_DATA_0     |
|*  2 |   COUNT STOPKEY    |                             |
|*  3 |    INDEX RANGE SCAN| RULE_OBJECT_ATTR_DATA_0_IX3 |
———————————————————-
Predicate Information (identified by operation id):
—————————————————
2 - filter(ROWNUM<1000)
3 - access(”CREATION_DATE”

Statistics
———————————————————-
1  recursive calls
21167  db block gets
427848  consistent gets
0  physical reads
1341824  redo size
1  sorts (memory)
0  sorts (disk)
999  rows processed

通過新增index_desc, Index range descending scan從index tree的中間或者右邊進入掃描，更快定位到存在紀錄的block.

SQL> DELETE /*+ index_desc(rule_object_attr_data_0) */ FROM  vltb_data_0   where creation_date < (SYSDATE - 3)  and rownum < 1000;
999 rows deleted.

Statistics
———————————————————-
1  recursive calls
21177  db block gets
59  consistent gets
288  physical reads
1368592  redo size
814  bytes sent via SQL*Net to client
833  bytes received via SQL*Net from client
3  SQL*Net roundtrips to/from client
1  sorts (memory)
0  sorts (disk)
999  rows processed

從而避免了無用功。這樣的例子時常在工作中遇到。