11 SQL语句解析类型_硬解析_软解析

Shared pool

shared pool 一般有问题 70-80% 是oracle 补丁没有打

shared pool 是一块内存池，最主要的作用：缓存sql语句、sql语句的执行计划

sql 执行：

解析、执行、获取数据

parse、exec、fetch

shared pool 是一块内存池，里边又被分成了很多小的区块，每个块有他们的作用

主要研究3个块:

1、free （空闲）

2、library cache（库缓存，缓存sql语句以及sql所对应的执行计划）

3、row cache（字典缓存，数据字典存放着Oracle数据库自身的信息。库里有多少表，多少用户，多少个列，列的名字，列的数据类型，每个表多大等等都属于数据库自身信息。管理数据库的时候要经常用到数据字典信息）

建立表：

SQL> create table t1 as select * from dba_objects;

表已创建。

查数据中是否有t1这张表：

SQL> desc dba_tables;（这个就是数据字典表，存放了数据字典信息，存放了Oracle 系统自身的信息）

SQL> select table_name,OWNER from dba_tables where table_name like 'T1%';

TABLE_NAME OWNER

------------------------------ ------------------------------

T1 SYS

查看Oracle 有哪些数据字典，可以从官方文档里面 选book--&gt reference --&gt2.Static Data Dictionary Views:..

查看shared pool

SQL> select * from v$sgastat a where a.NAME ='library cache';

SQL> select * from v$sgastat a where a.pool = 'shared pool' and a.NAME = 'free memory';

SQL> select * from v$sgastat a where a.NAME = 'row cache';

#########

sql 语句解析

硬解析、软解析、软软解析（不解析，和参数 session .. 有关系）

一个sql 语句，进入到数据库后，server process 会拿着sql语句到shared pool中的library cache 里边去找 ，看下sql语句以前是否有执行过。也就是在library cache 里面看有没有这条sql语句以及sql语句所对应的执行计划。

如果有，还是需要解析，进行软解析 --&gtsoft parse

如果没有，Oracle 会进行硬解析 --&gthard parse

硬解析：

1、server process 判断sql语句语法是否有错误

2、查看sql语句里边所涉及的对象是否存在，访问某个表，这个表是否存在

3、执行这条sql语句的用户，对这个表，对相关的对象是否有权限（有没有系统权限和对象权限）

都满足的前提下：

4、生成具体的执行计划（一条sql 有n种执行方案，多种执行方案都可以完成这条sql语句。有的执行方案消耗资源大 速度慢，有的消耗资源小 速度快）

Oracle 会在这条sql 语句所对应的n个执行方案中，挑出一个最优的执行方案，然后作为这条sql语句的执行计划 --&gt硬解析中最重要，最耗资源的一步，几乎消耗了Oracle 执行这条sql语句 所消耗资源的全部，消耗70%以上。

5、执行

软解析：

1、server process 判断sql语句语法是否有错误

2、查看sql语句里边所涉及的对象是否存在，访问某个表，这个表是否存在

3、执行这条sql语句的用户，对这个表，对相关的对象是否有权限（有没有系统权限和对象权限）

都满足的前提下：

...（省了一步 硬解析中 最消耗资源的一步，寻找最优的执行方案）

执行

PS：无论是软解析、硬解析，解析过程中都用到好多数据库自身信息，如权限信息、对象信息等--&gt字典信息

频繁访问字典信息--&gt shared pool

软硬解析的具体情况：

SQL> select name,value from v$sysstat where name like 'parse%';

NAME VALUE

---------------------------------------------------------------- ----------

parse time cpu 1312 #解析话费的cpu

parse time elapsed 3704 #解析花费的时间

parse count (total) 89982

parse count (hard) 8092

parse count (failures) 520

parse count (describe) 31

已选择6行。

############

SQL> select count(*) from x$ksmsp;

COUNT(*)

----------

40362

SQL> select count(*) from dba_objects;

COUNT(*)

----------

72460

SQL> select count(*) from x$ksmsp;

COUNT(*)

----------

40362

SQL> alter system flush shared_pool;

系统已更改。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29000429/viewspace-1060628/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29000429/viewspace-1060628/