Oracle内存组件与进程的相关知识总结
Oracle数据库服务器由两大部分组成：实例和数据库文件（物理文件）。实例就是指内存部分，其中包含两个部分：内存组件和进程。我们必须通过实例读取物理文件中存放的数据。同时，实例中还缓存了曾经使用过的数据，从而使得我们在下次再次访问相同的数据时，能够直接读取内存的即可，而不需要再发生物理I/O。
用户与Oracle数据库服务器建立连接：
Oracle提供了两种解决方式：专用连接和共享连接。
- 专用连接
- 使用者在本地客户端建立一个客户端进程与远程Oracle服务器进程建立连接，用户进程通过发送不同的命令，来请求服务器的响应，服务器进程代替用户进程去执行具体的命令和返回结果。用户进程不能直接访问数据库的。在专用连接模式下，用户进程与服务器进程一一对应，用户进程一旦终止，服务器进程也随之终止。
- 共享连接
- 共享进程中，在服务器端建立多个服务器端进程，一个用户进程可以对应多个服务器进程，但是共享连接模式比较少见。
当用户成功的建立连接后，会在服务器端生成对应的服务器进程，同时创建一个会话（Session）。所谓Session就是一段内存空间。gauge基本规划表记录了用户采用了什么应用程序连接到数据库、客户端机器的名称等信息。
理解Shared Pool：
Oracle对SQL语句进行了概括和抽象，将SQL语句提炼为两部分。一部分时SQL语句的静态部分，也就是SQL语句本身的关键词、所涉及的表名称以及表的列名等。另一部分是SQL语句的动态部分，也就是SQL语句中的字面值，如Select * from mytb where name = 'Peter'中的Peter就是字面值，是经常动态变化的。但对于SQL语句解析来说，动态部分比静态部分的解析所用的开销要小的多。
Oracle会将用户提交来的SQL语句都缓存在内存中。每次处理新的一条SQL语句时，都会先在内存中查看是否有相同的SQL语句。如果相同则可以减少最重要的解析工作（也就是生成执行计划），从而节省了大量的CPU资源；反之，如果没有找到相同的SQL语句，则必须重新从头到尾进行完整的解析。这部分存放SQL语句的内存就叫做共享池（Shared Pool）。当然，share Pool 中不仅仅是SQL语句，还包括执行计划，PL/SQL代码，PL/SQL程序的机器码，管理shared pool 的内存结构、控制信息等内容。
在一个很高的层次上来看，shared pool 可以分为库缓存（Library cache）和数据字典缓存（Dictionary cache）。Library cache 存放了最近执行的SQL语句、存储过程、函数、解析数以及执行计划等。而dictionary cache则存放了在执行SQL语句过程中所参照的数据字典的信息，包括SQL语句所涉及的表名、表的列、权限信息等。对于dictionary cache来说，Oracle倾向于将它们一直缓存在shared pool中，不会将它们唤出内存，因此我们不用对它们进行过多的关注。而Library cache则是shared pool 里最重要的部分，也是在shared pool 中进进出出最活跃的部分。
解析SQL语句的过程：
为了将用户写的SQL文本转化为Oracle认识的且可执行的语句，这个过程就叫做解析过程。解析分为硬解析和软解析。一条SQL语句在第一次被执行时必须进行硬解析。
当客户端发出一条SQL语句（或是一个存储过程、一个匿名的PL/SQL块）进入shared pool 时，Oracle首先将SQL文本转换为ASCII值，然后根据hash函数计算其对应的hash值（hash value）。根据计算出的hash值到Library cache 中找到对应的bucket（具体物理上shared pool 原理，可以google一下)，然后比较bucket里是否存在该SQL语句。
如果不存在，则需要进行硬解析。
硬解析：
- 对SQL语句进行文法检查、看是否有文法错误。
- 到数据字典里校验SQL语句涉及的对象和列是否都存在。如果不存在，则退出解析过程。这个过程会加载dictionary cache。
- 将对象进行名称转换。比如将同名词翻译成实际的对象等。
- 检查发出SQL语句的用户是否具有访问SQL语句里所引用的对象的权限。如果没有权限，则退出。
- 通过优化器创建一个最有的执行计划。这个过程涉及大量的数学运算，是最消耗CPU资源的。
- 将该游标所产生的执行计划、SQL文本等装载进Library cache 的heap中。
如果在bucket中找到了该SQL语句，则说明该SQL语句以前运行过，于是进行软解析。软解析是相对于硬解析而言的，如果解析过程中，可以从硬解析的步骤中去掉一个或多个的话，这样的解析就是软解析。软解析分为以下三周类型：
- 某个Session发出的SQL语句与library cache中的其他Session发出的SQL语句一致。则可以去掉硬解析的5和6。
- 某个Session发出的SQL语句与该Session之前曾经发出过得SQL语句一致，则可以去掉硬解析的2,3,5,6步骤。
- 第三种情况是当设置了初始化参数session_cached_cursors时，当某个session第三次执行相同的SQL语句，则会把该SQL语句的游标信息转移到该session的PGA里。这样，该session以后再执行相同的SQL语句时，会直接从PGA里取出执行计划，从而跳出硬解析的所有步骤，这种情况下，是最高效的解析方式，但是会消耗很大内存。
