|
|||||
|
以下脚本可以用于收集自动SGA(sga_target>0)内存管理ASMM下的实例诊断信息：
spool auto_sga_diag.log set line 190 pagesize 1400 SELECT a.SGA_MEM + b.PGA_MEM “TOTAL_MEMORY” FROM (SELECT SUM(current_size) / 1024 / 1024 “SGA_MEM” FROM v$sga_dynamic_components, (SELECT SUM(pga_alloc_mem) / 1024 / 1024 “PGA_MEM” FROM v$process) a WHERE component IN (‘shared pool’, ‘large pool’, ‘java pool’, ‘streams pool’, ‘DEFAULT buffer cache’)) a, (SELECT SUM(pga_alloc_mem) / 1024 / 1024 . . . → Read More: Script:收集自动SGA内存管理ASMM诊断信息 几个礼拜前， 有一套10.2.0.2 的 二节点RAC 数据库因为增大db_cache_size ， 引发其中一个实例发生著名的ORA-04031 错误，日志如下:
Errors in file /oracle/oracle/admin/maclean/udump/u1_ora_13757.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00604: error occurred at recursive SQL level 1 ORA-04031: unable to allocate 1048 bytes of shared memory (“shared pool”,”select name,online$,contents…”,”Typecheck”,”kgghteInit”) ORA-00604: error occurred at recursive SQL level 1 ORA-04031: unable to allocate 1048 bytes . . . → Read More: RAC中增大db_cache_size引发的ORA-04031错误 刚才发现在目前最新的11.2.0.3版本中实例instance startup时alert.log 中会提供Large Pages Information 大内存页的信息了:
Starting ORACLE instance (normal) ****************** Large Pages Information ***************** Total Shared Global Region in Large Pages = 0 KB (0%) Large Pages used by this instance: 0 (0 KB) Large Pages unused system wide = 0 (0 KB) (alloc incr 16 MB) Large Pages configured system wide = . . . → Read More: 11.2.0.3 实例启动现在提供Large Pages Information大内存页信息了 深入了解Oracle自动内存管理asmm View more documents from Maclean Liu RAC环境中共享池很大一部分被gcs和ges资源所占用，一般来说这些资源对象都是永久的(perm)的，所以我们无法期待LRU或flush shared_pool操作能够清理这些资源。 在使用大缓存(large buffer cache)的RAC实例环境中，查询v$sgastat内存动态性能视图时总是能发现’gcs resources’、’gcs shadows’、’ ges resource’、’ges enqueues ‘这些组件占用了共享池中的大量内存，为了避免shared pool出现著名的ORA-04031错误，Oracle推荐在RAC环境中设置较大的shared_pool_size初始化参数，此外显示地设置较大的GCS和GES资源结构的初始化分配数(INITIAL_ALLOCATION)也有利于避免ORA-4031。 这些控制GES和GCS资源结构初始化分配数量的参数主要包括： _gcs_resources number of gcs resources to be allocated GCS Resources Number of GCS resource structures determined by _gcs_resources parameter Stored in segmented array Externalized in X$KJBR Number of free GCS resource structures in X$KJBRFX _gcs_shadow_locks number of pcm shadow locks to be . . . → Read More: Know GCS AND GES structure size in shared pool PL/SQL Program Units即PL/SQL程序单元，常被叫做”library units”或lib-units. 参考以下模块类型: package spec package body top-level function or procedure type spec type body trigger anonymous blocks. PL/SQL 虚拟机的内存使用主要体现在4个方面： PGA PL/SQL stack call,用于保存本地变量和其他一些状态结构 NCOMP生成的动态链接库文件 CGA 二级内存(secondary memory),分配的堆和大的可收缩本地变量如大的strings、Lob或collections UGA 程度单元的实例(library-unit instantiations),如package global variables, DL0/ DL1 dependency vectors, display frame等 SGA 共享池中的MCODE子堆 KGL – Kernel Generic Library Manager 该layer管理会话间需要共享的资源,如PL/SQL MCODE,Diana,Source,SQL cursor,SQL Plan) KGI – . . . → Read More: PL/SQL Virtual Machine Memory Usage 在10g中引入了数据泵Data Pump导入导出工具，DataPump的工作流如下图: 我们在使用Data Pump工具时经常会遇到著名的ORA-04031/ORA-04030错误，主要影响DataPump的内存组件有PGA和SGA中的共享池Shared Pool、流池Streams Pool。Expdp/Impdp对shared Pool的开销主要体现在其运行过程中需要调用一系列的包体PACKGE BODY，它们包括: PACKAGE_NAME TYPE SHARABLE_MEM —————————————- ——————– ———— SYS.KUPM$MCP PACKAGE BODY 425448 SYS.KUPW$WORKER PACKAGE BODY 386000 SYS.DBMS_METADATA_INT PACKAGE BODY 325856 SYS.DBMS_REPCAT_UTL PACKAGE BODY 269064 SYS.DBMS_METADATA PACKAGE BODY 226624 SYS.DBMS_DATAPUMP PACKAGE BODY 192888 SYS.DBMS_PRVTAQIS PACKAGE BODY 147288 SYS.DBMS_PRVTAQIM PACKAGE BODY 142680 SYS.KUPF$FILE PACKAGE BODY 142008 SYS.DBMS_METADATA_UTIL PACKAGE BODY 115224 . . . → Read More: Data Pump failed with ORA-04031/ORA-4030? 每一个Oracle的初学者在入门阶段都会接触到SGA/PGA的知识，如果是从10g开始学习那么会多或少会对ASMM有所了解，从使用的角度来说ASMM的出现极大地简化了Oracle内存初始化参数的设置，在ASMM的使用上高级DBA和初学者不会有太大的差别；很多人因此而认为ASMM极大程度地减少了数据库对于专业DBA的依赖：如果我们有一个足够智能的DB，那么为什么还要花费金钱雇佣DBA呢？这似乎是时下一种十分流行的想法。当然这种想法我个人是不能苟同的，ASMM一定程度上带来了便利，更大程度上它是一个黑盒，黑盒里面藏了很多秘密，这些秘密带来比手动管理更多的不确定性；在10g release 1和10.2的早期版本中ASMM扮演的角色有点像一个闯祸精，另一个让用户对ASMM很不待见的原因是ASMM直接拖慢了startup的速度。一个个人观点是ASMM也好AMM也罢，都要求产品数据库DBA掌握更多SGA/PGA相关的知识才能成功”驾驭”这些”有智力”的家伙，有点夸张的说这个时候的DBA很像一个chemist(需要和一大堆以1个或2个下划线开头的奇怪参数打交道)。 为了不辱使命我们真的有必要了解一下ASMM的基本知识，显然这并不是一件容易的事情…… Oracle的SGA基本内存组件从9i开始并没有非常大的变化，他们包括: Buffer Cache 我们常说的数据库高速缓存，虽然我一直不明白要冠以高速之名 Default Pool 默认的缓冲池，大小由DB_CACHE_SIZE决定 Keep Pool 持久的缓冲池，大小由DB_KEEP_CACHE_SIZE决定 Non standard pool 非标准块标准池，大小由DB_nK_cache_size决定 Recycle pool 回收池，大小由db_recycle_cache_size决定 Shared Pool 共享池，大小由shared_pool_size决定 Library cache 俗称的库缓存 Row cache 行缓存，也叫字典缓存 Java Pool java池，大小由Java_pool_size决定 Large Pool 大池，大小由Large_pool_size决定 Fixed SGA 固定的SGA区域，包含了Oracle内部的数据结构，一般被存放在第一个granule中 在9i中尚未引入ASMM，唯一的选择是手动管理的SGA，有时候也叫做MSMM。在9i中除去buffer cache的大小可以手动修改外，其余组件都无法动态修改。因为缺乏一种动态管理的机制，所以在9i中如果有某个内存区域有急用，也无法从其他有空闲内存的组件中捐献一些来解燃眉之急。 手动管理SGA的缺点在于: 个别组件如shared pool、default buffer pool的大小存在最优值，但组件之间无法交换内存 在9i中就提供了多种内存建议(advisor)，但都要求人工手动干预 无法适应工作负载存在变化的环境 往往会导致内存浪费，没有用到实处 若设置不当，引发著名的ORA-04031错误的可能性大大提高 ASMM的优势在于: 全自动的共享内存管理 无需再配置每一个内存组件大小参数 仅使用一个参数sga_target驱动 有效利用所有可用的内存，极大程度上减少内存浪费 . . . → Read More: 深入了解ASMM |
|
||||
|
Copyright © 2012 Oracle Clinic – Maclean Liu的个人技术博客 - All Rights Reserved |
|||||
最新评论