首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >简单分析shared pool(一) (r3笔记46天)

简单分析shared pool(一) (r3笔记46天)

作者头像
jeanron100
发布于 2018-03-14 10:05:28
发布于 2018-03-14 10:05:28
6820
举报

oracle中的shared pool很重要,但是感觉知之甚少。今天想在原来的认识上能够有一点更深入的了解。 简单做了一个总结。 首先是转储一下shared pool共享内存的内容。 SQL> alter session set events 'immediate trace name heapdump level 2'; Session altered. 这个步骤会得到一个trace文件。简单的换算一下,就得到了trace文件的大体信息。

SQL> select sid from v$mystat where rownum<2; SID ---------- 24 SQL> select sid,serial# ,paddr from v$session where sid=24; SID SERIAL# PADDR ---------- ---------- ---------------- 24 83 00000000727B03B0 SQL> select spid from v$process where addr='00000000727B03B0'; SPID ------------------------ 18155 SQL> host 简单验证一下,对应的process是否存在。 [ora11g@rac1 ~]$ ps -ef|grep 18155 ora11g 18155 18106 0 06:00 ? 00:00:02 oracleTEST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) ora11g 19326 19167 0 06:21 pts/0 00:00:00 grep 18155 在trace文件目录下查看日志文件是否存在。

[ora11g@rac1 trace]$ ls -l *18155*.trc -rw-r----- 1 ora11g dba 6900360 Nov 4 06:11 TEST01_ora_18155.trc 对于shared pool来说,存储单位是chunk,多个chunk组成一个链表,也叫做bucket. 每个bucket都对chunk的大小都有一定的范围,是一个连续的值,没有交叉。 在10g,11g中都设置了255个bucket。 简单通过trace文件来看一下。 [ora11g@rac1 trace]$ grep Bucket *18155*.trc Bucket 0 size=32 Bucket 1 size=40 Bucket 2 size=48 Bucket 3 size=56 Bucket 4 size=64 Bucket 5 size=72 ... Bucket 250 size=12352 Bucket 251 size=12360 Bucket 252 size=16408 Bucket 253 size=32792 Bucket 254 size=65560 可能对于bucket的大小没有一个直观的感受,可以生成一个图来看看就很清楚了。

随着bucket的增长,对应的chunk大小都在递增,绝大多数的bucket中,chunk的大小都在5k以内。只有很小的一部分bucket的支持的chunk size很大, 这个也是oracle在不断的改进中得到的一个最优值,按照比例来划分,保证每次访问需要的chunk大小都能够合理的分配,尽量减少冗余。 同时不是每个bucket里面都是有chunk的,这个chunk的分配还是根据进入shared pool以后申请chunk大小紧密相关,bucket中的chunk数目可不是平均的。

如果想看看shared Pool比较细节一下的信息。可以参考x$ksmsp 这个基表中还是包含了不少的信息值得我们去学习。首先x$ksmsp里面的每一条记录代表一个chunk

SQL> select count(*)from x$ksmsp;

COUNT(*) ---------- 53317 如果你马上执行了一个其它的查询,再来看x$ksmsp的条数,就很可能发生变化。 SQL> select count(*)from all_objects;

COUNT(*) ---------- 13225

SQL> select count(*)from x$ksmsp;

COUNT(*) ---------- 53363

大体来说对于chunk的分配还是一个动态的过程,比如shared pool分为library cache,dictionary cache,如果chunk存放的sql相关的信息时,chunk就属于library cache. 如果chunk存放的信息时dictionary cache的话,chunk就属于dictionary cache. 按照大多数对象的生命周期,chunk的情况也大体如此,可能在不同的数据库版本中会略有不同。 比如在11gR2中的结果会和10g有一些不同。chunk的状态可能有多种,但是大体还是可以理解为4类,free,recr,perm,freeable KSMCHCLS COUNT(*) -------- ---------- freeabl 20196 recr 26469 perm 581 R-freea 134 R-free 60 R-perm 4 free 5918 R-recr 1 首先,可以分配空间的chunk,这种类型的chunk是free, 如果某个session执行的sql语句,同时另外一个session也执行了同样的sql语句,在shared pool中这种类型的chunk就可以临时移出内存,因为可以在需要的时候进行重建。这种chunk就是recreatable的。 如果某个session执行的sql语句都是不同的,或者没有绑定变量,导致在执行的时候生成的sql_id都不同,这种类型的chunk是不能临时欲出内存的,只能在需要的时候进行释放。这种chunk就是freeable的。 如果某个对象通过dbms_pool给直接pin在了shared pool里面,那么对应的chunk就是permanent的,只能在根据需要的时候才释放空间。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2014-11-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
关于oracle中session跟踪的总结(56天)
数据库中的session在操作中可能会有各种各样的问题,比如一条sql语句执行失败,某一个应用在一些特定的场景下就会有一些性能问题等等,有时候在代码层去做一些debug来说肯定是不实际的,而且也不一定能够迅速的排查问题,对于session的监控显得尤为重要。可以灵活的开启和关闭,在数据库层面,session层面,甚至特定的应用层面都能够进行监控,今天和大家分享一下对于的session监控常用的一些方法。 1.dbms_system.set_sql_trace_in_session 可以对其他的session
jeanron100
2018/03/13
1.2K0
关于oracle session的简单测试(r2笔记95天)
平时查看v$session的时候要定位一个session,需要sid,serial#这个两个值,其实更多时候我们关注更多的是sid,对于serial#却不太了解。 至少从v$mystat中,可以看
jeanron100
2018/03/14
7240
使用句柄实现特定场景的无备份恢复 (r3笔记第61天)
在dba的工作中,备份是一切工作的基础。如果没有备份,本来很简单的恢复工作也会难上加难,如果业务数据要求很高,造成数据的丢失或者损坏,就是重大事故了。 使用rman备份或者做一个完整的系统级备份也是很重要的,如果在特定的场景下,没有备份,如果还能恢复,那就太幸运了。 当数据库中的某个数据文件误删的时候,如果数据库还没有重启的时候,还是能够做一些工作的。因为文件对应的句柄还没有释放。我们可以从里面找到一个镜像的备份实现我们的数据恢复。一定注意这种恢复不一定是完全的数据恢复,如果在数据文件删除的瞬间,有开启的事
jeanron100
2018/03/15
7400
简单分析shared pool(二) (r3笔记48天)
对于shared pool的学习,发现越尝试去了解,发现自己对它越不了解。里面的东西很杂。 自己想用几个问题来作为引子来说明更加会有条理一些。 shared pool的大小设置 对于shared pool的大小设置,从早期版本到现在一直都带有争论。 从操作上来说,需要设置shared_pool_size就可以了,如果启用了sga_target或者11g里的memory_target,那shared pool的大小设置都是自动管理的了。 还有shared_pool_reserved_size会在sha
jeanron100
2018/03/14
8330
ORACLE常用性能监控SQL【二】
条件为什么block>100,因为一些很小的表,只有几行数据实际大小很小,但是block一次性分配就是5个(11g开始默认一次性分配1M的block大小了,见create table storged的NEXT参数),5个block相对于几行小表数据来说就相差太大了
小小工匠
2021/08/16
4K0
记一次数据库重启后归档急剧增加的问题(98天)
在本地的环境中测试外部表的性能,由于空间有限,不一会儿归档的空间就爆了。然后文件貌似出现了系统级的问题,刚刚rm掉的归档日志文件。隔了几秒钟再ls,就出现了。怎么删都删不掉。尝试了多次之后,无奈尝试shutdown immediate结果等了好半天还是没反应,然后采用shutdown abort后重启,库直接起不来了。报了ora错误,然后库就起不来了。 查看日志显示,和之前碰到的归档空间不足导致的问题一致。清除有问题的归档之后,重启库就起来了。可以参见日志:http://blog.itpub.net/237
jeanron100
2018/03/14
1K0
临时表相关 (r4笔记第52天)
临时表在日常工作中可能使用比较多,但是大家都对临时表相关的一些知识了解比较少。我们来简单说数理一下。 首先是临时表空间,临时表都存储在临时表空间中,对于临时表空间,从数据库中查询数据字典就能够很清楚的看到,临时表空间是nologging的,也就是临时表也是nologging的。 SQL> select tablespace_name,logging from dba_tablespaces; TABLESPACE_NAME LOGGING -----------------
jeanron100
2018/03/15
4960
查看并行进程的一些简单信息(r3笔记第17天)
在使用并行的时候,总能看到进程中出现一些ora_p这样的进程。有时候查看问题的时候只看到并行进程在运行,却没有思路去查找倒底是哪些session在干些什么,下面简单分析一下。怎么去映射系统级的进程和数
jeanron100
2018/03/14
6660
操作系统存储管理和oracle数据库(第一篇) (r3笔记第76天)
在上大学的时候,学习操作系统感觉特别枯燥,都是些条条框框的知识点,感觉和实际的关联不大。发现越是工作以后,在工作中越想深入了解,发现操作系统越发的重要。像现在的RHCE市场反响不错,如果想深入地学习,就有很多操作系统的知识需要补补。在实践中结合理论还是不错的一种学习方法。自从接触数据库以后,越来越感觉到很多东西其实都是相通的,操作系统中的很多设计思想在数据库中也有借鉴和改进之处。所谓大道至简,其实就是这个道理。 说到存储管理,是操作系统中式最重要的资源之一。因为任何程序和数据等都需要占有一定的存储空间,
jeanron100
2018/03/15
7940
【DB笔试面试528】在Oracle中,如何解决ORA-04030和ORA-04031错误?
ORA-04030报错形如“ORA-04030 'out of process memory when trying to allocate %s bytes (%s,%s)'”,该错误意味着Oracle Server进程无法从操作系统分配更多内存。该内存由PGA组成,其内容取决于服务器配置。对于专用的服务器进程,内存包含堆栈以及用于保存用户会话数据、游标信息和排序区的UGA。在多线程服务器(共享服务器)中,UGA被分配在SGA中,所以在这种配置下UGA不是造成ORA-04030错误的原因。因此,ORA-04030表示进程需要更多内存(堆栈、UGA或PGA)来执行其任务。
AiDBA宝典
2019/09/29
2.2K0
关于数据库中的一些name(r3笔记第64天)
如果接触数据库有些时间了,可能会碰到很多关于数据库相关的名字,比如ORACLE_SID,db_name,instance_name,db_unique_name等等。可能一下子都有些糊涂了,就一股脑儿认为都应该是一致的,其实不然。如果你接触的环境比较单一,可能会有这种错觉。 我们来简单对比一下单实例和多实例下的数据库中的这些名词。 首先来看看单实例的。 [ora11g@rac1 ~]$ echo $ORACLE_SID TEST01 [ora11g@rac1 ~]$ sqlplus / as sys
jeanron100
2018/03/15
6710
session跟踪失效的问题和分析(57天)
最近碰到一个奇怪的问题,在生产和其他比较正式的环境中进行sql trace都没问题,但就是测试环境的数据库不知道怎么的, 设置sql_trace,开启诊断事件,dbms_system,dbms_monitor都试了,就是没有trace日志,我都怀疑是不是有些配置给禁用了。 查看基本的参数设置,没有发现什么问题。 SQL> show parameter statis NAME TYPE VALUE -----------------
jeanron100
2018/03/14
1K0
shell基础学习总结(一) (r3笔记第63天)
关于shell也多多少少的写了不少文章了。在工作中shell的使用也是相当的普遍了,尤其是基础的学习。今天就简单的总结一下,希望对大家有所帮助。 -->查看局部/全局环境变量 printenv env
jeanron100
2018/03/15
7190
关于shared pool的深入探讨(一)
http://www.eygle.com/internal/shared_pool-1.htm
数据和云01
2018/09/05
6090
【DB笔试面试688】在Oracle中,跟踪会话执行语句的方法有哪几种?
因为TRACE的目标范围不同,所以导致必须使用不同的方法。若作用于数据库全局的,则改初始化参数。若只作用于当前会话的,则就用ALTER SESSION命令。若作用于其它会话的,则就用DBMS_SYSTEM包。
AiDBA宝典
2019/11/15
1.1K0
一些“简单”的linux命令(r2笔记46天)
有些linux命令看起来极其简单,只包含2个字符,但确有很强的功能性。看起来还是有些陌生的命令,不过在工作中别忘记它们的存在。 ab 这条命令式做为性能测试所广泛用到的一下子就有了一种高大上的感觉,来一个例子,对百度的某一个网页执行并发100,时长5秒,发送10000次请求的测试 [ora11g@rac1 ~]$ ab -n 10000 -c 100 -t 5 http://image.baidu.com/channel/game This is ApacheBench, Version 2.3 <$
jeanron100
2018/03/14
7400
RAC某节点v$asm_disk查询hang分析处理
主题:RAC某节点v$asm_disk查询hang分析处理 环境:Oracle 11.2.0.3 RAC 故障描述:RAC环境2个节点,节点1查询v$asm_disk正常返回结果,节点2查询v$asm_disk就会一直hang,查询会话对应event是ASM file metadata operation.
Alfred Zhao
2019/05/24
1.2K0
典型案例:深入剖析 ORA-04031 的前世今生
李磊 云和恩墨技术专家 每一个接触过 Oracle 数据库的人想必听到 Ora-04031 都会有一种捶胸顿足的感觉,至少在两年前的我是这样子的。都说 Ora-04031 和 Ora-01555 等是 Oracle 的经典错误,之所以成为经典,可能就是因为它们会经常出现,却又不是那么好解决的缘故吧。今天我就跟大家分享一个我工作当中的4031案例,解读一下4031的前世今生,希望通过今天晚上的交流,当我们再次遇见4031错误时不再像之前那么恐惧。 本次跟大家分享的这个案例是去年我在某电力公司驻场的时候,某
数据和云
2018/03/06
1.6K0
典型案例:深入剖析 ORA-04031 的前世今生
Oracle告警日志里记录了“KILL SOFT -/-/-”会话被杀掉的信息
当由于空闲超时而手动或由PMON终止会话后手动执行alter system kill session时,将在警报日志中记录相关信息
AiDBA宝典
2023/09/08
5090
Oracle告警日志里记录了“KILL SOFT -/-/-”会话被杀掉的信息
关于dual表的破坏性测试(r3笔记第60天)
关于dual表的破坏性测试,既然是破坏性测试,就需要确定这个测试仅限于测试或者个人学习所用,可能有些sql看似极为简单,但是一旦运行就会导致整个业务系统崩溃。 比如说我们拿dual表开刀,这个表是一个dummy表,里面的内容没有特定的意义,就是为了存在而存在。但是一旦这个表出现问题,所有相关的基础操作都会受到影响,后果不敢想象。 来简单模拟一下,在个人的机器上开始做下面的尝试,drop 表dual SQL> show user USER is "SYS" SQL> SQL> show parameter
jeanron100
2018/03/15
9240
推荐阅读
相关推荐
关于oracle中session跟踪的总结(56天)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档