oracle学习笔记 sharedpool内存块组成结构及4031错误产生原因分析



oracle学习笔记

sharedpool内存块组成结构及4031错误产生原因分析

sharedpool有三个空间
1、free
2、librarycache
它们容易出问题
3、rowcache
它不容易出问题。

我们只能总体上设sharedpool的大小，
不能设librarycache和rowcache分别占多大，它们的大小我们控制不了，
oracle会根据实际的使用情况，自动设置这两个的大小。

一）free空间内存的组成和组织管理

free空间不是一个大的控制内存块，
它由很多被分为不同大小的小内存块组成，
并使用链结构来分类管理。
它们按大小不同串在不同的链上
链英文chain
块英文chunk
即内存块都被挂在链上
在free空间挂的都是free的空闲内存块

每个链所挂的内存块的大小是不一样的。
从小到大形成一定的阶梯
如一个链上挂的是4K的内存块
一个链挂8k的，
一个链挂12k的。
4K链上的内存块大小就大于等于4K而小于8K
8K链上的内存块大小就大于等于8K而小于12K

解析一个sql语句时，
数据库会根据解析的sql语句，和sql语句的执行计划
计算出需要占用的实际空间。
这时我们需要一个空闲块，
如需要一个10K的空间
我们就在相应的8K的链上找10K的块
找到一个11K的大小合适，
但只需10K，
就把11K的分成两个 一个10K、一个1K
把sql语句和执行计划写到这个10K的块中，
并把这个块，放到librarycache中去。
剩下了一个1K的空闲内存块，把它挂在free空间的1K的链上。

硬解析的时候会发生刚才说的情况，
软解析不需要从free空间找chunk

二）ora-4031错误的产生

硬解析也产生了一个问题，
产生了一些小chunk，即产生了碎片，如上面例子中产生的1K的空闲块

如果数据库系统里面有大量的硬解析，
会发现虽然free里面还有很多空间，
但是所有的空间都是小的，不能使用。
如一个sql语句发生硬解析，去找free chunk
虽然还有200M的free，
但所有chunk都不够大，
这时候sql语句硬解析就会失败。
失败以后就会报一个很经典的oracle错误  
叫ora-4031错误

4031错误的产生原因是
1、大量的硬解析
2、大量的硬解析产生大量的小碎片以后突然又来了一些比较长的sql语句，
这个大sql语句，突然需要个大空间，
这时候没有块能提供这么大的空间，就容易产生4031错误。

三）链

oracle里面有很重要的一个概念chain即链
链有几个特点，
1、它把我们需要组织的内存块串起来，
它们功能或者说特性类似
2、链可以遍历
因为链有头有尾，
所有的内存块都是挂到链上，
我们可以找到第一个块看看，再找第二个块看看，可以从头开始找到尾
就是可以遍历并在链上找到所有的块

oracle数据库内存结构里面
一个重要的特征就是使用了大量的链
并且在使用时用锁latch来保护链

四）librarycache里存块的组织

librarycache里面也是用链来组织和管理chunk
链底下挂着chunk
这些chunk和free的chunk不一样
它不是空的，里面写有内容，内容是sql语句和执行计划plan
并且不是以大小来串起来的
而是以chunk所对应的sql语句运算以后得到的数字
挂到相应的链上
不管如何都是为了方便我们查找和管理

块在向链上挂时
首先把sql语句所有的字母转换成ASCII码值，
然后对这一堆数字进行一些运算，得到一个数字
这个数字就对应于链的编号。

如得到一个数字5，
我们就把这个sql语句及执行计划挂到5号链上。

再次执行这条sql语句时
oracle同样对这条sql语句求ASCII码值
并进行一些运算得到链的编号5
5号链挂了好多chunk，oracle就会锁住这个链
在链上进行遍历
最后会找到了这个chunk
就不会发生硬解析了，发生的是软解析

rowcache里面也是以链的方式来组织管理的
 
内存块存储有链，有链就有锁latch，
前面内容对应有
sharedpool latch，librarycache latch、rowcache latch

五）监视内存块变化

1)库中有一个视图 x$ksmsp,我们叫x表
sharedpool里面的每一个chunk，在这个表里面都有一行信息。
select count(*) from x$ksmsp;
得到的数字就是sharedpool里面的chunk总数。

执行这条语句
SQL> select count(*) from x$ksmsp;

  COUNT(*)
----------
     11648

数据库系统目前有11648个chunk

再执行一条以前从来没有执行过的语句
用来发生硬解析，它会从free上摘下chunk来放到librarycache上
SQL> select count(*) from dba_indexes;

  COUNT(*)
----------
      2344
语句执行后很有可能产生了碎片。

再看一下chunk数
SQL> select count(*) from x$ksmsp;

  COUNT(*)
----------
     11676
由11648变为了11676
说明有硬解析发生，因为chunk的数量增加了

将查询x$ksmsp表的语句连续执行
比如十分钟以内执行一次过十分钟再执行一次
得到的两个数字一减
我们可以算出在十分钟以内产生的chunk的数量。

正常情况下随着系统越来越稳定，产生的chunk的数量越来越少，
如果你发现十分钟以内产生了大量的chunk，
很可能这时候系统里面产生了大量的硬解析。

这是一个小技巧，
但是我们一般不用它来判断软硬解析的数量。

2)我们都用前面使用过的一条语句

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

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse time cpu                                                           53
parse time elapsed                                                      613
parse count (total)                                                    4255
parse count (hard)                                                      888
parse count (failures)                                                    0

直接看
parse count (hard)的值的变化，
就可以知道当前数据库系统自启动以来已经发生了多少硬解析
用它来判断一个时间段发生的硬解析的数量，更好一些。

3)再看一下
alter system flush shared_pool;
这个命令很危险，不能任意执行，但偶尔也可以执行

我们叫它flush命令
它会将librarycache和rowcache所有的内容全部清空
并重置和重新初始化free中的所有块和链。
这时候再去执行任何sql语句的时候都会发生硬解析，
所以这条语句我们轻易不要去执行

但是它执行完了以后4031错误马上就会减少
因为它一旦执行以后librarycache被清空
chunk会全部回到free里面去
这时free里会有大量的大大小小的chunk
这时候4031错误就不容易再出现了。

但这个命令执行完了以后，意味着接下来会产生大量的硬解析。
这个命令不是解决4031错误根本的办法
它是治标不治本的一个命令。

这节课讲了sharedpool里面的内存结构，
什么叫chain 什么叫 chunk，
以及讲了一个flush命令。
同时我们也知道，
硬解析大量存在的时候，会产生ora-4031错误。

我们怎么去减少硬解析呢，
系统有没有条件减少硬解析，
有没有这种可能，
放到下一章节去讲！

 2016年8月5日
                                                                            文字：韵筝