oracle执行计划

摘要 为了学习研究MySQL数据库在工作原理，深刻理解MySQL在企业运用时如何保证其高效运行。分别从表结构的优化，SQL语句的优化，存储引擎的选择，索引的优化以及现今MySQL的发展与其他企业级数据库的比较。介绍了从编码选择到数据类型的选择以及从整体的角度设计表结构。在SQL语句的选择和使用的介绍的时候，深入介绍了一些基本的使用原则以及在一般在使用过程中我们存在的误区以及如何解决这些问题。着重介绍了MySQL的几个存储引擎MyISAM、InnoDB和NDBCluster的差异以及各自的适用范围。有介绍了MySQL的索引的一些优化的建议以及高屋建瓴地阐述和比较了MySQL的优劣和发展态势。 前言 数据库作为应用作为广泛，地位极为重要的中间件应用，学习和使用数据库管理系统变得越来越重要。为了研究和总结对mysql数据库的学习结果，特别从数据表结构、sql语句优化、存储引擎的选择、索引的应用、以及mysql的比较总结对mysql技术做了一个比较全面升入的介绍。使用mysql的过程中，如何更好地使用与优化越来越重要，在这篇文章中就阐述。 第一章 表结构的优化 数据表是数据库的具体表现形式，设计优良的数据库拥有良好的表结构，者不单单指数据库的表需要满足范式结构，为了更有利于具体操作，表结构还需要实际的可扩展性，以便于做增删改查，又需要根据数据表的具体作用做出调节

基于版本：19c （12.2.0.3） AskScuti 创建方法： 克隆 创建 对应路径：属于克隆。PDB类型为： Refreshable 相关系列请参考《 Oracle创建PDB列表文章 》 注意 ： 创建可刷新的PDB， 源库必须处于归档 模式和 本地UNDO 模式 内容总览 1. 环境概述 2. 检查源库环境 3. 源库创建用户并授权 4. 目标库编辑TNS 5. 目标库创建DBLink 6. 目标库创建可刷新PDB 7. 目标库打开可刷新PDB 8. 可刷新PDB测试 1. 环境概述 为了概念理解统一，提前约定下： 远程CDB2中有个 ERP1 ，我们称 远程CDB2 为“源CDB”，IP：192.168.1.14 本地CDB1中有个 PDB1 ，我们称 本地CDB1 为“目标CDB”，IP：192.168.1.12 注意：源CDB和目标CDB是 相对而言 。就是 被克隆的 对象叫“ 源 ”， 准备克隆出来 的对象叫“ 目标 ”。因此，下面就是要通过 源CDB2中的ERP1 ，远程克隆出来一个可刷新的PDB，放在 目标CDB1中 ，名称为PDB_REF。 2. 检查源库环境 检查是否为归档模式 [oracle@henry ~]$ rlwrap sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on

1、备份数据库 采用RMAN或expdp都可以。 2、备份软件目录（node1/2） tar -czvf /u01/grid.tar.gz /u01/app/11.2.0/grid --exclude=/u01/app/11.2.0/grid/rdbms/audit/* tar -czvf /u01/database.tar.gz /u01/app/oracle/ --exclude=/u01/app/oracle/admin/orcl/adump/* 3、备份OCR（node1/2） [grid@vastdata01 ~]$ cd $ORACLE_HOME/bin [grid@vastdata01 bin]$ pwd /u01/app/11.2.0/grid/bin ./crsctl query css votedisk ./ocrcheck ./ocrconfig -manualbackup ./ocrconfig -export ocr.bak 4、备份OLR（node1/2） [grid@vastdata01 ~]$tar -cf /home/oracle/backup/ocr/olr.tar /u01/app/11.2.0/grid/cdata 5、升级前数据库对象检查 检查失效对象 select object_name,object_type from dba

第一章：oracle的优化器 1.优化器：优化器时Oracle数据库中内置的一个核心子系统。 2.分类：oracle数据库中优化器分为RBO和CBO，(Rule-Based-Optimizer) 基于规则的优化器 ，(Cost-Based-Optimizer) 基于成本的优化器 3.RBO等级从低到高分为1~15等级，1的执行效率最高，15等级最低，RBO内置的等级1所对应的执行路径为single row by rowid ，等级15则对应的执行路径为full table scan(全表扫描)。 4.CBO与RBO相比，有明显缺陷，在使用RBO情况下，执行计划一旦出现问题，很难对其做调整，还有就是，SQL的写法，甚至时目标SQL中涉及的各个对象在该SQL文本中的先后顺序，都可能会影响RBO对于该SQL执行计划的选择，还有，oracle数据库中有好多很好的特性，都不被RBO支持。 5.调整RBO，改变执行计划，比如where条件中，对NUMBER或者DATE类型的列加0，varchar2或者char类型加一个空格符，例如'||',如果遇到同等级的SQL时，RBO会根据目标SQL中所涉及的相关对象在数据字典缓存中的缓存顺序和目标SQL中涉及的各个对象在目标SQL文本中出现的先后顺序来综合判断，意味着我们可以通过调整相关对象在数据字典缓存中缓存顺序

一、目的： 　　1、说一说Oracle的Optimizer及其相关的一些知识。 　　2、回答一下为什么有时一个表的某个字段明明有索引,当观察一些SQL的执行计划时,发现确不走索引的问题。 　　3、如果你对 FIRST_ROWS、 ALL_ROWS这两种模式有疑惑时也可以看一下这篇文章。 Oracle在执行一个SQL之前,首先要分析一下语句的执行计划,然后再按执行计划去执行。分析语句的执行计划的工作是由优化器(Optimizer)来完成的。不同的情况,一条SQL可能有多种执行计划,但在某一时点,一定只有一种执行计划是最优的,花费时间是最少的。 二、 　 1、优化器的优化方式： Oracle的优化器共有两种的优化方式,即基于规则的优化方式(Rule-Based Optimization,简称为RBO)和基于代价的优化方式(Cost-Based Optimization,简称为CBO)。 　　A、RBO方式：优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。 比如我们常见的,当一个where子句中的一列有索引时去走索引。 　　B、CBO方式：依词义可知,它是看语句的代价(Cost)了,这里的代价 主要指Cpu和内存 。优化器在判断是否用这种方式时, 主要参照的是表及索引的统计信息 。 统计信息给出表的大小 、有多少行、每行的长度等信息 。这些统计信息起初在库内是没有的

1.背景知识介绍 2.构造测试用例 3.场景测试 4.总结 1.背景知识介绍 我们知道，Oracle在传统的OLTP(在线事务处理)类系统中，强烈推荐使用绑定变量，这样可以有效的减少硬解析从而增加系统的并发处理能力。甚至在有些老旧系统，由于在开始开发阶段缺乏认识没有使用到绑定变量，后期并发量增长且无法改造程序时，运维DBA还会不得已去设置cursor_sharing=force来强制使用系统的绑定变量（这是一个万不得已的方案，并不是最佳实践）。 虽然使用绑定变量给OLTP系统带来了巨大的好处，但也同时带来一些棘手的问题，最典型的就是由于SQL文本中包含绑定变量，优化器无法知道绑定变量代表的具体值，只能使用默认的可选择率，这就可能导致由于无法准确判断值的可选择率而造成选择错误的执行计划。Oracle在9i时代就有了针对这个问题的解决方案，即绑定变量窥探（bind peeking）特性。开启该特性的情况下，当遇到有绑定变量的SQL，在其第一次硬解析时，优化器会窥探真实的值从而准确判断可选择率（selectivity），最终选择正确的执行计划。可是该特性同时又引入另一个棘手的问题，因为在第一次硬解析之后就都是软/软软解析，所以也就不会再次窥探绑定变量的真实值，而如果该值所在字段本身数值比例就分布不均，就极可能导致性能问题（尤其是如果第一次窥探的值代表了少数情况，那问题就会更加严重）

AWR报告模板 1、 DB Time远远小于Elapsed时间，说明数据库比较空闲。如果是大于则说明数据库比较繁忙 举例介绍： Report A:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1
End Snap: 4612 24-Jul-08 23:00:25 17 1.7
Elapsed: 59.51 (mins)
DB Time: 466.37 (mins)
 先说Report A,在snapshot间隔中，总共约60分钟，cpu就共有60*8=480分钟，DB time为466.37分钟，则：
cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu有 466.37/480*100% 花费在处理Oracle的操作上，这还不包括后台进程
 2、Report Summary-->Load Profile（显示数据库负载情况） |— Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。 |— Redo size：每秒产生的日志大小(单位字节)，可标志数据变更频率,

NC Oracle SQL 脚本跟踪 脚本: select * from v$sqlarea a where 1=1 and a.LAST_ACTIVE_TIME >= to_date( '2013-02-21 18:23:00','yyyy-MM-dd HH24:mi:ss') and a.LAST_ACTIVE_TIME < to_date( '2013-02-21 18:24:00','yyyy-MM-dd HH24:mi:ss') --and a.LAST_ACTIVE_TIME < to_date('2012-02-21 17:55','yyyy-MM-dd HH24:mi:ss') and a.MODULE_HASH <> 0 and a.MODULE = 'JDBC Thin Client' order by a.LAST_ACTIVE_TIME desc 其他相关网摘: ---------------------------------------------------------------------- 2011-11-26 11:08 跟踪oracle中sql语句执行过程 (转自ocean_helen) （1）select * from v$sqlarea; 可以跟踪sql语句的执行过程，如果想跟踪某个时间点前后的语句，可以通过first_load

一.存储过程是一组为完成特定功能的sql语句，经编译后存储在数据库中。当一个事务涉及到多个sql语句或者多个表的操作时要考虑使用存储过程；还有当一个事务的完成需要复杂的商业逻辑（对多个数据操作，对多个状态的判断更改）以及比较复杂的统计和汇总也需要进行考虑。 二.存储过程的优缺点 优点： 1.使程序执行效率更高，安全性更好，过程建立后已经编译并且储存到数据库，直接写sql就需要先分析再执行，而且直接写sql会带来安全问题，例如sql注入等。 2.过程只是在调用时才使用，所以不会很占系统资源。 3.可以用于降低网络流量，存储过程代码直接存储于数据库中，不会产生大量T-sql语句的代码流量。 4.增强对执行计划的重复使用，可以通过使用远程过程调用 (RPC) 处理服务器上的存储过程而提高性能。 5.可维护性高。 6.代码精简一致，一个存储过程可以用于程序的不同位置。 7.增强安全性。（1）向用户授予对存储过程(而不是表)的访问权限，可提供对特定数据的访问；（2）提高代码安全，防止sql注入(未彻底解决)；（3）SqlParameter 类指定存储过程参数的数据类型，可以验证用户提供的值类型。 缺点：大量利用过程，会对服务器造成较大压力。 参考博客：https://www.cnblogs.com/dc-earl/articles/9260111.html 三.存储过程的编写 语法

一、前言 前面文章给大家介绍了当一条sql有多个执行计划时，如何通过spm去绑定其中一条执行计划。本文将继续介绍，如何给一条sql注入一个新的执行计划，去替换原始的执行计划。 二、解决办法 1. 生成初始执行计划所对应的sql plan baseline begin :temp := dbms_spm.load_plans_from_cursor_cache( sql_id => '原目标sql的sql_id', plan_hash_value => 原目标sql的plan hash value); end; / 2. 查出该sql的sql_handle select sql_handle, sql_text, plan_name, origin from dba_sql_plan_baselines where sql_text like '原目标sql的sql_text%'; 3. 生成新的sql plan baseline begin :temp := dbms_spm.load_plans_from_cursor_cache( sql_id => '加入合适hint后改写的sql的sql_id', plan_hash_value => 加入合适hint后改写的sql的plan hash value, sql_handle => '原目标sql在步骤(1)中所产生的sql