oracle执行计划

繁琐复杂的执行计划、可能迷了开发人员的眼、导致一条性感又傻X的SQL 在服务器上跑得特欢乐 有介于此、重点抓住几个部分、至于其他的嘛、当然是、非礼勿视咯、、 ㈠ 返回行的数量 Oracle优化器是基于成本的、评估成本的一个主要指标便是查询多少行 一般的、返回值在100W或者大表返回值超过总记录50%、可优化的空间就非常小 标记图为： ㈡ 返回行与逻辑读的比率 经验值是：每行5个以下一致性读(consistent gets + db block gets = 所谓的logical reads)开销是可接受的 标记图为： 每行需要花费7 个逻辑读 ㈢ 聚合查询 这类查询有 2 点需要注意： ① 返回行应是扫描表的行数而不是1 ② 一般的优化技巧：把索引当成瘦表而无需再回表(回表标识为 Table Access By index rowid) 标记图为： ㈣ 预测行的准确度 执行计划里有个列叫：Rows、这是Oracle 预测返回的行、有些时候或许不是特马准备 记得拿该值和真正返回的行比较、如果确实不准确、应该去找原因、比如统计信息、直方图、高水位...等 标记图为： ㈤ 谓词信息 Predicate Information 有2 个取值：filter 和 access、其中、access 一般为索引读或hash join 关注此鸟、最重要的在于、查看是否有发生数据类型转换、这抑制了索引

select count(*) from t1; 这句话比较简单，但很有玄机！对这句话运行的理解，反映了你对数据库的理解深度！ 建立实验的大表他t1 SQL> conn scott/tiger 已连接。 SQL> drop table t1 purge; 表已删除。 SQL> create table t1 as select * from emp where 0=9; 表已创建。 SQL> insert into t1 select * from emp; 已创建14行。 SQL> insert into t1 select * from t1; 已创建14行。 SQL> / 已创建28行。 SQL> / 已创建56行。 SQL> / 已创建112行。 SQL> / 已创建224行。 SQL> / 已创建448行。 SQL> / 已创建896行。 SQL> / 已创建1792行。 SQL> / 已创建3584行。 SQL> / 已创建7168行。 SQL> / 已创建14336行。 SQL> / 已创建28672行。 SQL> / 已创建57344行。 SQL> commit; 提交完成。 收集统计信息 SQL> execute dbms_stats.gather_table_stats('SCOTT','T1'); PL/SQL 过程已成功完成。 SQL> SET AUTOT

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

关于SPOOL(SPOOL是SQLPLUS的命令，不是SQL语法里面的东西。) 对于SPOOL数据的SQL，最好要自己定义格式，以方便程序直接导入,SQL语句如： select taskindex||'|'||commonindex||'|'||tasktype||'|'||to_number(to_char(sysdate,'YYYYMMDD')) from ssrv_sendsms_task; spool常用的设置 set timing on ; //显示SQL语句的运行时间。默认值为OFF。在SQLPLUS中使用，时间精确到0.01秒。也就是10毫秒。在PL/SQL DEVELOPER 中，时间精确到0.001秒： set autotrace on ; //说明：设置允许对执行的SQL进行分析。默认值为OFF。 set autotrace off：不生成AUTOTRACE 报告，这是缺省模式 set autotrace on explain : AUTOTRACE只显示优化器执行路径报告 set autotrace on statistics:只显示执行统计信息 set autotrace on：包含执行计划和统计信息 set autotrace traceonly：同SET AUTOTRACE ON，但是不显示查询输出 set colsep' ';　　　 //域输出分隔符

本文首先详细介绍了oracle中buffer cache的 概念 以及所包含的 内存结构 。然后结合各个后台进程（包括DBWRn、CKPT、LGWR等）深入介绍了oracle对于buffer cache的管理机制，并详细解释了oracle为什么会采用现在的管理机制，是为了解决什么问题。比如为何会引入touch次数、为何会引入增量检查点等等。最后全面介绍了有关buffer cache监控以及调优的实用方法。 1. buffer cache的 概念 用最简单的语言来描述oracle数据库的本质，其实就是能够用磁盘上的一堆文件来存储数据，并提供了各种各样的手段对这些数据进行管理。作为管理数据的最基本要求就是能够保存和读取磁盘上的文件中的数据。众所周知，读取磁盘的速度相对来说是非常慢的，而 内存 相对速度则要快的多。因此为了能够加快处理数据的速度，oracle必须将读取过的数据缓存在内存里。而oracle对这些缓存在内存里的数据起了个名字：数据高速缓存区（db buffer cache），通常就叫做buffer cache。按照oracle官方的说法，buffer cache就是一块含有许多数据块的内存区域，而这些数据块主要都是数据文件里的数据块内容的拷贝。通过初始化参数：buffer_cache_size来指定buffer cache的大小。oracle实例一旦启动

实验环境：OEL+Oracle11.2.0.3+physical standby 众所周知，Data Guard已经是现今标准的主流容灾方案，由于日志传递对于网络适应程度强，且可以采用同步实时的传递方式和异步延迟的传递方式，甚至可以成为远程的异地容灾方案。不管用于何种用途，DG都免不了要进行角色转换，即将standby 数据库切换为primary数据库，角色转换分为：switchover和failover两种；两种区别从三个角度来对比： （1）、使用场合不同：Switchover 用于有准备的、计划之中的切换，通常是系统升级、数据迁移等常态任务；Failover用于意料之外的突发情况，比如异常掉电、自然灾难等等。 （2）、数据丢失程度不同：Switchover不会丢失数据，Failover通常意味着有部分数据丢失。 （3）、善后处理的不同：Switchover之后Dataguard环境不会被破坏，任然有Primary、Standby两种角色的系统存在。但是Failover之后，Dataguard环境就会被破坏，必须需要重建。 一、Switchover 因为Switchover这种转化是有DBA主动、人为触发的，所以Switchover的步骤都是标准化的。Switchover流程是从Primary Database开始，终止于Standby Database。