oracle执行计划

在oracle 中，对于一个提交的sql语句,存在两种可选的解析过程, 一种叫做 硬解析 ,一种叫做 软解析 . 一个硬解析需要经解析,制定执行路径,优化访问计划等许多的步骤.硬解释不仅仅耗费大量的cpu，更重要的是会占据重要的们闩（latch）资源，严重的影响系统的规模的扩大（即限制了系统的并发行）， 而且引起的问题不能通过增加内存条和cpu的数量来解决。这是因为门闩是为了顺序访问以及修改一些内存区域而设置的，这些内存区域是不能被同时修改。当一个sql语句提交后，oracle会首先检查一下共享缓冲池（shared pool）里有没有与之完全相同的语句，如果有的话只须执行软分析即可，否则就得进行硬分析。 而唯一使得oracle 能够重复利用执行计划的方法就是采用绑定变量。绑定变量的实质就是用于替代sql语句中的常量的替代变量。绑定变量能够使得每次提交的sql语句都完全一样。 普通sql语句： update ipsdba_test set sn1=‘SN11’,sn2=‘SN12’,sn3=‘SN13’ where sn_key=1; update ipsdba_test set sn1=‘SN21’,sn2=‘SN22’,sn3=‘SN23’ where sn_key=1; update ipsdba_test set sn1=‘SN31’,sn2=‘SN32’,sn3=‘SN33

Shared Pool/Library Cache Latch Contention 可能的原因 sql语句不能被重用，语句没有使用绑定变量，不合适的应用游标缓存大小，频繁的登入或登出，数据库对象上做过ddl操作，共享池太小等 在会话级别 V$SESSTAT parse time CPU parse time elapsed Ratio of parse count (hard) / execute count Ratio of parse count (total) / execute count 在游标缓存（V$SQLAREA/V$SQLSTATS） 高的PARSE_CALLS / EXECUTIONS EXECUTIONS = 1 differing only in literals in the WHERE clause (that is, no bind variables used) High RELOADS（高的重载次数） High INVALIDATIONS（高的失效次数，ddl等操作造成对象失败需要重新解析） Large (> 1mb) SHARABLE_MEM 共享池或库缓存latch 争用的主要原因是由于解析，有很多技术可以避免没必要的解析。 1.手工检查只执行次数很少的sql语句是不是相似的。 SELECT SQL_TEXT FROM V$SQLSTATS

注意，无论gather stale还是gather auto，都要求进行监视。 如果你执行一个alter table xxx monitoring命令，Oracle会用dba_tab_modifications视图来跟踪发生变动的表。 这样一来，你就确切地知道，自从上一次分析统计数据以来，发生了多少次插入、更新和删除操作。 SELECT * FROM Sys.Dba_Tab_Modifications WHERE Table_Owner = 'SCOTT'; 使用alter table xxx monitoring命令来实现Oracle表监视时，需要使用dbms_stats中的auto选项。 auto选项根据数据分布以及应用程序访问列的方式（例如通过监视而确定的一个列的工作量） 来创建直方图。使用method_opt=>’auto’类似于在dbms_stats的option参数中使用gather auto。 begin dbms_stats.gather_schema_stats(ownname => 'SCOTT', estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all columns size auto', degree => 7); end; estimate_percent选项

1. Shared Pool组成 　 Shared Pool由许多区间(Extent)组成，这些区间又由多个连续的内存块（Chunk）组成，这些内存块大小不一。从逻辑功能角度，Shared pool主要包含三个部分：Library Cache，Dictionary Cache和Control Structure。而这里，我们主要介绍其中的Library Cache。 2. Library Cache 　 Library Cache主要用于存储系统中的可执行对象（例如：SQL语句，PL/SQL块及相关对象等）及其相关信息（解析信息，可执行代码，相关对象及信息，相关控制结构等），以便实现这些可执行对象及其相关信息的快速访问和共享。 3. Hash Bucket Hash Bucket主要用于特定可执行对象的快速定位和存取，每个哈希桶中对应一个将多个可执行对象连接起来的链表，而这些可执行对象在链表中的表现形式就是可执行对象的句柄（Handle），当需要定位或访问特定对象时，系统通过对特定SQL或PL/SQL对象做特定哈希计算，就可以快速得知该特定对象应该位于的哈希桶，而每个哈希桶的链表比较短，尤其是高版本的Oracle中，哈希桶的链表更短，这样，在哈希桶链表中定位和访问特定对象会非常快速。至于Library Cache中哈希桶的数目，系统会根据Shared Pool的大小自动算出

我们从一个用户请求开始讲，ORACLE的完整的工作机制是怎样的，首先一个用户进程发出一个连接请求，如果使用的是主机命名或者是本地服务命中的主机名使用的是机器名(非IP地址)，那么这个请求都会通过DNS服务器或HOST文件的服务名解析然后传送到ORACLE监听进程，监听进程接收到用户请求后会采取两种方式来处理这个用户请求，下面我们分专用服务器和共享服务器分别采用这两种方式时的情况来讲： 专用服务器模式下： 一种方式是监听进程接收到用户进程请求后，产生一个新的专用服务器进程，并且将对用户进程的所有控制信息传给此服务器进程，也就是说新建的服务器进程继承了监听进程的信息，然后服务器进程给用户进程发一个RESEND包，通知用户进程可以开始给它发信息了，用户进程给这个新建的服务器进程发一个CONNECT包，服务器进程再以ACCEPT包回应用户进程，致此，用户进程正式与服务器进程确定连接。我们把这种连接叫做HAND-OFF连接，也叫转换连接。 另一种方式是监听进程接收到用户进程的请求后产生一个新的专用服务器进程，这个服务器进程选用一个TCP/IP端口来控制与用户进程的交互，然后将此信息回传给监听进程，监听进程再将此信息传给用户进程，用户进程使用这个端口给服务器进程发送一个CONNECT包，服务器进程再给用户进程发送一个ACCEPT包，致此，用户进程可以正式向服务器进程发送信息了

前言 最近hyddd一直看Oracle的资料，今天特地总结一下这段时间了解到的 关于Oracle性能优化的下手点 。 一 . 数据库优化的方向 1.程序设计（这点最重要，如果程序本身设计有问题，再怎么进行下面的优化都是徒劳的。） 2.操作系统优化 3.硬件优化 4.数据库优化 5.SQL语句优化 二 . 硬件优化 这里涉及到的硬件主要有：硬盘，内存。 1.硬盘的读写速度：建议增加硬盘的数量，从而增加每秒的并发操作。 2.内存大小。 三 . 数据库优化 以上是Oracle 9i的体系结构，关于Oracle数据库的优化，很大程度上图有关。 1. 根据数据库的使用方式得出合理的优化策略 （1）OLTP：连机事务处理。 需要实时处理大量请求，而每次处请求的数据量都是很小的。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。 性能好坏的重要指标：响应时间与请求处理并发数。 （2）OLAP：联机分析处理。 可以简单地理解为在海量数据中得出统计/综合信息，是数据仓库的主要应用。做OLAP应用的数据库，数据量通常量非常大。和OLTP不同，OLAP应用的并发处理量是很低的，所以基本不用考虑并发问题。而在处理数据量方面，OLAP每次操作所需要处理的数据量通常都是非常大的，这点也和OLTP相反。 性能好坏的重要指标：查询大量数据的速度。

文章目录 MySQL 执行计划 Oracle 执行计划 SQL Server 执行计划 PostgreSQL 执行计划 SQLite 执行计划 执行计划（execution plan，也叫查询计划或者解释计划）是数据库执行 SQL 语句的具体步骤 ，例如通过索引还是全表扫描访问表中的数据，连接查询的实现方式和连接的顺序等。如果 SQL 语句性能不够理想，我们首先应该查看它的执行计划。本文主要介绍如何在各种数据库中获取和理解执行计划，并给出进一步深入分析的参考文档。 现在许多管理和开发工具都提供了查看图形化执行计划的功能，例如 MySQL Workbench、Oracle SQL Developer、SQL Server Management Studio、DBeaver 等；不过我们不打算使用这类工具，而是介绍利用数据库提供的命令查看执行计划。 我们先给出在各种数据库中查看执行计划的一个简单汇总： 数据库 执行计划 MySQL EXPLAIN sql_statement; Oracle EXPLAIN PLAN FOR sql_statement; SELECT * FROM TABLE(DBMS_XPLAN.display); SQL Server SET STATISTICS PROFILE ON; sql_statement; SET STATISTICS PROFILE

SQL语句在数据库中处理过程是怎样的呢？执行顺序呢？在回答这个问题前，我们先来回顾一下：在ORACLE数据库系统架构下，SQL语句由用户进程产生，然后传到相对应的服务端进程，之后由服务器进程执行该SQL语句，如果是SELECT语句，服务器进程还需要将执行结果回传给用户进程。 SQL语句的执行过程一般如下： 解析（PARSE）—— 绑定（BIND）——执行（EXECUTE）——提取（FETCH 只有SELECT才需要这步） 解析 服务器进程接收到一个SQL语句时，首先要将其转换成执行这个SQL语句的最有效步骤，这些步骤被称为执行计划。 Step 1：检查共享池中是否有之前解析相同的SQL语句后所存储的SQL文本、解析树和执行计划。如果能从共享池的缓存库中找到之前解析过生成的执行计划，则SQL语句则不需要再次解析，便可以直接由库缓存得到之前所产生的执行计划，从而直接跳到绑定或执行阶段，这种解析称作软解析。 但是如果在共享池的库缓存中找不到对应的执行计划，则必须继续解析SQL、生成执行计划，这种解析称作硬解析 在缓存池解析过的SQL，会有一个对应的哈希值与之对应，你可以通过V$SQL视图来查询，请看下面一个例子： SQL>SELECT * FROM SCOTT.DEPT WHERE DEPTNO =10; SQL>SELECT * FROM SCOTT.DEPT WHERE DEPTNO

目录 一、获取执行计划的方法 (1) explain plan for (2) set autotrace on (3) statistics_level=all (4) dbms_xplan.display_cursor获取 (5) 事件10046 trace跟踪 (6) awrsqrpt.sql 二、解释经典执行计划的方法 【单独型】 【联合型关联型】 【联合型非关联型】 最近拜读《收获，不止SQL优化》一书，并做了笔记，方便自己以后回顾，同时放在网上或许也有益于别人 一、获取执行计划的方法 (1) explain plan for 步骤： 1：explain plan for 你的SQL; 2：select * from table (dbms_xplan. display()) ; 优点：不需要真的执行，快捷方便 缺点：没有输出运行时的统计信息(逻辑读、递归调用，物理读)，因为没有真正执行，所以不能看到执行了多少行、表被访问了多少次等等 (2) set autotrace on sqlplus登录： 用户名/密码@主机名称:1521/数据库名 步骤： 1：set sutoatrace on 2：在此次执行你的sql; 优点：可以看到运行时的统计信息(逻辑读、递归调用，物理读) 缺点：不能看到表被访问了多少次，也需要等sql执行完成才能看 (3) statistics

博文结构 Oracle数据库体系结构 Oracle物理结构 Oracle逻辑结构 Oracle内存结构 Oracle进程结构 创建用户并授权 一.oracle体系结构概述 Orcale体系结构 Oracle体系结构包含一系列组件。 如图显示了Oracle体系结构中的主要组件，包括实例、用户进程、服务器进程、数据文件及其他文件，如参数文件、口令文件 和归档日志文件等. 从图中可以看出,实例和数据库是Oracle数据库体系结构的核心组成部分，也是最重要的 两个概念, DBA -个很重要的工作就是维护实例和数据库本身的正常工作。 1.实例 Oracle实例是后台进程和内存结构的集合，必须启动实例才能访问数据库中的数据。Oracle 实 例启动时，将分配- -个系统全局区(SGA) 并启动一系列Oracle后台进程。Oracle 实例有两种类型: 单进程实例和多进程实例。单进程Oracle实例使用一个进程执行Oracle的全部操作,在单进程环境下 的Oracle实例仅允许- -个用户可存取。多进程Oracle实例(又称多用户Oracle)使用多个进程来执行 Oracle的不同部分，对于每个连接的用户都有一个进程。 2.数据库 数据库是数据的集合，物理上是指存储数据库信息的一组操作系统文件，每个数据库有-个逻 辑结构和一个物理结构。物理结构是指构成数据库的一组操作系统文件