Oracle ORA-04031 错误说明

在老熊的Blog上看到他们写的有关ORA-04031的文章，转到blog。

老熊的Blog：

http://www.laoxiong.net/an-ora-04031-case.html

ORA-04031这个错误，几乎每一个专业的DBA都遇到过。这是一个相当严重的错误，Oracle进程在向SGA申请内存时，如果申请失败，则会报这个错误。大部分情况下是在向SGA中的shared pool申请内存时失败，而少有向large pool等池中申请内存失败。比如下面的报错：

Wed Apr 27 16:00:25 2011

Errors in file /oracle/app/oracle/admin/zxin/bdump/zxin1_ora_2052294.trc:

ORA-04031: unable to allocate 4128 bytes of shared memory

("shared pool","unknown object","sga heap(3,0)","kgllk hash table")

这里很清楚地表示出来，是在向shared pool申请内存时失败。

shared pool内存申请（分配）失败，通常有如下的几种可能：

（1）shared pool过小，比如在SGA Manual Management方式下，shared pool设置过小。比如一套数千连接的大系统，shared pool只设置了几百M。这种情况下，要解决问题很解单，增加shared pool的大小即可。

（2）应用没有使用绑定变量，硬解析非常多，导致shared pool内存碎片严重，分配大块内存时不能获得连续的内存空间。硬解析多的一个变种是虽然使用了绑定变量，但是由于某种原因，Cursor不能共享，导致Child Cursor非常多。实际上，如果shared pool较大（比如数GB大小），这种问题还是很少出现的，并且出现也通常出现在申请大块内存时。这种情况如果使用alter system flush shared_pool可以暂时缓解问题。但是这条命令又通常不适用于shared pool较大而且比较繁忙的系统。使用绑定变量

（3）Cache的cursor很多，同时cursor_space_for_time这一参数设置为TRUE，可能会使shared pool碎片化严重，导致不能分配到大块的连续内存。

（4）Oracle的BUG导致内存泄露，比如在一些版本中查询v$segment_statistics这样的视图导致内存泄露，使shared pool内存耗光。同样的情形还有类似于“obj stat memory”,”gcs resources”,”ges resources”等。通常这类内存为perm类型（permanet），这类内存通常是在分配时就确定了固定的用途，不能用于其他用途，因此极容易产生碎片。

（5）Oracle从9i开始，根据shared pool的大小将shared pool分为多个子池（subpool)，每个子池有独立的free list，同时在分配时单独管理（有其独立的shared pool latch）。Oracle的BUG或者说是内存分配策略缺陷导致某一类shared pool的内存分配只在一个子池(subpool)中，即多个子池的使用极不均衡，导致向那个使用得最多的子池申请内存时失败。报错信息中的”sga heap(3,0)”即指明是在第3个子池申请内存时失败。本文案例中的ORA-04031错误其产生的原因可以归结为Oracle对shared pool的分配/使用策略问题。

（6）操作系统内存不足，这只会出现在shared pool的使用还没有达到最大值时才会出现，并且在操作系统都有swap的情况下，只有部分操作系统才可能有这种情况，比如在HP-UX下，reserved内存过多导致swap满。

（7）其他原因，多数是因为BUG。请参考下面提及的MOS参考文档。

本文中的案例，其数据库是运行在AIX 5.3系统中的10.2.0.4 RAC，RAC节点数为2。数据库是从9i升级到10g，而目前处于正式升级前的测试阶段。数据库报的ORA-04031错误信息如本文前面所示（其中的数据库名称已经做了处理）。

在继续讲解案例之前，不得不提到MOS上的几篇关于ORA-04031错误的文档：

（1）Master Note for Diagnosing ORA-4031 [ID 1088239.1]

（2）Diagnosing and Resolving Error ORA-04031 on the Shared Pool or Other Memory Pools [Video] [ID 146599.1]

（3）Interpreting the automatically generated ORA-4031 diagnostic trace. [ID 809560.1]

（4）Troubleshooting and Diagnosing ORA-4031 Error [Video] [ID 396940.1]

（5）ORA-4031 Common Analysis/Diagnostic Scripts [Video] [ID 430473.1]

其实分析ORA-04031错误，通常有以下几个要点：

（1）判断错误发生所有的内存区域，是shared pool,large pool还是streams pool等。这个很容易从错误信息中判断出来，本文主要描述shared pool的ORA-04031错误，这也是最常见的。

（2）检查Shared Pool的总大小以及free memory的大小。如果free memory看上去挺多，以subpool为单位检查是否存在是由于碎片导致没有足够的连续内存以供分配，特别是关注报错信息中提及的子池。

（3）如果Shared Pool相较于系统规模来说足够大（通常数GB都已经是很大的了），检查Shared Pool中有没有占用非常多的内存类型或内存组件，如果有，是什么样的类型的内存，在各个子池之间是否分布均匀。如果有异常占用较多的内存类型，根据此类型在MOS上搜寻是否是会有相应的BUG引起，或者分析这种类型的内存消耗较多的原因。比如如果是sql area很大，检查是不是硬解析特别多，或者是不是child cursor特别多引起。

（4）基于以上分析的数据，来判断shared pool内存分配失败的原因。

上面的步骤写得比较粗略，关于分析和解决ORA-04031问题，这里也有一篇不错的文章：Simplified Approach to Resolve ORA-4031

这里关键的是分析Shared Pool的内存数据。ORA-04031错误发生后如果有条件可以马上连接到数据库中查询相应的x$表和v$视图得到相应的数据，否则只能通过ORA-4031错误发生时产生的trace文件。_4031_dump_bitvec这个隐含参数用于控制发生ORA-04031错误时对SGA的dump行为，而trace文件的分析就不像使用SQL那样简单了。

下面再来详细地分析案例：
从错误信息来看，很显然，是向shared pool的第3个subpool申请内存时出错。以下的数据是shared pool的数据：

SQL> select sum(bytes)/1024/1024 mb from v$sgastat where pool='shared pool';

----------

4096.53062

SQL> SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ)

2SIZ,

3To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')|

4|'k' "AVG SIZE"

5FROMX$KSMSPGROUP BY KSMCHCLS;

CLASSNUMSIZ AVGSIZE

-------- ---------- ---------- ------------

R-freea51224576.05k

freeabl807395 16439698481.99k

recr5307286620652401.22k

R-free256214910976819.82k

free430631006054962.28k

perm140 167336863211,672.49k

注意：

在生产库上查询X$KSMSP时，要看下系统的繁忙或者说是负载高低，因为可能会导致db hang住。

虽然free的数量不是太多，但是freeable的数量还是很多的。
下面是各个子池更详细的数据：

SQL> SELECT KSMCHIDX,KSMCHDUR, KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ)

2SIZ,

3To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')|

4|'k' "AVG SIZE"

5FROMX$KSMSPGROUP BY KSMCHIDX,KSMCHDUR, KSMCHCLS

6order by 1,2,3;

KSMCHIDXKSMCHDUR CLASSNUMSIZ AVG SIZE

---------- ---------- -------- ---------- ---------- ------------

11 R-free2722666392819.82k

R-freea542592.05k

free2614024.53k

perm3243029944813,131.70k

2 R-free1210073952819.82k

R-freea241152.05k

free10531245191122.27k

freeabl4492232457736.71k

recr163177134273584.80k

3 R-free97555464819.82k

R-freea18864.05k

free167845557042.65k

freeabl798151025140241.25k

recr32689363680961.09k

4 R-free2016789920819.82k

R-freea401920.05k

free218258100562.60k

freeabl662352546561843.75k

recr16245582844803.50k

21 R-free2520987400819.82k

R-freea502400.05k

free2320016.85k

perm3539841838411,116.58k

2 R-free43357984819.82k

R-freea8384.05k

free513766041761.26k

freeabl4037712140944.29k

recr5494245005024.80k

3 R-free97555464819.82k

R-freea18864.05k

free147755245683.65k

freeabl795481018798081.25k

recr32380360334481.09k

4 R-free2117629416819.82k

R-freea422016.05k

free254070924242.73k

freeabl701332703328003.76k

recr15924572630323.51k

31 R-free2621826896819.82k

R-freea522496.05k

free2620520.77k

perm3341435541612,261.94k

2 R-free43357984819.82k

R-freea8384.05k

free469370530321.47k

freeabl4972314339800.28k

recr5277142357312.78k

3 R-free119234456819.82k

R-freea221056.05k

free359492809042.52k

freeabl958231219344881.24k

recr39643440975041.09k

4 R-free2520987400819.82k

R-freea502400.05k

free282272916802.52k

freeabl844433231497123.74k

recr19148679970083.47k

41 R-free2722666392819.82k

R-freea542592.05k

free2618088.68k

perm4043029538410,505.26k

2 R-free65036976819.82k

R-freea12576.05k

free4818114739202.33k

freeabl4608939963224.85k

recr5406144188072.80k

3 R-free97555464819.82k

R-freea18864.05k

free142741095042.81k

freeabl800261023790801.25k

recr33217369492401.09k

4 R-free2117629416819.82k

R-freea422016.05k

free199362284643.05k

freeabl705812690871363.72k

recr16614593726563.49k

KSMCHDUR是什么意思？在9i里面这个列的值通常为1。实际上，Oracle从9i开始，将shared pool划分为多个sub pool。而在10g以上的版本中（具体开始的版本号已经不记得），每个sub pool又分了4个更小的池，我们暂且称之为mini heap。每个mini heap有其自己的free list。KSMCHDUR这一列即表示mini heap的编号。”heap(3,0)”中的0是指第1个mini heap。

在上面的数据中，可以看到这个子池的第1个mini heap的free已经很少，只有10来K。另外，我们可以观察到，perm类型的内存块只存在于每个sub pool的第1个min heap中。这个是一个重点，在后面会有解释。

这里本应该有通过查询v$sgastat得到shared pool的各个组件占用的内存分布，只是写BLOG时找不到了….但是我们可以在trace文件中找到数据，下面只列出sub pool 3的数据：

==============================

Memory Utilization of Subpool 3

================================

Allocation NameSize

___________________________________

"free memory"81466568

"miscellaneous"0

"dpslut_kfdsg"512

"trace buffer"737280

"trace_knlasg"504

"gcs res hash bucket"1048576

"gcs res latch table"12288

"evaluation con"0

"sql area"344545752

"UNDO STAT INFO"59904

"txncallback"141744

"transaction"2103264

"ges resource pools"3968

"sessions"4526488

"dlo fib struct"128032

"KJCTS process batching st"240

"row cache"3272

"KCB where statistics arra"25888

"KCB buffer wait statistic"32000

"KCB incremental ckpt entr"512

"invalid low rba queue"1024

"table definiti"108704

"temporary tabl"4136

"KCL instance cache transf"131072

"resumable"2720

"KESTB existence bitvec se"128

"type object de"392448

"enqueue_hash"318960

"KSXR pending consumption "20192

"KTI SGA freeable small po"0

"trigger defini"885472

"trigger source"99264

"trigger inform"960

"KTCN: Obj Invalidation Se"2336

"kmgsb circular statistics"108800

"kgl lock hash table state"45360

"kglsim size of pinned mem"8024

"kelr system metrics table"280

"kzctxgjsi ksuseclid memor"117360

"kzctxgjci ksuseclidmemo"0

"CCursor"95912048

"ksr message pool free que"188960

"ksb ci process list (each"144

"ksunfy: nodes of hierarch"320

"ksuloi: long op free list"256

"kwqmncal: allocate buffer"4048

"ksim group query request "0

"ksuxds ksuseclidmemory "0

"call"87304

"dictionary cache"0

"KSXR pending reply queue "255488

"hng: All sessions data fo"0

"ksfv subheap descriptor"184

"gcs resources"169082312

"gcs affinity"8320

"gcs opaque in"12312

"PCursor"50743128

"ges resource"539376

"fdrec_kffsg"24

"work area tab"80640

"kglsim main lru count"38400

"plwpil:wa"4264

"grptab_kfgsg"2464

"AW SGA"40

"KEWS sesstat seg tbl"8

"kebm slave descriptors"1456

"kglsim hash table bkts"1048576

"KSXR global channels"1288

"ges enqueues"17333720

"PLS chunk"352

"KSQ event description"1440

"KESTB existence bitvec"4096

"gcs shadows"101246344

"qmtb_init_data"224

"Core dump directory"264

"sort segment handle"7480

"SERVICE NAME ENTRY"48

"PQ/BizCard"1536

"qtree_kwqbspse"40

"latch descriptor table"1576

"recovery domain"29856

"parameters"30056

"SHARED SERVERS INFO"240

"qtree_kwqbsgn"40

"post agent"0

"pspool_kfsg"80

"plwsppwp:wa"0

"PL/SQL DIANA"14050624

"segmented arrays"2072

"Checkpoint queue"4097024

"sim lru segments"2560

"sim segment hits"2560

"sim state object"40

"partitioning d"199616

"ASH buffers"8388608

"message pool freequeue"276336

"PL/SQL MPCODE"4499360

"PL/SQL PPCODE"3984944

"procs: ksunfy"1512000

"primem_kfmdsg"1032

"SYSTEM PARAMETERS"76624

"object queue hash buckets"262656

"object queue hash table d"7552

"object level stats hash t"512

"object stat dummy statprv"144

"sim cache sizes"320

"logout storm management"24000

"pl/sql source"21256

"sys event stats"199136

"parameter handle"67896

"Parameter Handle"1656

"channel handle"828672

"API blockers array"64

"PARAMETER TABLE"2048

"PARAMETER ENTRY"8

"LGWR post requested array"24

"bloom filter"3104

"param hash values"5984

"sql area:PLSQL"11477776

"PX subheap desc"256

"repository"213544

"sql area:KOKA"16192

"archive_lag_target"9624

"state objects"640

"latch nowait fails or sle"116832

"sched job slv"5952

"pso tbs: ksunfy"390000

"dummy"269928

"Sort Segment"37440

"Cursor Stats"6095760

"Banner Storage"2048

"quiescing session"3872

"API data buffer"16

"buffer handles"1020000

"prmtzdini tz region"408320

"sga node map"16

"savepoints"0

"Managed Standby Proc Arra"24576

"OS proc request holder"4664

"db_files"416576

"PX server msg stats"2288

"KQR M PO"283376

"kks stats"40

"parameter table block"483168

"KSFV SGA"824

"plugin datafile array"36016

"plwda:PLW_STR_NEW_RVAL"24

"plwspv:PLW_STR_NEW_VAL"16

"KGKP sga"32

"BRANCH TABLE SEGMENTED AR"70176

"mvobj part des"306544

"parameter value memory"216

"multiblock re"98496

"parameter text value"1080

"parallel_max_servers"8192

"KGLS heap"13290800

"KGSKI sga"80

"resize request state obje"368000

"MTTR advisory"1462832

"monitoring co"12480

"rules engine aggregate st"1416

"krbmror"36400

"joxs heap"136

"krbmrsr"152

"ksfqpar"4008

"SGA - SWRF DrvMet Runtime"2656

"SGA - SWRF Metrics ksuTim"72

"SGA - SWRF RawMet Runtime"1408

"SGA - SWRF Metrics WCTime"32

"SQL Memory Manager Base W"13400

"change notification regis"4096

"simulator latch/bucket st"59392

"Prefetch history buffer"2832

"change notification obj m"4096

"KQR ENQ"16512

"kksss"16464

"API data buffer length"0

"kokcd"0

"kohsg"8

"Sequence Background Insta"88

"ksfqpn"416

"KGLS SP"4704

"knstsg"48

"latch classes"352

"system default language h"568

"name-service entry"2592

"API data buffer array"0

"kzull"4096

"kzulu"392

"kfgsga"104

"library cache"46604712

"kcrrny"25320

"spfile cleanup structure "16760

"xssinfo"5952

"buffer_pool_desc_array"3384

"row cache child latch"3360

"rm request queue link"5320

"SCHEDULING POLICY TABLE"160

"namhsh_kfdsg"4104

"Closed Thread SCN Bitvec "8448

"Client ID trace settings "3872

"osp allocation"21104

"os statistics"9192

"plwppwp:PLW_STR_NEW_LEN_V"16

"plwgc: plwgc_garbage_clea"0

"plwiiw: kglpql warnings"0

"object queue"808080

"obj stat memo"599184

"obj htab chun"122960

"object level"111888

"XCT XGA"0

"SGA - SWRF Metric Eidbuf "900840

"Processor group descripto"64

"Prefetch client count per"32

"X$SKGXPIA"2680

"simulator hash buckets"2101248

"State object subpools"896

"API data buffer length ma"0

"AWR Table Info (KEW layer"872

"character set memory"4856

"sim segment num bufs"1280

"character set object"129728

"session idle latches"2560

"qesmmaInitialize:"112

"returns from remote ops"49152

"name-service"4080

"SGA - SWRF Metric CHBs"10912

"listener addresses"32

"db_block_hash_buckets"67108864

"KSI resource types"2704

"kglsim object batch"4196304

"trigger condition node"72

"ksws service events"18560

"Heap0: KGL"11642128

"fixed allocation callback"392

"kqlpWrntoStr:value"0

"KEWS statistic name"424

"KEWS statistic maps"1096

"KCL partition table"131072

"kebm slave message"88

"kcbl state objects"12800

"free rm request queue lin"0

"xsoqsehift"3104

"DBWR event stats array"192

"kgllk hash table"659456

"event descriptor table"192

"kpssnfy: kpsssgct"32

"kpscad: kpscscon"1952

"dbwriter coalesce buffer "3158016

"kglsim hash table"8208

"gcs resource freelist dyn"256

"gcs shadow locks dyn seg "256

"kks stats latch"160

"KTC latch cleanup"576

"ges enqueue max. usage pe"64

"ges lmd process descripto"2760

"KTU latch cleanup"2496

"kscdnfyinithead"16

"X$KSVIT table"512

"kqlpaac:value-1"64

"KCL buffer header"192064

"kxfpdp pointers"28800

"kodosgi kopfdo"104

"kglsim latches"136

"TXN TABLE SEGMENTED ARRAY"54784

"KJCT remote i"1640

"KKJ SHRD WRQS"288

"KJC dest ctx"3560

"kwrsnfy: kwrs"1624

"kwqmn:tskdata"0

"KKKI consumer"4136

"dbwr suspend/resume ptr a"16

"dbwr actual working sets "64

"KGSKI schedule"0

"temp lob duration state o"3296

"ges regular msg buffers"3078008

"jsksncb: 9"28672

"Transportable DB Converte"2552

"KTU lat struct"800

"kks stats hds"256

"KSFD SGA I/O b"4190248

"HTTP fixed headers"72

"UNDO INFO SEGMENTED ARRAY"649856

"ges process hash table"132000

"jsksncb-latch"1280

"kfkid hrec"24

"KTCCC OBJECT"0

"KTPR HIST TB"2808

"KTF MAPPINGS"12288

"kksss-heap"35136

"kglsim heap"3431232

"event statistics per sess"7665280

"eventlist to post commits"16

从上面的数据可以看到，第3个sub pool中，占用较多的内存是gcs resources、gcs shadows以及sql area。但是没有明显的异常。

下面是第3个sub pool中第1个mini-heap中free memory的更详细数据：

SQL> break on ksmchidx on ksmchdur

SQL> select

2ksmchidx,ksmchdur,

3case

4when ksmchsiz < 1672 then trunc((ksmchsiz-32)/8)

5when ksmchsiz < 4120 then trunc((ksmchsiz+7928)/48)

6when ksmchsiz < 8216 then 250

7when ksmchsiz < 16408 then 251

8when ksmchsiz < 32792 then 252

9when ksmchsiz < 65560 then 253

10when ksmchsiz >= 65560 then 253

11end bucket,

12sum(ksmchsiz)free_space,

13count(*)free_chunks,

14trunc(avg(ksmchsiz))average_size,

15max(ksmchsiz)biggest

16from

17sys.x$ksmsp

18where

19inst_id = userenv('Instance') and

20ksmchcls = 'free'

21group by

22case

23when ksmchsiz < 1672 then trunc((ksmchsiz-32)/8)

24when ksmchsiz < 4120 then trunc((ksmchsiz+7928)/48)

25when ksmchsiz < 8216 then 250

26when ksmchsiz < 16408 then 251

27when ksmchsiz < 32792 then 252

28when ksmchsiz < 65560 then 253

29when ksmchsiz >= 65560 then 253

30end ,

31ksmchidx, ksmchdur

32order by ksmchidx , ksmchdur

33/

ksmchidxksmchdurbucket free_space free_chunks average_sizebiggest

---------- ---------- ---------- ---------- ----------- ------------ ----------

3157217272

131361136136

272481248248

484161416416

5619204480480

6616803560560

6846088576576

1641344113441344

1801472114721472

1881536115361536

1901552115521552

1991624116241624

2041880118801880

2072032120322032

可以看到，最大的free memory块才2032字节，而报错中提到的申请的内存大小为4128字节。由于在第3个sub pool的第1个mini heap中没有4128字节的连续free memory，所以导致内存申请失败。

那么这里的问题是，为什么这个mini heap中的free memory那么少？正如前面提及，为什么这个mini heap中的已经使用的类型全是perm类型？这个问题的答案就在于”DURATION”。Oracle在启用了SGA自动管理的模式下，为了便于在shared pool与buffer cache或其他内存之间动态调整大小，规定了在每一个mini heap中分配内存按照duration来进行。这里duration可以理解为内存块的持久时间。

perm类型的内存块，就是分配后不能释放，只能用于相同组件的重用。比如gcs resources这种组件的内存是perm类型，这种内存被分配后，不能释放给sql area使用，也不能给gcs shadows使用，只能给其他的gcs resource使用。

按DURATION分配内存时，perm类型的内存就只能从每个sub pool的第1个mini heap中分配。而其他类型的内存通常在sub pool的第2-4个mini heap中分配。由于perm类型的内存不能释放，也不能被其他组件的内存重用，所以里面的内存会越用越少，如果没有了free memory怎么办？前面说到，这种模式主要是工作在SGA自动管理模式下，如果free memory没有了，就会从SGA中的其他部分，比如buffer cache中取得memory chunk，加入到缺少内存的mini heap中。正常情况下这种机制没有问题。

完全使用SGA自动管理有一个缺陷就是，如果应用系统绑定变量做得不好，或者由于BUG，child cursor过多，导致shared pool会变得很大，甚至超过10G，严重的比buffer cache还大，另一方面，在buffer cache和shared pool之间频繁地调整大小，可能会导致严重的解析问题和其他性能问题。

针对这个问题，通常有2种解决办法：一种就是关闭SGA自动管理，即将SGA_TARGET设置为0，以9i的方式来设置shared_pool_size,db_cache_size这些参数，来手动管理SGA；第二种就是sga_target仍然大于0，即自动管理SGA，但是通过设置shared_pool_size，db_cache_size等参数限制这些内存组件的最小大小，而只留给系统极少的自动调整空间。

而出现问题的这套系统，正是使用了第二种方式，开启了SGA自动调整，但是留给自动调整的空间极少。SGA_TARGET为35G，buffer_cache_size为30G，shared_pool_size为4G，再加上large_pool等组件，几乎没有什么可自动调整的余地。这种方式下，就存在了问题。

下面来做一个按时间的分析：

（1）时间T1，数据库启动，shared pool只消耗了极少量的内存。

（2）时间T2至时间T3，Oracle进程请求shared pool内存，Oracle会向操作系统以指定的粒度为单位（比如16MB）请求物理内存，加入到所请求内存所在的mini heap中。直至shared pool的大小达到shared pool最大容许的大小。这个容许大小由各参数计算而来。比如说SGA_TARGET为10G，其他组件的参数设置后最小值为8G，shared_pool_size的值为1G，但是shared pool的最大容许大小为2G。这个时候，每个sub pool的mini heap的大小已经固定。在到达shared pool最大容许大小这一阶段，可能会从buffer cache等组件中占用。

（3）时间T4，Oracle进程请求shared pool内存，这个时候只能从free list或age out内存块后获取内存，对于sub pool的第1个mini heap，只能从free list中获取，因为这个mini heap中的已用内存全是perm，是不能age out的。

（4）时间T5，Oracle进程请求shared sub pool中第1个mini heap的内存，但是free list中已经没有内存。所以报ORA-04031错误。

在上面的时间点T5那里，如果SGA有较大的自动调整空间，比如说完全没有限制，即buffer_cache_size等参数很少或为0，这样在请求第1个mini heap中的内存时，完全可以从buffer cache中占用，这样的后果是使shared pool越来越大。

而本文案例的ORA-04031，正是由于SGA自动管理，而自动调整的余地又太小，最终使sub pool的第1个mini heap空间用光。当然我们可以分析为什么会用光，这个就显得更为复杂，这跟数据量、应用系统都有很大的关系。而系统中第1次出现ORA-04031错误的进程，是一个job进程，而此后大部分出现的错误均是job进程，能检查job代码，发现在做大量的表的大量数据的UPDATE操作，这可能是引起gcs shadows和gcs resources大量内存使用的原因。在一套RAC数据库中，gcs和ges相关的perm内存占用可能会比较大。

那么除了调整应用，应该怎么样解决这样问题？这里的解决方法是增加shared_pool_size参数到6G，同时将sga_target设置为0，再重启。
而另一种可能的办法是将参数“_enable_shared_pool_durations”设置为FALSE。这一参数为FALSE，将会使shared pool内存分配时，不再使某一类型的内存(比如perm)必须要求在一个固定的mini heap中。而实际上，sga_target设置为0之后，这一个参数自动会设为FALSE（由于这一参数是静态参数，所以修改了sga_target之后需要重启才会使这个隐含参数改变），所以建议的解决办法是设置sga_target参数，而不建议修改隐含参数。当然还有一种办法是完全让Oracle自动管理SGA，将buffer_cache_size和shared_pool_size等参数设置为0，但是正如前面所说，这种方法有比较大的缺陷。

SGA管理方式由自动管理改为手工管理，示例：

alter system set sga_target=0m scope=spfile;
alter system set shared_pool_size=3072m scope=spfile;
alter system set large_pool_size=512m scope=spfile;
alter system set java_pool_size=16m scope=spfile;
alter system set db_cache_size=6400m scope=both;

-------------------------------------------------------------------------------------------------------

Oracle ORA-04031 错误说明相关推荐

Oracle Ora 错误解决方案合集
Oracle Ora 错误解决方案合集参考文章: (1)Oracle Ora 错误解决方案合集 (2)https://www.cnblogs.com/ios9/p/8627643.html 备忘一下 ...
oracle提示01034,oracle数据库ORA 01034错误问题解决方案
ORA-01034错误的话: Oracle常见错误之一这是个Oracle数据库服务器比较常见的错误.有经验的用户几乎马上就能解决这个错误,再不济也能马上到Metalink去搜索一下. 不幸的是,大多 ...
ORA-28547:连接服务器失败，可能是Oracle Net管理错误
描述:监听和服务都正常启动了,但是远程连接的时候会有这种错误 ORA-28547:连接服务器失败,可能是Oracle Net管理错误解决办法: listener.ora 文件中 DEFAULT_SE ...
Oracle的常见错误及解决办法
ORA-12528: TNS:listener: all appropriate instances are blocking new connections ORA-12528问题是因为监听中的服务 ...
使用DBeaver远程连接Oracle数据库出现错误“listener does not currently know of service requested in connect descrip”
使用DBeaver远程连接Oracle数据库出现错误"listener does not currently know of service requested in connect des ...
Oracle ORA
ORA-00001: 违反唯一约束条件 (.) 错误说明:当在唯一索引所对应的列上键入重复值时,会触发此异常. ORA-00017: 请求会话以设置跟踪事件 ORA-00018: 超出最大会话数 OR ...
linux下ora-12505,甲骨文临时ORA 12505错误后的Linux启动
我遇到与Oracle一个很奇怪的现象,也许有人可以帮助我,让我总结一下真正的快:甲骨文临时ORA 12505错误后的Linux启动我的首选操作系统是Debian的Linux操作系统,我使用的是Ora ...
oracle 配置数据库错误,Oracle数据库配置错误信息解决方法
Oracle数据库配置错误信息 Oralce数据库的错误信息经常会出现,我们看见的都是错误的代码,至于错误原因究竟是什么还一时半会难以解答,所以就把一些常见的错误整理了一下,来看看也许对你有帮助的. ...
oracle 10g报12514,oracle 10g 12514错误
oracle 10g 12514错误 ORA-12514: TNS:listener does not currently know of service requested in connect处理 ...
oracle数据库出现01034错误,Oracle数据库ORA-01034错误
ORA-01034错误是Oracle数据库服务器比较常见的错误.有经验的用户很快就能解决这个错误,但对于初级用户来说解决起来却存在一定的难度(因为对于初级用户提Metalink也起不到什么作用--一般 ...

Oracle ORA-04031 错误说明

Oracle ORA-04031 错误说明相关推荐

最新文章

热门文章

Oracle ORA-04031 错误 说明

Oracle ORA-04031 错误 说明相关推荐

最新文章

热门文章

Oracle ORA-04031 错误说明

Oracle ORA-04031 错误说明相关推荐