【每日一摩斯】-Index Skip Scan Feature (212391.1)

INDEX Skip Scan,也就是索引快速扫描,一般是指谓词中不带复合索引第一列,但扫描索引块要快于扫描表的数据块,此时CBO会选择INDEX SS的方式。

官方讲的,这个概念也好理解,如果将复合索引看做是一个分区表,其中分区主键(这里指的是复合索引的首列)定义了存储于此的分区数据。在每个键(首列)下的每行数据都将按照此键排序。因此在SS,首列可以被跳过,非首列可以作为逻辑子索引访问。因此一个“正常”的索引访问可以忽略首列。

复合索引被逻辑地切分成更小的子索引。逻辑子索引的个数取决于初始列的cardinality。因此尽管首列未出现在谓词中,也可能使用这个索引。、

另外,需要吧补充一点:当复合索引的第一个字段的值重复率非常低时,扫描索引的效率会比全表扫描更高,这是CBO才可能会选择使用INDEX Skip Scan的方式访问数据。

这里比较奇怪的是:

使用9i时,未使用INDEX Skip Scan:

SQL> create table at2(a varchar2(3),b varchar2(10),c varchar2(5));
Table created.

SQL> begin
  2    for i in 1..1000
  3    loop
  4    insert into at2 values('M', i, 'M');
  5    insert into at2 values('F', i, 'F');
  6    end loop;
  7    end;
  8  /
PL/SQL procedure successfully completed.

SQL> create index at2_i on at2(a,b,c);
Index created.

SQL> exec dbms_stats.gather_table_stats(OWNNAME => NULL, TABNAME => 'at2', CASCADE => TRUE, method_opt => 'FOR ALL COLUMNS SIZE 1');
PL/SQL procedure successfully completed.

SQL> set autotrace traceonly

SQL> select * from at2 where b='352';
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=2 Bytes=14)
   1    0   INDEX (FAST FULL SCAN) OF 'AT2_I' (NON-UNIQUE) (Cost=2 Car
          d=2 Bytes=14)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         10  consistent gets
          0  physical reads
          0  redo size
        447  bytes sent via SQL*Net to client
        587  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          2  rows processed

使用10g的,则使用了INDEX Skip Scan:

SQL> select * from full_tbl where object_name='TEST';
Execution Plan
----------------------------------------------------------
Plan hash value: 1293869270
------------------------------------------------------------------------------
| Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |          |     2 |    58 |    55   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| FULL_TBL |     2 |    58 |    55   (2)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_NAME"='TEST')

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        230  consistent gets
          0  physical reads
          0  redo size
        585  bytes sent via SQL*Net to client
        492  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

难道9i和10g在选择INDEX Skip Scan还有什么不同么?

时间: 2024-11-15 06:30:03

【每日一摩斯】-Index Skip Scan Feature (212391.1)的相关文章

关于Oracle 9i 跳跃式索引扫描(Index Skip Scan)的小测试

oracle|索引 在Oracle9i中我们知道能够使用跳跃式索引扫描(Index Skip Scan).然而,能利用跳跃式索引扫描的情况其实是有些限制的. 从Oracle的文档中我们可以找到这样的话: Index Skip ScansIndex skip scans improve index scans by nonprefix columns. Often, scanning index blocks is faster than scanning table data blocks.Sk

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列4

Jobs (CJQ0, Jn, SNPn) Job进程运行用户定义的以及系统定义的类似于batch的任务.检查Job进程占用大量CPU资源的方法,就像检查用户进程一样. 可以根据以下视图检查Job进程运行的状态:DBA_JOBS_* , DBA_SCHEDULER_*, DBA_AUTOTASK_*. 这些进程可能会消耗大量的CPU资源,因为他们无限循环地查询job队列. Note: 8531434.8 Bug 8531434 - Solaris: Excessive CPU by MMNL/C

【每日一摩斯】-LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4

LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4 Database (文档 ID 601316.1) LGWR的trace日志中记录: Warning: log write time 540ms, size 5444KB *** 2008-05-14 10:19:02.686 Warning: log write time 1470ms, size 55

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列1

这篇文章的目的是帮助寻找消耗CPU较高的Oracle进程. 高CPU应用不一定就是问题,或者说系统资源正在被充分利用.然而,如果CPU使用持续高,但系统负载低.系统性能差,那么就应该调查下CPU高使用率的原因.特别地,如果一个或多个进程持续是以其它进程为代价,持续消耗CPU资源,那么就应该调查这个CPU进程.除了为解决一些问题来收集的信息,几乎没有办法停止这些进程消耗CPU资源.另一方面,我们可以防止这种情况的发生.Oracle提供了两种方法限制个人用户使用的CPU资源: Profiles  N

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列2

当一个进程使用大量CPU资源时,需要查找哪些线索呢? 哪些进程在使用CPU? 后台进程 Oracle用户进程 和Oracle无关的操作系统进程 僵尸进程 后台进程: PMON: 当清理进程或在监听注册时,PMON进程占用CPU较高资源的主要原因可能是某个BUG. SMON: SMON进程负责空间整合与交易恢复,如果使用的是字典管理表空间,那么可能会产生巨大的消耗. 字典管理表空间中,如果一个包含很多extent区的大表被drop或truncate,SMON能让数据库hang住. 从9i开始,本地

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列3

LGWR & DBWR 这两个进程通常是和IO相关的,但是当存在操作系统问题,这两个进程可能"spin(等待)"直到IO操作完成.这种等待是一种CPU操作.异步IO操作的缓慢或失败也能证明它们是高CPU消耗的. 如果LGWR间歇地占用100%的CPU资源,那么异步输入输出AIO配置应该重新检查.作为一种临时性的方法,可以设置下面的参数防止LGWR出现等待的现象: _lgwr_async_io=false 这个参数可以关闭LGWR的异步输入输出. Note: 813473.1 L

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列5

Oracle(用户)进程 以下这些操作都是需要消耗大量CPU资源的:解析大型查询,存储过程编译或执行,空间管理和排序. 下面这几篇文章可以帮助采集关于使用高CPU资源的进程的更多信息: Note:352648.1 How to Diagnose High CPU Usage Problems to the Module Level  Note:452358.1 How to Collect Diagnostics for Database Hanging Issues 补充:Oracle用户进程

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列6

如果问题是一个正运行的缓慢的查询SQL,那么就应该对该查询进行调优,避免它耗费过高的CPU资源.如果它做了许多的hash连接和全表扫描,那么就应该添加索引以提高效率. 下面的文章可以帮助判断查询的问题: Note:215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL Note:199083.1 Master Note: SQL Query Performance Overview 实时SQL监控是11g的一个新特性,它能监控正运

【每日一摩斯】-RAC and Sequences (853652.1)

序列有四种组合: a. CACHE + NOORDER b. CACHE + ORDER c. NOCACHE + NOORDER d. NOCACHE + ORDER 即使在单例配置下,当有大量的sequence需要产生的时候,性能压力和存储sequence值的行锁定代价相关. NOCACHE与CACHE的性能       当使用cache时,dictionary cache(row cache)仅仅当出现新的水位线时才会更新一次.例如当cache是20,nextval第一次请求时,dicti