Session altered.
SQL> exec dbms_stats.gather_table_stats(ownname=>‘SYS‘,tabname=>‘FAKEIND_TEST‘,degree=>4,estimate_percent=>100,cascade=>true);
PL/SQL procedure successfully completed.
--再次确认表的分析情况
SQL> select table_name,last_analyzed from dba_tables where table_name=‘FAKEIND_TEST‘;
TABLE_NAME LAST_ANALYZED
------------------------------ ------------------
FAKEIND_TEST 17-SEP-14
--再次查询测试表
SQL> set autot trace
SQL> select object_id,object_name from fakeind_test where object_id in(select distinct object_id from fakeind_test where object_id>44500 and object_id<45000);
3992 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2531911586
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3904 | 308K| 12 (17)| 00:00:01 |
| 1 | VIEW | VM_NWVW_2 | 3904 | 308K| 12 (17)| 00:00:01 |
| 2 | HASH UNIQUE | | 3904 | 179K| 12 (17)| 00:00:01 |
|* 3 | HASH JOIN | | 3904 | 179K| 11 (10)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | IND_FAKE_ID | 3819 | 19095 | 2 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| FAKEIND_TEST | 3819 | 156K| 8 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | IND_FAKE_ID | 3819 | | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("OBJECT_ID"="OBJECT_ID")
4 - access("OBJECT_ID">44500 AND "OBJECT_ID"<45000)
6 - access("OBJECT_ID">44500 AND "OBJECT_ID"<45000)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
17418 consistent gets
0 physical reads
0 redo size
144488 bytes sent via SQL*Net to client
3445 bytes received via SQL*Net from client
268 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
3992 rows processed
SQL> set autot off
SQL> set autot trace
SQL> select object_id,object_name from fakeind_test where object_id in(select distinct object_id from fakeind_test where object_id>45500 and object_id<50000);
35992 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2531911586
-------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 41816 | 3307K| | 548 (1)| 00:00:07 |
| 1 | VIEW | VM_NWVW_2 | 41816 | 3307K| | 548 (1)| 00:00:07 |
| 2 | HASH UNIQUE | | 41816 | 1919K| 2472K| 548 (1)| 00:00:07 |
|* 3 | HASH JOIN | | 41816 | 1919K| | 53 (2)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | IND_FAKE_ID | 34375 | 167K| | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| FAKEIND_TEST | 34375 | 1409K| | 49 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | IND_FAKE_ID | 34375 | | | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("OBJECT_ID"="OBJECT_ID")
4 - access("OBJECT_ID">45500 AND "OBJECT_ID"<50000)
6 - access("OBJECT_ID">45500 AND "OBJECT_ID"<50000)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
11017 consistent gets
82 physical reads
0 redo size
1293055 bytes sent via SQL*Net to client
26908 bytes received via SQL*Net from client
2401 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
35992 rows processed
虽然创建了真实索引,但数据库却仍旧在用虚拟索引,此时COST和TIME反而还上去了一点,那么需要先禁用虚拟索引
SQL> alter session set "_use_segment_indexes"=false;
--禁用虚拟索引后继续查看刚才的SQL
SQL> select object_id,object_name from fakeind_test where object_id in(select distinct object_id from fakeind_test where object_id>45500 and object_id<50000);
35992 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 750753197
-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 34375 | 1443K| 2414 (1)| 00:00:29 |
|* 1 | HASH JOIN RIGHT SEMI| | 34375 | 1443K| 2414 (1)| 00:00:29 |
| 2 | VIEW | VW_NSO_1 | 34375 | 436K| 79 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | IND_REAL_ID | 34375 | 167K| 79 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL | FAKEIND_TEST | 604K| 17M| 2331 (1)| 00:00:28 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_ID"="OBJECT_ID")
3 - access("OBJECT_ID">45500 AND "OBJECT_ID"<50000)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11017 consistent gets
0 physical reads
0 redo size
1293055 bytes sent via SQL*Net to client
26908 bytes received via SQL*Net from client
2401 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
35992 rows processed
这个测试其实并没有做的很完善,SQL语句选取得不好,正常情况下,原有语句所涉及的表至少且肯定会有一个主键索引,没有索引的表在OLTP生产库中是不太现实的。本文主要是起到一个抛砖引玉的作用,当我们面对一个数据库优化的场景,需要测试创建某个特定条件的索引是否会给系统带来性能提升,就可以借助虚拟索引来测试,因为在生产库中通常不允许随意创建索引,而维护索引对数据库而言也是一笔不小的开销,况且如果索引创建不当,可能使数据库性能更糟糕。