oracle执行计划

【引言】 在Oracle中直方图是一种对数据分布质量情况进行描述的工具。它会按照某一列不同值出现数量多少，以及出现的频率高低来绘制数据的分布情况，以便能够指导优化器根据数据的分布做出正确的选择。在某些情况下，表的列中的数值分布将会影响优化器使用索引还是执行全表扫描的决策。 构造直方图最主要的原因：是帮助优化器在表中数据严重偏斜时做出更好的规划 直方图是一种统计学上的工具，并非Oracle专有，通常情况下它会表现为一种几何图形表，这个图形表是根据从实际环境中所收集来的被管理对象某个方面的质量分布情况的数据所绘制成的，通常会画成以数量为底边，以频度为高度的一系列连接起来的矩形图，因此直方图在统计学上也称为质量分布图。 当where 子句的值具有不成比例数量的数值时，将出现这种情况，使得全表扫描比索引访问的成本更低。这种情况下如果where 子句的过滤谓词列之上有一个合理的正确的直方图，将会对优化器做出正确的选择发挥巨大的作用，使得SQL语句执行成本最低从而提升性能。 在分析表或索引时，直方图用于记录数据的分布。通过获得该信息，基于成本的优化器就可以决定使用将返回少量行的索引，而避免使用基于限制条件返回许多行的索引。直方图的使用不受索引的限制，可以在表的任何列上构建直方图。 构造直方图最主要的原因就是帮助优化器在表中数据严重偏斜时做出更好的规划 。如果一到两个值构成了表中的大部分数据

1. 问题 　　 系统有个模块，需要查询Oracle数据库中的数据。目前是通过建立链接服务器实现的。 　　 SQLServer访问Oracle实现 可参考这篇文章 http://www.cnblogs.com/gnielee/archive/2010/09/07/access-oracle-from-sqlserver.html 　　 目前的查询语句就是一个简单的带where条件的查询语句，类似如下： 　　 SELECT * FROM LINKED_NAME..ACCOUNT_NAME.TABLE_NAME WHERE COLUMN1=SID; 　　 存在的问题是查询速度非常慢，前台报超时。所以准备提升下查询的性能 2. 分析 　　首先，确定远程Oracle的表在筛选字段上是否存在索引。经确认，存在索引。 　　然后，在SSMS客户端中查看了执行语句的执行计划，如下： 　　 　　从执行计划可以看出，过程没有和自己设想的那样，原以为SQLServer会将整个查询提交到Oracle服务器执行。而实际在远程查询时，并没有加入where条件，而是将结果返回到本地后，在本地执行筛选（有一个筛选器） 　　这样速度肯定会非常慢，因为查询没有使用到索引查找，需要将远程数据全部传输到本地后才执行筛选，相当于全表扫描，还多了网络传输的时间。 3. 解决 　

事件 说明 例子 Event 10013 - Monitor Transaction Recovery 在Startup时跟踪事务恢复 ALTER SESSION SET EVENTS '10013 trace name context forever, level 1'; Event 10015 - Dump Undo Segment Headers- 在事务恢复后做Dump回退段头信息 ALTER SESSION SET EVENTS '10015 trace name context forever, level 1'; Event 10032 - Dump Sort Statistics Dump排序的统计信息 ALTER SESSION SET EVENTS '10032 trace name context forever, level 10'; Event 10033 - Dump Sort Intermediate Run Statistics 排序过程中，内存排序区和临时表空间的交互情况 ALTER SESSION SET EVENTS '10033 trace name context forever, level 10'; Event 10045 - Trace Free List Management Operations FREELIST的管理操作

前言： 该文来自于Oracle RWP团队的领袖Andrew Holdsworth的一个精彩分享，笔者觉得很精彩，便将其梳理成文，并加上了自己的理解，希望能帮助大家更好的理解TX-index contention等待事件。 enq:TX-index contention: enq:TX-index contention是一个非常常见的等待事件，其专指由于索引分裂产生的竞争等待。最常见的索引竞争一般发生在主键索引上，主键值从序列（sequence)中获取，每个事务都会生成一条新的记录，每条记录都要获得一个新的序列号，因为从sequence中取出的值是单向递增的，当索引中插入数据，并且维护索引结构的时候，不得不一直走向索引的最右侧的分支，对于每一个操作，都会想要维护索引中最右边的叶节点，那么所有的操作都会关注同一个内存块，希望能够维护这块内存，这就是一种典型的竞争形式。但在同一时间，只有一个人能够修改这块内存，因此当有一个人在修改的时候，其他所有想修改的人只能处于等待状态。 在一个并发量很大的OLTP系统中，开发者希望记录每个用户的登录和操作情况，因此需要创建基于主键的索引。接下来我们将通过实验说明如何减少这类索引竞争。 首先来看在没有索引的情况下系统的运行状况，系统运行平稳并且性能良好。如下图所示： 接下来我们尝试最简单的B树索引，索引的的值是通过sequence生成的

1.使用语句监控应用帐号的normal索引 select owner, 'alter index ' || owner || '.'||'"'||index_name||'"'||' monitoring usage;' from dba_indexes where index_type = 'NORMAL' and uniqueness = 'NONUNIQUE' and owner in ( select username from dba_users t where t.account_status='OPEN' and t.default_tablespace not in ('SYSTEM','USERS','SYSAUX')); 2.查询索引是否被使用 select us.username owner, io.name index_name, t.name table_name, decode(bitand(i.flags, 65536), 0, 'NO', 'YES') monitoring, decode(bitand(ou.flags, 1), 0, 'NO', 'YES') used, ou.start_monitoring, ou.end_monitoring from sys.obj$ io, sys.obj$ t, sys.ind$ i, sys

语法： explain plan for + 目标SQL select * from table(dbms_xplan.display); eg： SQL> explain plan for select empno,ename,dname from scott.emp,scott.dept where emp.deptno=dept.deptno; Explained. SQL> set linesize 800 SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- Plan hash value: 844388907 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 14 | 364 | 6 (17)| 00:00

基于oracle的sql优化 基于oracle的sql优化 一．编写初衷描述 在应有系统开发初期，由于数据库数据较少，对于sql语句各种写法的编写体现不出sql的性能优劣，随着数据的不断增加，出现海量数据，劣质sql与优质sql在执行效率甚至存在百倍差距，可见sql优化的重要性 二．Sql语句性能优化 2.1 认识Oracle的执行过程 2.2 Oracle优化法则—漏斗法则 2.3 Oracle 执行计划 2.3.1 什么是Oracle执行计划 执行计划是一条查询语句在Oracle中执行过程或者访问路径的描述. 2.3.2 查看Oracle执行计划 1.执行计划常用的列字段解释 基数：返回的结果集行数 字节：执行该步骤后返回的字节数 耗费(cust),CPU耗费：Oracle估计的该步骤的执行成本，用于说明SQL执行的代价，理论上越小越好. 2.3.3 看懂Oracle执行计划 2.3.3.1执行顺序 根据缩进来判断，缩进最多的最先执行(缩进相同时，最上面的最先执行) 2.4 表的访问方式 TABLE ACCESS FULL ( 全表扫描 ) TABLE ACCESS BY ROWID ( 通过rowid的表存取 ) TABLE ACCESS BY INDEX SCAN ( 索引扫描 ) 2.4.1 ABLE ACCESS FULL(全表扫描) Oracle会读取表中的所有行

说明：本内容是工作用到的知识点整理，来自工作中和网络。 代码于Oracle9上测试。 Trigger 失效 经常发现系统里的 Trigger 失效（ all_objects.status= 'INVALID' 并且 all_triggers.status= 'ENABLED' ） 失效原因 涉及的一些表或者其它对象被删除或者其它操作（ DDL ），这时你需要重新编译或重建。所以，严密周到还是配有相应文档。举一个例子， Test1 表（ NUM , CREATEDATE), 有一个 insert 触发器 , 当 alter table Test1 add(a); 那触发器变为失效，要重新创建。 同样，删除字段也会失效。 同样，修改字段的类型（ Type ）也会失效。 查看 Trigger 状态 -- 有是否有效的状态 (INVALID/VALID) select * from all_objects o where o.object_type='TRIGGER' AND o.object_name in ('WRITE_BACK_RCL_DETAIL_F137','WRITE_BACK_RCL_DETAIL_F138') -- 有是否启用的状态 (DISABLED/ENABLED) select * from all_triggers t where t.trigger_name

（转） Oracle大数据常见优化查询 (1-30)： 1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or num=20 可以这样查询： select id from t where num=10 union all select id from t where num=20 5.in 和 not in 也要慎用，否则会导致全表扫描，如： select id from t where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了： select id from t where num between 1

注：本文参考了《 整理oracle 树形查询 》 sql树形递归查询是数据库查询的一种特殊情形，也是组织结构、行政区划查询的一种最常用的的情形之一。下面对该种查询进行一些总结： create table JD2_SUPERVISE_MATTER ( id NUMBER(10) not null, pid NUMBER(10), data_model_id NUMBER(10), code VARCHAR2(30), name VARCHAR2(30), descript VARCHAR2(50), flag_notic_budget_unit CHAR(1), flag_notic_busi_dept CHAR(1), busi_dept_name VARCHAR2(30), orderid NUMBER(10) ) alter table JD2_SUPERVISE_MATTER add constraint PK_JD2_SUPERVISE_MATTER primary key (ID) insert into JD2_SUPERVISE_MATTER (ID, PID, DATA_MODEL_ID, CODE, NAME, DESCRIPT, FLAG_NOTIC_BUDGET_UNIT, FLAG_NOTIC_BUSI_DEPT, BUSI_DEPT_NAME,