[20130910]12C执行计划的TABLE ACCESS BY INDEX ROWID BATCHED(补充).txt

简介: [20130910]12C执行计划的TABLE ACCESS BY INDEX ROWID BATCHED(补充).txt链接http://space.itpub.net/267265/viewspace-772371写了12c下在范围扫描时可能出现的TABLE ACCESS BY INDEX ROWID BATCHED,这是一种新的执行方式,能够提高执行效率,特别在数据聚集很好的情况下。
[20130910]12C执行计划的TABLE ACCESS BY INDEX ROWID BATCHED(补充).txt

链接
http://space.itpub.net/267265/viewspace-772371

写了12c下在范围扫描时可能出现的TABLE ACCESS BY INDEX ROWID BATCHED,这是一种新的执行方式,能够
提高执行效率,特别在数据聚集很好的情况下。

既然是12c的一个特性应该有一个参数关闭这个特性。重复前面的例子:

1.建立测试环境:
SCOTT@test01p> @ver

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0

SCOTT@test01p> create table t (id number,name varchar2(20));
Table created.

--打开3个session,分别执行如下:
-session 1:
insert into t values (1,lpad('a',20,'a'));
commit ;

-session 2:
insert into t  values (2,lpad('b',20,'b'));
commit ;

-session 3:
insert into t  values (3,lpad('c',20,'c'));
commit ;

insert into t  select rownum+3 id ,lpad('x',20,'x') name from dual connect by level commit ;

--这样操作可以导致id=1在一个数据块id=2,3在另外的数据块。
SCOTT@test01p> select rowid ,t.* from t where id between 1 and 3;
ROWID                      ID NAME
------------------ ---------- --------------------
AAAWxnAAJAAAAC1AAA          1 aaaaaaaaaaaaaaaaaaaa
AAAWxnAAJAAAAC3AAA          2 bbbbbbbbbbbbbbbbbbbb
AAAWxnAAJAAAAC3AAB          3 cccccccccccccccccccc

COTT@test01p> @lookup_rowid AAAWxnAAJAAAAC1AAA
   OBJECT       FILE      BLOCK        ROW DBA
--------- ---------- ---------- ---------- --------------------
    93287          9        181          0 9,181

COTT@test01p> @lookup_rowid AAAWxnAAJAAAAC3AAA
   OBJECT       FILE      BLOCK        ROW DBA
--------- ---------- ---------- ---------- --------------------
    93287          9        183          0 9,183

SCOTT@test01p> create unique index i_t_id on t(id);
Index created.

--分析表
SCOTT@test01p> execute dbms_stats.gather_table_stats(user,'t');
PL/SQL procedure successfully completed.

2.测试
SCOTT@test01p> @dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  3uy89r3c5z5yy, child number 0
-------------------------------------
select * from t where id between 1 and 100

Plan hash value: 3446268138

----------------------------------------------------------------------------
| Id  | Operation                           | Name   | E-Rows | Cost (%CPU)|
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |        |        |     3 (100)|
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| T      |    100 |     3   (0)|
|*  2 |   INDEX RANGE SCAN                  | I_T_ID |    100 |     1   (0)|
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID">=1 AND "ID"
--即使扫描全部数据,选择的也是使用索引。


SYS@test01p> @hide _optimizer_batch_table_access_by_rowid
old  10:  and lower(a.ksppinm) like lower('%&1%')
new  10:  and lower(a.ksppinm) like lower('%_optimizer_batch_table_access_by_rowid%')
NAME                                     DESCRIPTION                                DEFAULT_VALUE  SESSION_VALUE  SYSTEM_VALUE
---------------------------------------- ------------------------------------------ -------------- -------------- ------------
_optimizer_batch_table_access_by_rowid   enable table access by ROWID IO batching   TRUE           TRUE           TRUE

SCOTT@test01p> alter session set "_optimizer_batch_table_access_by_rowid"=false;
Session altered.

SCOTT@test01p> @dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  3uy89r3c5z5yy, child number 1
-------------------------------------
select * from t where id between 1 and 100

Plan hash value: 4153437776

--------------------------------------------------------------------
| Id  | Operation                   | Name   | E-Rows | Cost (%CPU)|
--------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |        |     3 (100)|
|   1 |  TABLE ACCESS BY INDEX ROWID| T      |    100 |     3   (0)|
|*  2 |   INDEX RANGE SCAN          | I_T_ID |    100 |     1   (0)|
--------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("ID">=1 AND "ID"
--回到原来的模式,奇怪的是为什么选择的还是INDEX RANGE SCAN+ TABLE ACCESS BY INDEX ROWID扫描呢?
--正常应该选择全表扫描。

SCOTT@test01p> set autot traceonly
SCOTT@test01p> select * from t where id between 1 and 100;
100 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 4153437776
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |   100 |  2400 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T      |   100 |  2400 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | I_T_ID |   100 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("ID">=1 AND "ID"
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
       3548  bytes sent via SQL*Net to client
        544  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        100  rows processed

--奇怪逻辑读还是4.难道oracle改进了什么?能力如此,oracle许多东西不了解,那位知道给出答案!





目录
相关文章
|
安全 网络协议 物联网
不看后悔系列之一篇搞懂LinuxCentOS搭建MQTT服务器及客户端操作使用
linux CentOS上搭建MQTT服务器并不难,主要就是用到了mosquitto这款消息代理服务软件。其采用发布/订阅模式传输机制,轻量、简单、开放并易于实现,被广泛应用于物联网之中。
3217 0
|
SQL Oracle 关系型数据库
Oracle-index索引解读
Oracle-index索引解读
507 0
|
2月前
|
人工智能 自然语言处理 安全
2025年企业如何选择智能客服系统:企业级智能客服系统推荐
在数字化转型加速的今天,智能客服已成为企业提升服务效率与客户体验的核心工具。本文系统梳理主流智能客服解决方案,重点解析阿里云旗下瓴羊Quick Service如何依托通义大模型,实现全渠道、全链路、全场景的智能化服务升级,助力企业从“拥有”到“用好”,真正释放智能客服的增长潜力。
|
6月前
|
人工智能 监控 数据可视化
2025年PMO必备的项目管理工具类软件功能介绍与推荐
在数字化转型背景下,PMO软件已从基础任务管理工具演变为助力企业实现战略目标的核心平台。本文精选15款2025年必备的PMO项目管理工具,涵盖Microsoft Project、Monday.com、板栗看板、Asana等,全面解析其核心功能与适用场景。内容还涵盖PMO工具发展趋势、选型关键因素及未来发展方向,助您在复杂项目环境中做出高效决策,提升组织执行力与战略落地能力。
378 1
|
Java jenkins 持续交付
Centos7下docker的jenkins下载并配置jdk与maven
通过上述步骤,您将成功在CentOS 7上的Docker容器中部署了Jenkins,并配置好了JDK与Maven,为持续集成和自动化构建打下了坚实基础。
999 1
|
JSON 安全 API
API开发实战:从设计到部署的全流程指南
在数字化转型中,API成为系统集成的关键。本文引导读者逐步实践API开发: 1. 设计阶段确定需求,选择RESTful风格,例如天气查询API(/api/weather/{city}),返回JSON数据。 2. 使用Python和Flask实现API,处理GET请求,返回城市天气信息。 3. 进行测试,如用curl请求`http://localhost:5000/api/weather/Beijing`。 4. 文档化API,借助Flask-RESTPlus自动生成文档。 5. 部署到Heroku,创建`Procfile`,通过`heroku`命令推送代码。 【6月更文挑战第28天】
2451 0
|
存储 Oracle 关系型数据库
Oracle索引知识看这一篇就足够
Oracle索引知识看这一篇就足够
|
Web App开发 前端开发 安全
Chrome浏览器进程:了解多进程架构优劣的探索
Chrome浏览器进程:了解多进程架构优劣的探索
|
运维 监控 数据安全/隐私保护
【运维知识进阶篇】zabbix5.0稳定版详解5(SNMP网络管理协议监控)
【运维知识进阶篇】zabbix5.0稳定版详解5(SNMP网络管理协议监控)
641 0
|
弹性计算 分布式计算 安全
服务器基础知识:包含基本概念,作用,服务器选择,服务器管理等(学习来自米拓建站)
服务器基础知识:包含基本概念,作用,服务器选择,服务器管理等(学习来自米拓建站)
1743 0