oracle 好书 05 ( 内存组件与 oracle 进程 )

实例 instance: 包括内存组件和进程.

必须通过实例访问数据库.

用户与数据库服务器建立连接

Oracle 提供了两种连接方式: 专用连接和共享连接( dedicate, share )

一般使用专用连接, 用户在客户端启动了一个应用程序, 比如 SQL*PLUS, 于是就在可与段本地启动了一个用户进程, 与 oracle服务器建立连接后, 就会在服务器端生成一个对应的服务器进程, 该进程作为用户进程的代理进程, 也叫影子进程, 从而代替客户端去执行各种命令并返回结果.也就是说, 用户在客户端输入的各种命令, 都是通过位于客户端的用户进程发送到服务器端对应的服务器进程, 并由服务器进程代替用户进程去执行具体的命令及返回结果. 在专用连接模式下, 用户进程与服务器进程是一一对应, 用户进程一旦终止, 服务器进程也随之终止.

session 和连接的区别:

连接: 指物理概念, 从客户端到服务器端的通信通道. 分为以下 3 种:

本地登录: 从数据库服务器登录服务器, 内部通信机制.
C/S模式: 客户机和服务器在同一个局域网内, 借助oracle 网络组件, 通过网络设备和服务器建立连接.
B/S模式: 浏览器->应用服务器->数据库服务器.( 前面一层是 http, 后面一层是网络连接, tcp/ip )

深入 Shared Pool

oracle 在准备执行用户提交的 SQL 语句时, oracle 首先需要解析该语句, 而SQL语句分为两部分, 动态和静态语句, 其中静态语句难以解析, 动态语句是指, where name = ‘value’ 这个 value 就是需要动态的, 而剩下所有的都属于静态的，所以每次 oracle 会先将 SQL 语句放在内存中, 查看内存中是否有一样的静态语句, 如果有, 只是动态语句不一样, 就不需要再花大量的时间进行解析, 直接执行. 这个被放置SQL语句的内存就是 shared pool. 当然还有 pl/sql 执行计划等等也在该内存中.

如果 sql 语句使用绑定变量, 那么在 shared pool 中查找到相同的SQL语句概率就打,例如 select c1 from t1 where c2 = 1;

select c1 from t1 where c2 = 2; 如果把 1, 2 换成变量, 例如 v1, 写成 select c1 from t1 where c2 = :v1;

shared pool 内存结构

shared pool: 分为 library cache, dictionary cache

library cache: 存放了最近执行sql 语句, 存储过程, 函数, 解析树以及执行计划.

dictionary cache: 存放了在执行SQL语句过程中, 所参照的数据字典, 包括SQL语所涉及的表名, 列名, 权限等. 这里的信息都是以数据行形式存储, 所以又叫 row cache.

内存情况: chunk 是 shared pool 中最小的内存单位, 它有时候存储 library cache 中的内容, 有时候存储 dictionary cache中的内容.

可以通过 x$ksmps 查看当前 shared pool 情况, 每条记录都表示一个 chunk.

chunk 状态:

free: 不包含有效对象, 可以不受限制的被分配
recr: recreatable, 包含的对象可以在需要的时候被临时移走, 并在需要时重建.
freeabl: 包含对象都是曾经被 session 用过, 并且随后会被完全或部分释放.
perm: permanent, 永久对象.

在 shared pool 里，可用的chunk(free类型) 会被串起来称为可用链表( free list), 也叫 bucket, 当某个进程需要 shared pool 中的一个 chunk时, 则该进程首先到符合所需空间大小的 bucket 上扫描, 找到一个尺寸最合适的 chunk, 扫描会持续到 bucket 的最末端, 知道找到完全符合尺寸的 chunk . 如果找到的chunk比需要的尺寸大, 则该 chunk 就会被分成两个 chunk, 一个用来存放数据, 另一个则成为free类型的 chunk, 并挂到当前该 bucket上. 如果全部 free 都没有了, 则扫描已经使用过的 recreatable 类型的 chunk 链表, 释放一部分 chunck来使用. 如果还是找不到, 就会发出 ORA-4031的错误消息. 当出现4031错误时, 我们查询 v$sgastat 里可用的 shared pool空间时, 可能会发现 name 为 “free memory”的可用内存还足够大, 但是为何会报4031错呢, 事实上, 在 oracle发出 4031错误之前, 已经释放了不少的recreatable类型的chunk,因此会产生不少可用内存, 但是这些可用的chunk,没有一个chunk能够以连续的物理内存提供所需的内存空间,所以发生了4031错误.

对于非常大的对象, 我们可以让 oracle为它们单独从保留区域分配空间, 而不是从可用的chunk链表分配空间, shared_pool_reserved_size决定这部分空间大小, 默认为 shared_pool_size 的 5%, 这块保留区与正常 chunk 管理是完全分开的. 这块保留区的使用情况 v$shared_pool_reserved.

当用户提交SQL或PL/SQL 到 shared pool 以后, 会在library cache中生成一个可执行对象, 叫做游标( cursor), 注意: 这个游标和传统意义的游标不一样,每个游标至少由两个对象组成, 父游标( 包含名称及提交用户信息，从 v$sqlarea视图里都是父游标的信息), 子游标

当一条SQL语句进入 library cache 时, 先将 SQL 文本转化为对应的 ASCII数值, 然后对这些ASCII进行 hash函数运算, 得到 hash bucket号码, 从而该SQL语句被分配到该号得 hash bucket中.

当某个进程需要处理某个对象时, 比如处理一条新进入的SQL语句时，它会对该SQL语句应用hash函数算法, 这样能够知道该对象的 hash bucket 号码, 然后进入该 hash bucket 进行扫描以确定是否存在相同的SQL语句. 如果不存在或以前存在后来又交换出内存, 就再次装载 reload.

可以通过查询 v$db_object_cache来显示 library cache 中有哪些对象被缓存, 一级对象的大小尺寸.

dictionary cache 专门用来存放 SYS schema 所拥有的对象的内存区域. 为了更快的解析 SQL 语句速度, 不用过多担心.

解析SQL语句过程

硬解析和软解析 ( 一条SQL语句在第一次被执行时必须进行硬解析 )

这里的 shared pool latch, 是锁.

设置 shared pool

“不要太大, 也不要太小”的原则, 然后, 让系统运行一段事件, 监控 shared pool 使用情况, 最后给出一个比较合理的值. 一般 shared pool 是 SGA 的 10%, 但是不要超过 1GB, 只要将 statistics_level 设置为typical( 默认) 或 all, 就能启动对 shared pool的建议功能, 如果设置为 basic, 则关闭建议功能.