❶ 2020-01-20 oracle中sql如何执行，什么是硬解析和软解析
1.语法检查：检查 SQL 拼写是否正确，如果不正确，Oracle 会报语法错误。
2.语义检查：检查 SQL 中的访问对象是否存在。比如我们在写 SELECT 语句的时候，列名写错了，系统就会提示错误。语法检查和语义侍槐察检查的作用是保证 SQL 语句没有错误。
3.权限检查：看用户是否具备访问该数据的权限。
4.共享池检查：共享池（Shared Pool）是一块内存池，最主要的作用是缓存 SQL 语句和该语句的执行计划。Oracle 通过检查共享池是否存在 SQL 语句的执行计划，来判断进行软解析，还是硬解析。那软解析和硬解析又该怎么理解呢？在共享池中，Oracle 首先对 SQL 语句进行 Hash 运算，然后根据 Hash 值在库缓存（Library Cache）中查找，如果存在 SQL 语句的执行计划，就直接拿来执行，直接进入“执行器”的环节，这就是软解析。如果没有找到 SQL 语句和执行计划，Oracle 就需要创建解析树进行解析明羡，生成执行计划，进入“优化器”这个步骤，这就是硬解析。
5.优化器：优化器中就是要进行硬解析，也就老茄是决定怎么做，比如创建解析树，生成执行计划。
6.执行器：当有了解析树和执行计划之后，就知道了 SQL 该怎么被执行，这样就可以在执行器中执行语句了。
共享池是 Oracle 中的术语，包括了库缓存，数据字典缓冲区等。我们上面已经讲到了库缓存区，它主要缓存 SQL 语句和执行计划。而数据字典缓冲区存储的是 Oracle 中的对象定义，比如表、视图、索引等对象。当对 SQL 语句进行解析的时候，如果需要相关的数据，会从数据字典缓冲区中提取。
如何避免硬解析，尽量使用软解析呢？在 Oracle 中，绑定变量是它的一大特色。绑定变量就是在 SQL 语句中使用变量，通过不同的变量取值来改变 SQL 的执行结果。
❷ 影响数据库性能的主要因素有哪些
1、1、调整数据结构的设计。这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。 x0dx0ax0dx0a2、2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。 x0dx0ax0dx0a3、3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。 x0dx0ax0dx0a4、4、调整服务器内存分销和段配。内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA区）的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。 x0dx0ax0dx0a5、5、调整硬盘I/O，这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。 x0dx0ax0dx0a6、6、调整操作系统参数，例如：运行在UNIX操作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。 x0dx0ax0dx0a实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。 x0dx0ax0dx0aORACLE数据库性能优化工具 x0dx0ax0dx0a常用的数据库性能优化工具有： x0dx0ax0dx0a1、1、ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。 x0dx0ax0dx0a2、2、操作系统工具，例如UNIX操作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现棚行在什么地方有时候很有用。 x0dx0ax0dx0a3、3、SQL语言跟踪工具（SQL TRACE FACILITY），SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文亏誉件，管理员可以使用TKPROF工具查看这些文件。 x0dx0ax0dx0a4、4、ORACLE Enterprise Manager（OEM），这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。 x0dx0ax0dx0a5、5、EXPLAIN PLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。 x0dx0ax0dx0aORACLE数据库的系统性能评估 x0dx0ax0dx0a信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。 x0dx0ax0dx0a1、1、在线事务处理信息系统（OLTP），这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数： x0dx0ax0dx0al l 数据库回滚段是否足够？ x0dx0ax0dx0al l 是否需要建立ORACLE数据库索引、聚集、散列？ x0dx0ax0dx0al l 系统全局区（SGA）大小是否足够？ x0dx0ax0dx0al l SQL语句是否高效？ x0dx0ax0dx0a2、2、数据仓库系统（Data Warehousing），这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数： x0dx0ax0dx0al l 是否采用B*-索引或者bitmap索引？ x0dx0ax0dx0al l 是否采用并行SQL查询以提高查询效率？ x0dx0ax0dx0al l 是否采用PL/SQL函数编写存储过程？ x0dx0ax0dx0al l 有必要的话，需要建立并行数据库提高数据库的查询效率 x0dx0ax0dx0aSQL语句的调整原则 x0dx0ax0dx0aSQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAIN PLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则： x0dx0ax0dx0a1、1、尽量使用索引。试比较下面两条SQL语句： x0dx0ax0dx0a语句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN x0dx0ax0dx0a(SELECT deptno FROM emp); x0dx0ax0dx0a语句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS x0dx0ax0dx0a(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno); x0dx0ax0dx0a这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。 x0dx0ax0dx0a2、2、选择联合查询的联合次序。考虑下面的例子： x0dx0ax0dx0aSELECT stuff FROM taba a, tabb b, tabc c x0dx0ax0dx0aWHERE a.acol between :alow and :ahigh x0dx0ax0dx0aAND b.bcol between :blow and :bhigh x0dx0ax0dx0aAND c.ccol between :clow and :chigh x0dx0ax0dx0aAND a.key1 = b.key1 x0dx0ax0dx0aAMD a.key2 = c.key2; x0dx0ax0dx0a这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。 x0dx0ax0dx0a3、3、在子查询中慎重使用IN或者NOT IN语句，使用where (NOT) exists的效果要好的多。 x0dx0ax0dx0a4、4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。 x0dx0ax0dx0a5、5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。 x0dx0ax0dx0a6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。 x0dx0ax0dx0aCPU参数的调整 x0dx0ax0dx0aCPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90％以上。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。 x0dx0ax0dx0a使用操作相同命令可以看到CPU的使用情况，一般UNIX操作系统的服务器，可以使用sar _u命令查看CPU的使用率，NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。 x0dx0ax0dx0a数据库管理员可以通过查看v$sysstat数据字典中“CPU used by this session”统计项得知ORACLE数据库使用的CPU时间，查看“OS User level CPU time”统计项得知操作系统用户态下的CPU时间，查看“OS System call CPU time”统计项得知操作系统系统态下的CPU时间，操作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占操作系统总的CPU时间90％以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。 x0dx0ax0dx0a数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。 x0dx0ax0dx0a出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。 x0dx0ax0dx0a1、数据库管理员可以执行下述语句来查看SQL语句的解析情况： x0dx0ax0dx0aSELECT * FROM V$SYSSTAT x0dx0ax0dx0aWHERE NAME IN x0dx0ax0dx0a('parse time cpu', 'parse time elapsed', 'parse count (hard)'); x0dx0ax0dx0a这里parse time cpu是系统服务时间，parse time elapsed是响应时间，用户等待时间 x0dx0ax0dx0awaite time = parse time elapsed _ parse time cpu x0dx0ax0dx0a由此可以得到用户SQL语句平均解析等待时间＝waite time / parse count。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句 x0dx0ax0dx0aSELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA x0dx0ax0dx0aORDER BY PARSE_CALLS; x0dx0ax0dx0a来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。 x0dx0ax0dx0a2、数据库管理员还可以通过下述语句： x0dx0ax0dx0aSELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA; x0dx0ax0dx0a查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。 x0dx0ax0dx0a3、3、数据库管理员可以通过v$system_event数据字典中的“latch free”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latch free查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。 x0dx0ax0dx0a内存参数的调整 x0dx0ax0dx0a内存参数的调整主要是指ORACLE数据库的系统全局区（SGA）的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。 x0dx0ax0dx0a1、 1、 共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句： x0dx0ax0dx0aselect (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache; x0dx0ax0dx0a来查看共享SQL区的使用率。这个使用率应该在90％以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句： x0dx0ax0dx0aselect (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache; x0dx0ax0dx0a查看数据字典缓冲区的使用率，这个使用率也应该在90％以上，否则需要增加共享池的大小。 x0dx0ax0dx0a2、 2、 数据缓冲区。数据库管理员可以通过下述语句： x0dx0ax0dx0aSELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads'); x0dx0ax0dx0a来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。 x0dx0ax0dx0a这个命中率应该在90％以上，否则需要增加数据缓冲区的大小。 x0dx0ax0dx0a3、 3、 日志缓冲区。数据库管理员可以通过执行下述语句： x0dx0ax0dx0aselect name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率： x0dx0ax0dx0a申请失败率＝requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。
❸ 怎样保持Oracle数据库SQL性能的稳定性
有客户遇到SQL性能不稳定 突然变差导致系统性能出现严重问题的情况 对于大型的系统来说 SQL性能不稳定 有时突然变差 这是常常遇到的问题 这也是一些DBA的挑战
对于使用Oracle数据库的应用系统 有时会出现运行得好好的SQL 性能突然变差 特别是对于OLTP类型系统执行频繁的核心SQL 如果出现性能问题 通常会影响整个数据库的性能 进而影响整个系统的正常运行 对于个别的SQL 比如较少使用的查询报表之类的SQL 如果出现问题 通常只影响少部分功能模块 而不会影响整个系统
那么应该怎么样保持SQL性能的稳定性？
SQL的性能变差 通常是在SQL语句重新进行了解析 解析时使用了错误的执行计划出现的 下列情况是SQL会重新解析的原因
SQL语句没有使用绑定变量 这样SQL每次执行都要解析
SQL长时间没有执行 被刷出SHARED POOL 再次执行时需要重新解析
在SQL引用的对象（表 视图等）上执行了DDL操作 甚至是结构发生了变化 比如建了一个索引
对SQL引用的对象进行了权限更改森拿
重新分析（收集统计信息）了SQL引用的表和索引 或者表和索引统计信息被删除
修改了与性能相关的部分参数
刷新了共享池
当然重启数据库也会使所有SQL全部重新解析
SQL重新解析后 跟以前相比 性能突然变差 通常是下列原因
表和索引的优化统计信息被删除 或者重新收集后统计信息不准确 重新收集统计信息通常是由于收集策略（方法）不正确引起 比如对分区表使用 *** yze命令而不是用dbms_stats包 收集统计信息时采样比例过小等等 Oracle优化器严重依赖于统计信息 如果统计信息有问题 则很容易导致SQL不能使用正确的执行计划
SQL绑定变量窥蚂祥探(bind peeking) 同时绑定变量对应的列上有直方图 或者绑定变量的值变化范围过大 分区数据分布极不均匀
） 绑定变量的列上有闷春搏直方图
假如表orders存储所有的订单 state列有 种不同的值 表示未处理 表示处理成功完成 表示处理失败 State列上有一个索引 表中绝大部分数据的state列为 和 占少数 有下面的SQL
select * from orders where state=:b
这里:b 是变量 在大多数情况下这个值为 则应该使用索引 但是如果SQL被重新解析 而第一次执行时应用传给变量b 值为 则不会使用索引 采用全表扫描的方式来访问表 对于绑定变量的SQL 只在第一次执行时才会进行绑定变量窥探 并以此确定执行计划 该SQL后续执行时全部按这个执行计划 这样在后续执行时 b 变量传入的值为 的时候 仍然是第一次执行时产生的执行计划 即使用的是全表扫描 这样会导致性能很差
） 绑定变量的值变化范围过大
同样假如orders表有一列created_date表示一笔订单的下单时间 orders表里面存储了最近 年的数据 有如下的SQL
Select * from orders where created_date >=:b ;
假如大多数情况下 应用传入的b 变量值为最近几天内的日期值 那么SQL使用的是created_date列上的索引 而如果b 变量值为 个月之前的一个值 那么就会使用全表扫描 与上面描述的直方图引起的问题一样 如果SQL第 次执行时传入的变量值引起的是全表扫描 那么将该SQL后续执行时都使用了全表扫描 从而影响了性能
） 分区数据量不均匀
对于范围和列表分区 可能存在各个分区之间数据量极不均匀的情况下 比如分区表orders按地区area进行了分区 P 分区只有几千行 而P 分区有 万行数据 同时假如有一列proct_id 其上有一个本地分区索引 有如下的SQL
select * from orders where area=:b and proct_id =:b
这条SQL由于有area条件 因此会使用分区排除 如果第 次执行时应用传给b 变量的值正好落在P 分区上 很可能导致SQL采用全表扫描访问 如前面所描述的 导致SQL后续执行时全部使用了全表扫描
其他原因 比如表做了类似于MOVE操作之后 索引不可用 对索引进行了更改 当然这种情况是属于维护不当引起的问题 不在本文讨论的范围
综上所述 SQL语句性能突然变差 主要是因为绑定变量和统计信息的原因 注意这里只讨论了突然变差的情况 而对于由于数据量和业务量的增加性能逐步变差的情况不讨论
为保持SQL性能或者说是执行计划的稳定性 需要从以下几个方面着手
规划好优化统计信息的收集策略 对于Oracle g来说 默认的策略能够满足大部分需求 但是默认的收集策略会过多地收集列上的直方图 由于绑定变量与直方图固有的矛盾 为保持性能稳定 对使用绑定变量的列 不收集列上的直方图 对的确需要收集直方图的列 在SQL中该列上的条件就不要用绑定变量 统计信息收集策略 可以考虑对大部分表 使用系统默认的收集策略 而对于有问题的 可以用DBMS_STATS LOCK_STATS锁定表的统计信息 避免系统自动收集该表的统计信息 然后编写脚本来定制地收集表的统计信息 脚本中类似如下
exec dbms_stats unlock_table_stats…
exec dbms_stats gather_table_stats…
exec dbms_stats lock_table_stats…
修改SQL语句 使用HINT 使SQL语句按HINT指定的执行计划进行执行 这需要修改应用 同时需要逐条SQL语句进行 加上测试和发布 时间较长 成本较高 风险也较大
修改隐含参数 _optim_peek_user_binds 为FALSE 修改这个参数可能会引起性能问题（这里讨论的是稳定性问题）
使用OUTLINE 对于曾经出现过执行计划突然变差的SQL语句 可以使用OUTLINE来加固其执行计划 在 g中DBMS_OUTLN CREATE_OUTLINE可以根据已有的执行正常的SQL游标来创建OUTLINE 如果事先对所有频繁执行的核心SQL使用OUTLINE加固执行计划 将最大可能地避免SQL语句性能突然变差
注 DBMS_OUTLN可以通过$ORACLE_HOME/rdbms/admin/dbmsol sql脚本来安装
使用SQL Profile SQL Profile是Oracle g之后的新功能 此处不再介绍 请参考相应的文档
除此之外 可以调整一些参数避免潜在的问题 比如将 _btree_bitmap_plans 参数设置为FALSE（这个参数请参考互联网上的文章或Oracle文档）
lishixin/Article/program/Oracle/201311/18054
❹ Oracle数据库强制索引
当where子句对某一列使用函数时 除非利用这个简单的技术强制索引 否则Oracle优化器不能在查询中使用索引
通常情况下 如果在WHERE子句中不使用诸如UPPER REPLACE 或SUBSTRD等函数 就不能对指定列建立特定的条件 但如果使用了这些函数 则会出现一粗闹个问题 这些函数会阻碍Oracle优化器对列使用索引 因而与采用索引的情况相比较 查询会花费更多的时间
庆幸的是 如果在使用函数的这些列中包含了字符型数据 可以用这样一种方法修改查询语句 以达到强制性使用索引 更有效地运行查询 这篇文章介绍了涉及的技术 并说明了在两种典型情况下怎样实现
大小写混合情况在讨论由于函数修改了列的内容 如何强制使用索引前 让我们首先看看为什么Oracle优化器在这种情况下不能使用索引 假定我们要搜寻包含了大小写混合的数据 如在表 中ADDRESS表的NAME列 因为数据是用户输入的 我们无法使用已经统一改为大写的数据 为了找到每一个名为john的地址 我们使用包含了UPPER子句的查询语句 如下所示
SQL> select address from address where upper(name) like JOHN ;
在运行这个查询语句前 如果我们运行了命令 set autotrace on 将会得到下列结果 其中包含了执行过程
ADDRESS cleveland row selected Execution Plan SELECT STATEMENT TABLE ACCESS FULL ADDRESS
可以看到 在这种情况下 Oracle优化器对ADDRESS 表作了一次完整的扫描 而没有使用NAME 列的索引 这是因为索引是根据列中数据的实际值建立的 而UPPER 函数已经将字符转换成大写 即修改了这些值 因此该查询不能使用这列的索引 优化器不能与索引项比较 JOHN 没有索引项对应于 JOHN 只有 john
值得庆幸的是 如果在这种情况下想要强制使用索引 有一种简便的方法 只要在WHERE 子句中增加一个或多个特定友凳扮的条件 用于测试索引值 并减少需要扫描的行 但这并没有修改原来SOL 编码中的条件 以下列查询语句为例
SQL> select address from address where upper(name) like JO% AND (name like J% or name like j% );
使用这种查询语句（已设置AUTOTRACE） 可得到下列结果
ADDRESS cleveland row selected Execution Plan SELECT STATEMENT CONCATENATION TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I
现在 优化器为WHERE 子句中AND 联结的两个语句中每一个语句确定的范围进行扫描 第二个语句没有引用函数 因而使用了索引 在两个范围扫描后 将运行结果合并
在这个例子中 如果数据库有成百上千行 可以用下列方法扩充WHERE 子句 进一步缩小扫描范围
select address from address where upper(name) like JOHN AND (name like JO% or name like jo% or name like Jo or name like jO );
得到的结果与以前相同 但是 其执行过程如好灶下所示 表明有 个扫描范围
Execution Plan SELECT STATEMENT CONCATENATION TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I
如果试图进一步提高查询速度 我们可以在特定的 name like 条件中指明 个或更多的字符 然而 这样做会使得WHERE子句十分笨重 因为需要大小写字符所有可能的组合 joh Joh jOh joH等等 除此之外 指定一个或两个字符已足以加快查询的运行速度了
现在让我们看看 当我们引用不同的函数时 怎样运用这个基本技术
使用REPLACE的情况正如名字不总是以大写输入一样 电话号码也会以许多格式出现 如 （ ） 等等
如果在列名为 PHONE_NUMBER中搜寻上述号码时 可能需要使用函数REPLACE以保证统一的格式 如果在PHONE_NUMBER列中只包含空格 连字符和数字 where 子句可以如下所示
WHERE replace(replace(phone_number ) ) =
WHERE子句两次使用REPLACE 函数去掉了连字符和空格 保证了电话号码是简单的数字串 然而 该函数阻止了优化器在该列使用索引 因此 我们按如下方法修改WHERE子句 以强制执行索引
WHERE replace(replace(phone_number ) ) = AND phone_number like %
如果我们知道数据中可能包含圆括号 WHERE 子句会稍微复杂一点 我们可以再增加REPLACE 函数（去掉圆括号 连字符和空格） 按如下所示扩充增加的条件
WHERE replace(replace(replace(replace(phone_number ) ) ( ) ) ) = AND (phone number like % or phone_number like ( % )
该例强调了巧妙地选用WHERE 子句条件的重要性 而且 这些条件不会改变查询结果 你的选择应基于完全了解该列中存在的信息类型 在该例中 我们需要知道 PHONE_NUMBER 数据中存在几种不同的格式 这样 我们能够修改WHERE 子句而不会影响查询结果
正确的条件 lishixin/Article/program/Oracle/201311/18519
❺ ORACLE索引提高效率
用索引漏氏提高效率
索引是表的一个概念部分 用来提高检索数据的效率 实际上 ORACLE使用了一个复杂的自平衡B tree结构 通常 通过索引查询数据比全表扫描要快 当ORACLE找出执行查询和Update语句的最佳路径时 ORACLE优化器将使用索引 同样在联结多个表时使用索引也可以提高效率 另一个使用索引的好处是 它提供了主键(primary key)的唯一性验证
除了那些LONG或LONG RAW数据类型 你可以索引几乎所有的列 通常 在大型表中使用索引特别有效 当然 你也会发现 在扫描小表时 使用索引同样能提高效率
虽然使用索引能得到查询效率的提高 但是我们也必须注意到它的代价 索引需要空间来
存储 也辩搜辩需要定期维护 每当有记录在表中增减或索引列被修改时 索引本身也会被修改 这意味着每条记录的INSERT DELETE UPDATE将为此多付出 次的磁盘I/O 因为索引需要额外的存储空间和处理 那些不必要的索引反而会使查询反应时间变慢
定期的重构索引是有必要的
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
索引的操作
ORACLE对索引有两种访问模式
索引唯一扫描 ( INDEX UNIQUE SCAN)
大多数情况下 优化器通过WHERE子句访问INDEX
例如:
表LODGING有两个索引 : 建立在LODGING列上的唯一性索引LODGING_PK和建立在MANAGER列上的非唯一性索引LODGING$MANAGER
SELECT * FROM LODGING
WHERE LODGING = ROSE HILL ;
在内部 上述SQL将被分成两步执行 首先 LODGING_PK 索引将通过索引唯一扫描的方式被访问 获得相对应的ROWID 通过ROWID访问表的方式 执行下一步检索
如果被检索返回的列包括在INDEX列中 ORACLE将不执行第二步的处理(通过ROWID访问表) 因为检索数据保存在索引中 单单访问索引就可以完全满足查询结果
下面SQL只需要INDEX UNIQUE SCAN 操作
SELECT LODGING FROM LODGING WHERE LODGING = ROSE HILL ;
索引范围查询(INDEX RANGE SCAN)
适用于两种情况:
基于一个范围携缺的检索
基于非唯一性索引的检索
例 :
SELECT LODGING FROM LODGING WHERE LODGING LIKE M% ;
WHERE子句条件包括一系列值 ORACLE将通过索引范围查询的方式查询LODGING_PK 由于索引范围查询将返回一组值 它的效率就要比索引唯一扫描低一些
例 :
SELECT LODGING FROM LODGING WHERE MANAGER = BILL GATES ;
这个SQL的执行分两步 LODGING$MANAGER的索引范围查询(得到所有符合条件记录的ROWID) 和下一步同过ROWID访问表得到LODGING列的值 由于LODGING$MANAGER是一个非唯一性的索引 数据库不能对它执行索引唯一扫描
由于SQL返回LODGING列 而它并不存在于LODGING$MANAGER索引中 所以在索引范围查询后会执行一个通过ROWID访问表的操作
WHERE子句中 如果索引列所对应的值的第一个字符由通配符(WILDCARD)开始 索引将不被采用
SELECT LODGING FROM LODGING WHERE MANAGER LIKE ％HANMAN ;
在这种情况下 ORACLE将使用全表扫描
基础表的选择
基础表(Driving Table)是指被最先访问的表(通常以全表扫描的方式被访问) 根据优化器的不同 SQL语句中基础表的选择是不一样的
如果你使用的是CBO (COST BASED OPTIMIZER) 优化器会检查SQL语句中的每个表的物理大小 索引的状态 然后选用花费最低的执行路径
如果你用RBO (RULE BASED OPTIMIZER) 并且所有的连接条件都有索引对应 在这种情况下 基础表就是FROM 子句中列在最后的那个表
举例:
SELECT A NAME B MANAGER FROMWORKER A LODGING B
WHEREA LODGING = B LODING;
由于LODGING表的LODING列上有一个索引 而且WORKER表中没有相比较的索引 WORKER表将被作为查询中的基础表
多个平等的索引
当SQL语句的执行路径可以使用分布在多个表上的多个索引时 ORACLE会同时使用多个索引并在运行时对它们的记录进行合并 检索出仅对全部索引有效的记录
在ORACLE选择执行路径时 唯一性索引的等级高于非唯一性索引 然而这个规则只有
当WHERE子句中索引列和常量比较才有效 如果索引列和其他表的索引类相比较 这种子句在优化器中的等级是非常低的
如果不同表中两个想同等级的索引将被引用 FROM子句中表的顺序将决定哪个会被率先使用 FROM子句中最后的表的索引将有最高的优先级
如果相同表中两个想同等级的索引将被引用 WHERE子句中最先被引用的索引将有最高的优先级
举例:
DEPTNO上有一个非唯一性索引 EMP_CAT也有一个非唯一性索引
SELECT ENAME FROM EMP WHERE DEPT_NO = AND EMP_CAT = A ;
这里 DEPTNO索引将被最先检索 然后同EMP_CAT索引检索出的记录进行合并 执行路径如下:
TABLE ACCESS BY ROWID ON EMP AND EQUAL INDEX RANGE SCAN ON DEPT_IDX
INDEX RANGE SCAN ON CAT_IDX
等式比较和范围比较
当WHERE子句中有索引列 ORACLE不能合并它们 ORACLE将用范围比较
举例:
DEPTNO上有一个非唯一性索引 EMP_CAT也有一个非唯一性索引
SELECT ENAME FROM EMP WHERE DEPTNO > AND EMP_CAT = A ;
这里只有EMP_CAT索引被用到 然后所有的记录将逐条与DEPTNO条件进行比较 执行路径如下:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON CAT_IDX
不明确的索引等级
当ORACLE无法判断索引的等级高低差别 优化器将只使用一个索引 它就是在WHERE子句中被列在最前面的
举例:
DEPTNO上有一个非唯一性索引 EMP_CAT也有一个非唯一性索引
SELECT ENAME FROM EMP WHERE DEPTNO > AND EMP_CAT > A ;
这里 ORACLE只用到了DEPT_NO索引 执行路径如下:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON DEPT_IDX
我们来试一下以下这种情况:
SQL> select index_name uniqueness from user_indexes where table_name = EMP ;
INDEX_NAME UNIQUENES
EMPNO UNIQUE
EMPTYPE NONUNIQUE
SQL> select * from emp where empno >= and emp_type = A ;
no rows selected
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
TABLE ACCESS (BY INDEX ROWID) OF EMP
INDEX (RANGE SCAN) OF EMPTYPE (NON UNIQUE)
虽然EMPNO是唯一性索引 但是由于它所做的是范围比较 等级要比非唯一性索引的等式比较低!
强制索引失效
如果两个或以上索引具有相同的等级 你可以强制命令ORACLE优化器使用其中的一个(通过它 检索出的记录数量少)
举例:
SELECT ENAME FROM EMP WHERE EMPNO =
AND DEPTNO + = /*DEPTNO上的索引将失效*/
AND EMP_TYPE || = A /*EMP_TYPE上的索引将失效*/
这是一种相当直接的提高查询效率的办法 但是你必须谨慎考虑这种策略 一般来说 只有在你希望单独优化几个SQL时才能采用它
这里有一个例子关于何时采用这种策略
假设在EMP表的EMP_TYPE列上有一个非唯一性的索引而EMP_CLASS上没有索引
SELECT ENAME FROM EMP WHERE EMP_TYPE = A AND EMP_CLASS = X ;
优化器会注意到EMP_TYPE上的索引并使用它 这是目前唯一的选择 如果 一段时间以后 另一个非唯一性建立在EMP_CLASS上 优化器必须对两个索引进行选择 在通常情况下 优化器将使用两个索引并在他们的结果集合上执行排序及合并 然而 如果其中一个索引（EMP_TYPE）接近于唯一性而另一个索引（EMP_CLASS）上有几千个重复的值 排序及合并就会成为一种不必要的负担 在这种情况下 你希望使优化器屏蔽掉EMP_CLASS索引
用下面的方案就可以解决问题
SELECT ENAME FROM EMP WHERE EMP_TYPE = A AND EMP_CLASS|| = X ;
避免在索引列上使用计算．
WHERE子句中 如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．
举例:
低效
SELECT … FROM DEPT WHERE SAL * > ;
高效:
SELECT … FROM DEPT WHERE SAL > / ;
自动选择索引
如果表中有两个以上（包括两个）索引 其中有一个唯一性索引 而其他是非唯一性．
在这种情况下 ORACLE将使用唯一性索引而完全忽略非唯一性索引．
举例:
SELECT ENAME FROM EMP WHERE EMPNO =
AND DEPTNO = ;
这里 只有EMPNO上的索引是唯一性的 所以EMPNO索引将用来检索记录．
TABLE ACCESS BY ROWID ON EMP
INDEX UNIQUE SCAN ON EMP_NO_IDX
避免在索引列上使用NOT
通常 我们要避免在索引列上使用NOT NOT会产生在和在索引列上使用函数相同的
影响 当ORACLE 遇到 NOT 他就会停止使用索引转而执行全表扫描
举例:
低效: (这里 不使用索引)
SELECT … FROM DEPT WHERE DEPT_CODE NOT = ;
高效: (这里 使用了索引)
SELECT … FROM DEPT WHERE DEPT_CODE > ;
需要注意的是 在某些时候 ORACLE优化器会自动将NOT转化成相对应的关系操作符
NOT > to <=
NOT >= to <
NOT < to >=
NOT <= to >
SQL> select * from emp where NOT empno > ;
no rows selected
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
TABLE ACCESS (BY INDEX ROWID) OF EMP
INDEX (RANGE SCAN) OF EMPNO (UNIQUE)
SQL> select * from emp where empno <= ;
no rows selected
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
TABLE ACCESS (BY INDEX ROWID) OF EMP
INDEX (RANGE SCAN) OF EMPNO (UNIQUE)
两者的效率完全一样 也许这符合作者关于 在某些时候 ORACLE优化器会自动将NOT转化成相对应的关系操作符 的观点．
用>=替代>
如果DEPTNO上有一个索引
高效:
SELECT * FROM EMP WHERE DEPTNO >=
低效:
SELECT * FROM EMP WHERE DEPTNO >
lishixin/Article/program/Oracle/201311/17710
❻ 数据库性能优化有哪些措施
1、调整数据结构的设计
这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。
2、调整应用程序结构设计
这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。
3、调整数据库SQL语句
应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器(OracleOptimizer)和行锁管理器(row-levelmanager)来调整优化SQL语句。
4、调整服务器内存分配
内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区(SGA区)的数据缓冲区、日志缓冲区和共享池的大小;还可以调整程序全局区(PGA区)的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。
5、调整硬盘I/O
这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。
6、调整操作系统参数
例如：运行在UNIX操作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。
实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。
一、ORACLE数据库性能优化工具
常用的数据库性能优化工具有：
ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。
操作系统工具，例如UNIX操作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现在什么地方有时候很有用。
SQL语言跟踪工具(SQLTRACEFACILITY)，SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文件，管理员可以使用TKPROF工具查看这些文件。
ORACLEEnterpriseManager(OEM)，这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。
EXPLAINPLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。
二、ORACLE数据库的系统性能评估
信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。
1、在线事务处理信息系统(OLTP)，这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数：
数据库回滚段是否足够?
是否需要建立ORACLE数据库索引、聚集、散列?
系统全局区(SGA)大小是否足够?
SQL语句是否高效?
2、数据仓库系统(DataWarehousing)，这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数：
是否采用B*-索引或者bitmap索引?
是否采用并行SQL查询以提高查询效率?
是否采用PL/SQL函数编写存储过程?
有必要的话，需要建立并行数据库提高数据库的查询效率
三、SQL语句的调整原则
SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAINPLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则：
1、尽量使用索引。试比较下面两条SQL语句：
语句A：SELECTdname,
(SELECTdeptnoFROMemp);
语句B：SELECTdname,deptnoFROMdeptWHERENOTEXISTS
(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno);
这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。
2、选择联合查询的联合次序。考虑下面的例子：
SELECTstuffFROMtabaa,tabbb,tabcc
WHEREa.acolbetween:alowand:ahigh
ANDb.bcolbetween:blowand:bhigh
ANDc.ccolbetween:clowand:chigh
ANDa.key1=b.key1
AMDa.key2=c.key2;
这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。
3、在子查询中慎重使用IN或者NOTIN语句，使用where(NOT)exists的效果要好的多。
4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。
5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。
6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。
四、CPU参数的调整
CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90%以上。如果空闲时间CPU使用率就在90%以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。
使用操作相同命令可以看到CPU的使用情况，一般UNIX操作系统的服务器，可以使用sar_u命令查看CPU的使用率，NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。
数据库管理员可以通过查看v$sysstat数据字典中“CPUusedbythissession”统计项得知ORACLE数据库使用的CPU时间，查看“OSUserlevelCPUtime”统计项得知操作系统用户态下的CPU时间，查看“OSSystemcallCPUtime”统计项得知操作系统系统态下的CPU时间，操作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占操作系统总的CPU时间90%以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。
数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。
出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。
1、数据库管理员可以执行下述语句来查看SQL语句的解析情况：
SELECT*FROMV$SYSSTATWHERENAMEIN
('parsetimecpu','parsetimeelapsed','parsecount(hard)');
这里parsetimecpu是系统服务时间，parsetimeelapsed是响应时间，用户等待时间，waitetime=parsetimeelapsed_parsetimecpu
由此可以得到用户SQL语句平均解析等待时间=waitetime/parsecount。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句
SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA
ORDERBYPARSE_CALLS;
来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。
2、数据库管理员还可以通过下述语句：
SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;
查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。
3、数据库管理员可以通过v$system_event数据字典中的“latchfree”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latchfree查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。
五、内存参数的调整
内存参数的调整主要是指ORACLE数据库的系统全局区(SGA)的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。
1、共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句：
select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache;
来查看共享SQL区的使用率。这个使用率应该在90%以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句：
select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache;
查看数据字典缓冲区的使用率，这个使用率也应该在90%以上，否则需要增加共享池的大小。
2、数据缓冲区。数据库管理员可以通过下述语句：
SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads');
来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。
这个命中率应该在90%以上，否则需要增加数据缓冲区的大小。
3、日志缓冲区。数据库管理员可以通过执行下述语句：
selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests');
查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率：
申请失败率=requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。
昆明北大青鸟java培训班转载自网络如有侵权请联系我们感谢您的关注谢谢支持
❼ 在oracle数据库中，影响优化器生成执行计划的因素有哪些
9i前的RBO不熟，也就不敢妄言。
关于10g后的CBO，谈下我的理解。
首先，影响优化器执行计划最主要的因素是统计信息。优化器根据统计信息情况，单表上选择全表扫描还是索引。表联接方式上选择嵌套，哈希还是合并排序。不同的统计信息将会生成不同的执行计划。很多时候发现之前跑的好好的sql，突然变慢了，多数情况下重新收集下统计信息便解决了。统计信息这一块需要关注直方图这一块，很多生产环境都存在数据倾斜的情况，如若未准确收集直方图，那么生成的执行计划便有失偏颇。
--------------------------------------------------------------------------------------------------------------------
第二点，sql语句的写法问题。比如字段上有索引，但谓词条件写成like '%xxx%'方式，将导致该字段上索引不可用。比如表连接方式用<>之类，将无法使用hash join。其实这些与其说是写法问题，倒不如说是oracle自身有一定的编码规则，符合该规则条件，方可用到index之类。
--------------------------------------------------------------------------------------------------------------------
第三点，也是最无奈的一点，CBO的自身缺陷问题。很多时候，统计信息是最新的，也符合写法规范，但CBO就是不生成我们所期待的执行计划。这个时候，通常要改变sql语句的逻辑写法，比如标量子查询可否换成左连接，用with as替换一些子查询等，以期待oracle生成更高效率的执行计划。另外，就是使用hint来迫使CBO生成你所期待的执行计划，但CBO不一定就范。
谈及缺陷，也不算不上缺陷，尤其是表越多，将会出现更多排列的可能性，oracle不可能将所有执行计划都生成出来然后选择一个最优的，定是按照一定比例择取，但具体多少，我不详。也就是说，DBA完全可以凭借自身对你所管理的oracle了解程度，给sql语句指定一个最优的执行计划。
--------------------------------------------------------------------------------------------------------------------
其他还有一些细节问题，可在日常工作中慢慢体会，cbo还是相当强大的。
❽ 如何修改oracle优化器模式
ALTERSYSTEMSETOPTIMIZER_MODE=ALL_ROWSscope=both;
其他可以选择的脊猛模式还有RULE/CHOOSE/FIRST_ROWS/ALL_ROWS。
应用系统优化最好对大查皮野简询单独调优，修改优燃裤化器模式之后，有可能别的查询又会变慢。
❾ cbo是什么意思
一、CBO （基于代价的优化方式）
CBO是Cost-Based Optimization的缩写，中文叫做“基于成本的优化。”
Oracle的优化器有两种优化方式,即基于规则的优化方式(Rule-Based Optimization，简称为RBO)和基于代价的优化方式(Cost-Based Optimization，简称为CBO)，在Oracle8及以后的版本,Oracle强烈推荐用CBO的方式。
二、CBO（首席品牌官）
CBO（Chief Brand Officer）首席品牌官，是现代组织（包括企业、政府或其他组织）中设置的专门负责品牌战略管理与运营的高级官员岁裤，代表CEO就企业形象、品牌以及文化进行内外部沟通。
三、CBO（国会预算办公室）
CBO是美国 国会预算办公室国会下设的一个专业的、非党派的机构，成立于1975年，没有审批权游漏。
四、CBO （ORACLE提供的一种SQL优化器）
ORACLE提供的一种SQL优化器。
ORACLE提供了CBO、RBO两种SQL优化器。CBO在ORACLE7 引入，但在ORACLE8i 中才成熟。ORACLE 已经明确声明在ORACLE9i之后的版本中(ORACLE 10G )，RBO将不再支持。
五、CBO（市场流通债券的再证券化）
Collateralised Bond Obligation，即市场流通债券的再证券化，是CDO（担神雀烂保债务权证）的一个分支。
❿ 如何进行oracle数据库性能优化
你最好买一本专门讲ORACLE性能优化的书，好好看看\x0d\x0a1、调整数据库服务器的性能\x0d\x0aOracle数据库服务器是整个系统的核心，它的性能高低直接影响整个系统的性能，为了调整Oracle数据库服务器的性能，主要从以下几个方面考虑： \x0d\x0a1.1、调整操作系统以适合Oracle数据库服务器运行\x0d\x0aOracle数据库服务器很大程度上依赖于运行服务器的操作系统，如果操作系统不能提供最好性能，那么无论如何调整，Oracle数据库服务器也无法发挥其应有的性能。 \x0d\x0a1.1.1、为Oracle数据库服务器规划系统资源 \x0d\x0a据已有计算机可用资源, 规划分配给Oracle服务器资源原则是：尽可能使Oracle服务器使用资源最大化,特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务。 \x0d\x0a1.1.2、调整计算机系统中的内存配置 \x0d\x0a多数操作系统都用虚存来模拟计算机上更大的内存，它实际上是硬盘上的一定的磁盘空间。当实际的内存空间不能满足应用软件的要求时，操作系统就将用这部分的磁盘空间对内存中的信息进行页面替换，这将引起大量的磁盘I/O操作，使整个服务器的性能下降。为了避免过多地使用虚存，应加大计算机的内存。 \x0d\x0a1.1.3、为Oracle数据库服务器设置操作系统进程优先级 \x0d\x0a不要在操作系统中调整Oracle进程的优先级，因为在Oracle数据库系统中，所有的后台和前台数据库服务器进程执行的是同等重要的工作，需要同等的优先级。所以在安装时，让所有的数据库服务器进程都使用缺省的优先级运行。 \x0d\x0a1.2、调整内存分配\x0d\x0aOracle数据库服务器保留3个基本的内存高速缓存，分别对应3种不同类型的数据：库高速缓存，字典高速缓存和缓冲区高速缓存。库高速缓存和字典高速缓存一起构成共享池，共享池再加上缓冲区高速缓存便构成了系统全程区(SGA)。SGA是对数据库数据进行快速访问的一个系统全程区，若SGA本身需要频繁地进行释放、分配，则不能达到快速访问数据的目的，因此应把SGA放在主存中，不要放在虚拟内存中。内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能，由于Oracle数据库服务器的内存结构需求与应用密切相关，所以内存结构的调整应在磁盘I/O调整之前进行。 \x0d\x0a1.2.1、库缓冲区的调整 \x0d\x0a库缓冲区中包含私用和共享SQL和PL/SQL区，通过比较库缓冲区的命中率决定它的大小。要调整库缓冲区，必须首先了解该库缓冲区的活动情况，库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect sum(pins),sum(reloads) from v$librarycache; \x0d\x0a \x0d\x0aPins列给出SQL语句，PL/SQL块及被访问对象定义的总次数；Reloads列给出SQL 和PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误。如果sum(pins)/sum(reloads) ≈0，则库缓冲区的命中率合适；若sum(pins)/sum(reloads)>1, 则需调整初始化参数 shared_pool_size来重新调整分配给共享池的内存量。 \x0d\x0a1.2.2、数据字典缓冲区的调整 \x0d\x0a数据字典缓冲区包含了有关数据库的结构、用户、实体信息。数据字典的命中率，对系统性能影响极大。数据字典缓冲区的使用情况记录在动态性能表v$librarycache中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect sum(gets),sum(getmisses) from v$rowcache; \x0d\x0a \x0d\x0aGets列是对相应项请求次数的统计；Getmisses 列是引起缓冲区出错的数据的请求次数。对于频繁访问的数据字典缓冲区，sum(getmisses)/sum(gets)<10%～15%。若大于此百分数，则应考虑增加数据字典缓冲区的容量，即需调整初始化参数shared_pool_size来重新调整分配给共享池的内存量。 \x0d\x0a1.2.3、缓冲区高速缓存的调整 \x0d\x0a用户进程所存取的所有数据都是经过缓冲区高速缓存来存取，所以该部分的命中率，对性能至关重要。缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads'); \x0d\x0a \x0d\x0adbblock gets和consistent gets的值是请求数据缓冲区中读的总次数。physical reads的值是请求数据时引起从盘中读文件的次数。从缓冲区高速缓存中读的可能性的高低称为缓冲区的命中率，计算公式： \x0d\x0a \x0d\x0aHit Ratio=1-(physical reds/(dbblock gets+consistent gets)) \x0d\x0a \x0d\x0a如果Hit Ratio<60%～70%，则应增大db_block_buffers的参数值。db_block_buffers可以调整分配给缓冲区高速缓存的内存量，即db_block_buffers可设置分配缓冲区高速缓存的数据块的个数。缓冲区高速缓存的总字节数=db_block_buffers的值*db_block_size的值。db_block_size 的值表示数据块大小的字节数，可查询 v$parameter 表： \x0d\x0a \x0d\x0aselect name,value from v$parameter where name='db_block_size'; \x0d\x0a \x0d\x0a在修改了上述数据库的初始化参数以后，必须先关闭数据库，在重新启动数据库后才能使新的设置起作用。