1-shared pool之SQL执行过程剖析

一、SQL解析执行主要包括三个步骤:

          1、客户端输入SQL语句;

          2、SQL语句通过网络到达数据库实例;

          3、server process(前台进程)接收SQL语句:

                1)解析:解析主要做两件事情,SQL语法、权限、访问对象是否存在等;SQL该如何执行---找个最优的执行方案生成执行计划

                2)执行:根据生成的执行计划,执行SQL

                其中,SQL语句和执行计划都需要缓存,即shared pool

二、基本概念

          1、Logic read:server process从buffer cache中读取数据返回给用户。

          2、Physics read:server process先把dbf(数据库文件)数据从磁盘读到buffer cache中,然后再从buffer cache中读取数据返回给用户。

          3、命中率:指的是,对于所有数据块的读取,buffer cache读的块数占buffer cache读和dbf读总块数的比率。即L/(L+P)

          在这里,命中率低一定有问题,命中率高的话,不一定没问题。例如:一定时间逻辑读10万次,物理读1万。虽然命中率很高,但是物理读也很多。那么,对于数据块的读取,需要关注每秒的物理读次数,即查看IO是否繁忙,可以通过以下命令:

linux:vmstat 1 10      iostat 1 10    sar 1 10  mpstat(查看多处理器状况)

三、进程之间的协同工作

        考虑到最复杂情况,以修改和物理读操作为例:

          1、server process将dbf读到buffer cache中进行修改;

          2、server process对数据的修改产生日志(server process产生),日志将被server process写到log buffer(内存空间)中;

          3、commit之后,后台进程LGWR将日志实时写到log file中;

          4、在一定的触发条件下,DBWR将脏的数据块从buffer cache写到磁盘中。

          整个过程,server process不负责写(datafile)而只负责读(buffer cache)的原因:server process直接为用户服务,接收到用户的SQL之后,首先对SQL进行解析,然后执行SQL,最后获取数据将结果返回给用户。如果server process慢的话,用户会感到数据库很慢。所以,server process并不关心什么时候将修改的数据写到磁盘(交由后台进程DBWR、LGWR来完成)。

数据库主要进程的作用:

      CKPT:周期性运行,比较轻松,将数据库当前的状态信息写到control file和datafile header中,即更新控制文件和数据文件头部。

      SMON:负责对数据库实例(SGA)内部进行清理和维护。例如:共享池的碎片整理

      PMON:负责对数据库实例外部(server process)进行维护和清理。例如:客户端网络断掉,server process一直被用户启用着,PMON会周期性的启动,发现server process的客户端已经断掉,PMON会清理该server process:关掉server process的进程,清理所对应PGA的内存空间。

      ARCH:归档log file

缓冲区的主要状态:

      干净、未使用、脏、连接(pin)---server process读写数据块的瞬间

      如果所有的buffer都被使用,优先使用干净的buffer(datafile中有相同的block);如果所有的buffer都是脏的,则会触发DBWR将脏的buffer写到磁盘,buffer变为干净的,能够被重用。

      有些人可能会问:数据从磁盘被读到buffer cache中,在内存中是依据什么原则,如何组织的呢?DBWR写脏数据块到磁盘,又是依据什么规则呢?buffer cache使用了LRU chain和checkpoint queue来保证数据块读的命中率和脏数据块是如何写入磁盘的。在后续《buffer_cache内存组织结构剖析》和《检查点队列》章节中有详细介绍。

四、SQL解析类型---硬解析与软解析

          1、shared pool的主要作用:缓存SQL语句和SQL语句的执行计划。它是由三块区域组成:free、library cache、row cache(dictionary cache)。

                    1)library cache:缓存SQL语句以及SQL语句的执行计划

                    2)dictionary cache:oracle数据库自身的信息。例如,数据库中有多少表、多少用户、表有多少列、列名是什么、列的数据类型、每个表多大等信息。其中,所有的数据字典信息可在官方文档中查找books--->reference--->dba_tables

          2、查看shared pool大小:select a.pool,sum(a.bytes) as sum_bytes from v$sgastat a where a.pool_name='shared pool' group by a.pool;

查看shared pool大小

          3、SQL解析(hard parse,soft parse):

          硬解析主要由四个阶段完成:

                  1)server process判断SQL语句语法是否有错误

                  2)查看SQL语句所涉及的对象是否存在

                  3)执行SQL的用户对对象是否有相应权限(系统权限、对象全向)

                  4)生成执行计划,即在N个执行方案中挑选出最优的一个方案作为这条SQL的执行计划---最消耗资源

          软解析:不包含第四步,仅仅做常规判断

          那么,什么时候发生硬解析呢?server process拿着SQL语句在library cache中找,如果这条SQL语句在library cache中没有,说明该语句和它的执行计划在library cache中没有,此时发生硬解析,如果有则发生软解析。无论是硬解析还是软解析,解析过程中用到很多数据库自身信息(权限信息、对象信息、对象统计信息---字典信息),即对SQL语句进行解析的时候,都要频繁的访问数据字典信息。所以,row cache放在shared pool和library cache在一起。

          软硬解析的具体情况:

1-shared pool之SQL执行过程剖析_第1张图片
查看解析次数


            本节主要以SQL的执行过程为线索,初步认识了shared pool的相关知识。下一节主要说明shared pool内存块是如何组织的。

你可能感兴趣的:(1-shared pool之SQL执行过程剖析)