想通过加HINT让其走全表扫描

一个SQL,通过SPM固定它的执行计划,可以通过DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE实现。也可以通地此功能在不修改原SQL的情况下对其加HINT来固定执行计划。
DB VERSION:Oracle 11.2.0.4
OS:CentOS 6.6
例如:
原SQL走索引:
SELECT * FROM SCOTT.TB_SPM WHERE OBJECT_ID=10;
想通过加HINT让其走全表扫描:
SELECT /*+FULL(TB_SPM)*/* FROM SCOTT.TB_SPM WHERE OBJECT_ID=10;
在V$SQL中查询出,原SQL的SQL_ID=064qcdmgt6thw,加HINT的SQL的SQL_ID=ahdtbgvsd3bht,PLAN_HASH_VALUE=970476072。
执行以下:
DECLARE
CNT NUMBER;
V_SQL CLOB;
BEGIN
--得到原语句SQL文本
SELECT SQL_FULLTEXT INTO V_SQL FROM V$SQL WHERE SQL_ID = ‘064qcdmgt6thw‘ AND ROWNUM=1;
--用加HINT的SQL的SQL_ID和PLAN_HASH_VALUE,来固定原语句的SQL
CNT := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(SQL_ID => ‘ahdtbgvsd3bht‘, PLAN_HASH_VALUE => 970476072, SQL_TEXT => V_SQL);
END;
这样就将加HINT的执行计划固定在原语句上。执行原语句,在V$SQL的PLAN_HASH_VALUE列和SQL_PLAN_BASELINE列来确认是否固定。
测试中发现,一些含有绑定变量的SQL,用常量的SQL的SQL_ID和PLAN_HASH_VALUE无法固定,此时可以尝试使用EXECUTE IMMEDIATE来生成含有绑定变量的SQL。
例如:
DECLARE
V_SQL VARCHAR2(2881064151);
BEGIN
V_SQL := ‘SELECT /*+FULL(TB_SPM)*/* FROM SCOTT.TB_SPM WHERE OBJECT_ID=:1‘;
EXECUTE IMMEDIATE V_SQL
USING 10;
END;

var v number;
exec :v :=10
SELECT /*+FULL(TB_SPM)*/* FROM SCOTT.TB_SPM WHERE OBJECT_ID=:V;
Oracle 通过SQL PROFILE为SQL语句加HINT可参考:http://www.linuxidc.com/Linux/2015-05/116974.htm

更多Oracle相关信息见Oracle 专题页面 http://www.codesec.net/topicnews.aspx?tid=12

时间: 2024-10-14 00:10:58

想通过加HINT让其走全表扫描的相关文章

oracle在组合索引上,只使用部分列进行查询(查询时必须包含前导列,否则会走全表扫描)

实验环境:Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production 1.创建表插入数据 SQL> create table txtx(id int,name char(2),tx char(3),id1 int,primary key(id,name,tx)); 表已创建. SQL> insert into txtx values(1,'tx','tx',1); 已创建 1 行. SQL> i

表访问方式---->全表扫描(Full Table Scans, FTS)

全表扫描(Full Table Scans, FTS) 全表扫描是指Oracle在访问目标表里的数据时,会从该表所占用的第一个区(EXTENT)的第一个块(BLOCK)开始扫描,一直扫描到该表的高水位线(HWM,High Water Mark),Oracle会对这期间读到的所有数据施加目标SQL的where条件中指定的过滤条件,最后只返回那些满足过滤条件的数据. 不是说全表扫描不好,事实上Oracle在做全表扫描操作时会使用多块读,ORACLE采用一次读入多个数据块 (database bloc

SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析

原文:SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析 在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index Seek))呢?是否所有情况都是如此?又该如何优化呢? 下面我们通过一些简单的例子来分析理解这些现象.下面的实验环境为SQL SERVER 2008,如果在不同版本有所区别,欢迎指正. 堆表单索引 首先我们构建我们测试需要实验环境,

Oracle 表的访问方式(1) ---全表扫描、通过ROWID访问表

1.Oracle访问表的方式 全表扫描.通过ROWID访问表.索引扫描 2.全表扫描(Full Table Scans, FTS) 为实现全表扫描,Oracle顺序地访问表中每条记录,并检查每一条记录是否满足WHERE语句的限制条件.ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描,而不是只读取一个数据块,这极大的减少了I/O总次数,提高了系统的吞吐量,所以利用多块读的方法可以十分高效地实现全表扫描.需要注意的是只有在全表扫描的情况下才能使用多块读操作.在这种

oracle全表扫描166G的表只花了6分钟

如何最大限制利用cpu?如何最快速的扫描完大表.如果大表有主键,count(*)就会走主键,oracle只需要扫描主键就能完成. 假设这个表没有主键,那么count(*)的时候只能走全表扫描,数据就非常慢.这里用full(a)强制走全表来模拟. --找100G以上的分区表 SQL> @getsegsize_big Enter value for tablespace_name: Enter value for owner: Enter value for how_big_m: 100000 OW

如何导致全表扫描原因

转一位大神的笔记. 导致表的执行计划做全表扫描的原因: u       SQL谓词列没有建相应的索引 u       谓词列建有相应的索引,但执行计划没有使用 Oracle不使用b*tree索引的情况大致如下 1:where条件中和null比较可能导致不使用索引 2:count,sum,ave,max,min等聚集操作时可能导致不使用索引 3:显示或者隐式的函数转换导致不使用索引 4:在cbo模式下,统计信息过于陈旧导致不使用索引 5:组合索引中没有使用前导列导致没有使用索引 6:访问的数据量超

为什么全表扫描成本(COST)公式里面要除以sreadtim

全表扫描的成本计算公式 如下: Cost = ( #SRds * sreadtim + #MRds * mreadtim + CPUCycles / cpuspeed ) / sreadtim 全表扫描的时候,单块读次数=0,#SRds表示单块读次数.全表扫描的成本里面,CPU消耗其实非常少,可以忽略不计,所以全表扫描的公式可以改写为: Cost = #MRds * mreadtim / sreadtim #MRds 表示多块读io次数 mreadtim 表示一次多块读耗费时间 sreadtim

【翻译自mos文章】使用索引快速全扫(index ffs) 来避免全表扫描

使用索引快速全扫(index ffs) 来避免全表扫描 参考原文: Index Fast Full Scan Usage To Avoid Full Table Scans (Doc ID 70135.1) 适用于: Oracle Database - Enterprise Edition - Version 7.3.0.0 to 11.2.0.3 [Release 7.3.0 to 11.2] Information in this document applies to any platfo

SQL 数据优化索引建suo避免全表扫描

首先什么是全表扫描和索引扫描?全表扫描所有数据过一遍才能显示数据结果,索引扫描就是索引,只需要扫描一部分数据就可以得到结果.如果数据没建立索引. 无索引的情况下搜索数据的速度和占用内存就会比用索引的检索慢和高.下面是一个例子 1:无索引的情况 Product表,里面没有任何索引,如下图: 从上图中,我悲剧的看到了,物理读是9次,也就说明走了9次硬盘,你也可以想到,走硬盘的目的是为了拿数据,逻辑读有1636次,要注意的是这里 的”次“是“页”的意思,也就是在内存中走了1636个数据页,我用dbcc