一、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;
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在一起。
软硬解析的具体情况：
本节主要以SQL的执行过程为线索，初步认识了shared pool的相关知识。下一节主要说明shared pool内存块是如何组织的。
