yaolinxueke写给自己

解决/减少share pool的ORA-4031错误的方法：1、alter system flush shared_pool;      ----治标不治本2、共享SQL减少硬解析（绑定变量、cursor_sharing）  3、select * from v$db_object_cache where sharable_mem > 10000and (type =

研究了几天shared pool,没想到忽然就撞到问题上来了.作为一个案例写出来给大家参考一下吧.问题起因是公司做短信群发,就是那个18万买的4000字的短信小说(嘘,小声点,我也没看过...).群发的时候每隔一段时间就会发生一次消息队列拥堵的情况在数据库内部实际上是向一个数据表中记录发送日志.我们介入来检查数据库的问题,在一个拥堵时段我开始诊断:

library cache我上图中，oracle去5号链上遍历，会把5号链锁住（Library Cache Latch），这样的话如果咱们吧shared_pool设的很大，library cache中缓存的sql/执行计划就会很多，链就会很长，那么遍历的时间就长，锁住链的时间就会很长。来~~~咱们捋一下sql执行的过程：说明：我们说的链也可叫bucket

两个概念：1、chain    2、chunkSHARED POOL--------------------------------------------------------------------------------------------------------------------------------------

一、shared_poolshare pool分为两个部分1、library cache（库高速缓存）： 加速解析 减少语句重解析，曾经使用的SQL，PL/SQL 的语句和执行计划2、data dictionary cache 又叫rowcache（数据字典高速缓存）：加速sql的解析，使用过的字典 就会缓存在这里 再次使用这个字典就直接从内存获取，这些统计的信息在 v$rowcach

首先创建一个表，用于存放整理过的数据：SQL> create table t1 as select sql_text from v$sqlarea; Table created给表t1增加一个字段：SQL> alter table t1 add sql_text_wo_constants varchar2(1000); Table altered

1、执行：select * from t1 where id=1   oracle通过计算得出这行数据在1号文件24号块中2、oracle 通过计算知道这个块在2号chain上，去找，发现2号链上没有这个块3、发生物理IO，把1号文件24号块调去如内存，并把buffer header挂到2号CBC链上，在内存中取出块中的对应数据返回给用户4、这时我再执行：select * from t