ORA-04031案例一则（非常详细的解释）

「爱情、让人受尽委屈。」 2022-05-28 01:44 214阅读 0赞

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

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

1.  Wed Apr 27 16:00:25 2011  
2.  Errors in file /oracle/app/oracle/admin/zxin/bdump/zxin1\_ora\_2052294.trc:  
3.  ORA-04031: unable to allocate 4128 bytes of shared memory  
4.  ("shared pool","unknown object","sga heap(3,0)","kgllk hash table")

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

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

*  shared pool过小，比如在SGA Manual Management方式下，shared pool设置过小。比如一套数千连接的大系统，shared pool只设置了几百M。这种情况下，要解决问题很解单，增加shared pool的大小即可。
 *  应用没有使用绑定变量，硬解析非常多，导致shared pool内存碎片严重，分配大块内存时不能获得连续的内存空间。硬解析多的一个变种是虽然使用了绑定变量，但是由于某种原因，Cursor不能共享，导致 Child Cursor非常多。实际上，如果shared pool较大（比如数GB大小），这种问题还是很少出现的，并且出现也通常出现在申请大块内存时。这种情况如果使用alter system flush shared\_pool可以暂时缓解问题。但是这条命令又通常不适用于shared pool较大而且比较繁忙的系统。使用绑定变量
 *  Cache的cursor很多，同时cursor\_space\_for\_time这一参数设置为TRUE，可能会使shared pool碎片化严重，导致不能分配到大块的连续内存。
 *  Oracle的BUG导致内存泄露，比如在一些版本中查询v$segment\_statistics这样的视图导致内存泄露，使shared pool内存耗光。同样的情形还有类似于“obj stat memory”,”gcs resources”,”ges resources”等。通常这类内存为perm类型（permanet），这类内存通常是在分配时就确定了固定的用途，不能用于其他用途，因此极容易产生碎片。
 *  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的分配/使用策略问题。
 *  操作系统内存不足，这只会出现在shared pool的使用还没有达到最大值时才会出现，并且在操作系统都有swap的情况下，只有部分操作系统才可能有这种情况，比如在HP-UX下，reserved 内存过多导致swap满。
 *  其他原因，多数是因为BUG。请参考下面提及的MOS参考文档。

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

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

*  Master Note for Diagnosing ORA-4031 \[ID 1088239.1\]
 *  Diagnosing and Resolving Error ORA-04031 on the Shared Pool or Other Memory Pools \[Video\] \[ID 146599.1\]
 *  Interpreting the automatically generated ORA-4031 diagnostic trace. \[ID 809560.1\]
 *  Troubleshooting and Diagnosing ORA-4031 Error \[Video\] \[ID 396940.1\]
 *  ORA-4031 Common Analysis/Diagnostic Scripts \[Video\] \[ID 430473.1\]

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

*  判断错误发生所有的内存区域，是shared pool,large pool还是streams pool等。这个很容易从错误信息中判断出来，本文主要描述shared pool的ORA-04031错误，这也是最常见的。
 *  检查Shared Pool的总大小以及free memory的大小。如果free memory看上去挺多，以subpool为单位检查是否存在是由于碎片导致没有足够的连续内存以供分配，特别是关注报错信息中提及的子池。
 *  如果Shared Pool相较于系统规模来说足够大（通常数GB都已经是很大的了），检查Shared Pool中有没有占用非常多的内存类型或内存组件，如果有，是什么样的类型的内存，在各个子池之间是否分布均匀。如果有异常占用较多的内存类型，根据此类型在MOS上搜寻是否是会有相应的BUG引起，或者分析这种类型的内存消耗较多的原因。比如如果是sql area很大，检查是不是硬解析特别多，或者是不是child cursor特别多引起。
 *  基于以上分析的数据，来判断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的数据：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

1.  SQL> select sum(bytes)/1024/1024 mb from v$sgastat where pool='shared pool';  
2.    
3.          MB  
4.  \----------  
5.  4096.53062  
6.    
7.  SQL> SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ)  
8.    2  SIZ,  
9.    3  To\_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')|  
10.   4  |'k' "AVG SIZE"  
11.   5  FROM X$KSMSP GROUP BY KSMCHCLS;   
12.   
13. CLASS           NUM        SIZ AVG SIZE  
14. \-------- ---------- ---------- ------------  
15. R-freea         512      24576         .05k  
16. freeabl      807395 1643969848        1.99k  
17. recr         530728  662065240        1.22k  
18. R-free          256  214910976      819.82k  
19. free          43063  100605496        2.28k  
20. perm            140 1673368632   11,672.49k

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

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

1.  SQL> SELECT KSMCHIDX,KSMCHDUR, KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ)  
2.    2  SIZ,  
3.    3  To\_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')|  
4.    4  |'k' "AVG SIZE"  
5.    5  FROM X$KSMSP GROUP BY KSMCHIDX,KSMCHDUR, KSMCHCLS  
6.    6  order by 1,2,3;   
7.    
8.    KSMCHIDX   KSMCHDUR CLASS           NUM        SIZ AVG SIZE  
9.  \---------- ---------- -------- ---------- ---------- ------------  
10.          1          1 R-free           27   22666392      819.82k  
11.                       R-freea          54       2592         .05k  
12.                       free             26      14024         .53k  
13.                       perm             32  430299448   13,131.70k  
14.                     2 R-free           12   10073952      819.82k  
15.                       R-freea          24       1152         .05k  
16.                       free          10531   24519112        2.27k  
17.                       freeabl       44922   32457736         .71k  
18.                       recr         163177  134273584         .80k  
19.                     3 R-free            9    7555464      819.82k  
20.                       R-freea          18        864         .05k  
21.                       free           1678    4555704        2.65k  
22.                       freeabl       79815  102514024        1.25k  
23.                       recr          32689   36368096        1.09k  
24.                     4 R-free           20   16789920      819.82k  
25.                       R-freea          40       1920         .05k  
26.                       free           2182    5810056        2.60k  
27.                       freeabl       66235  254656184        3.75k  
28.                       recr          16245   58284480        3.50k  
29.          2          1 R-free           25   20987400      819.82k  
30.                       R-freea          50       2400         .05k  
31.                       free             23      20016         .85k  
32.                       perm             35  398418384   11,116.58k  
33.                     2 R-free            4    3357984      819.82k  
34.                       R-freea           8        384         .05k  
35.                       free           5137    6604176        1.26k  
36.                       freeabl       40377   12140944         .29k  
37.                       recr          54942   45005024         .80k  
38.                     3 R-free            9    7555464      819.82k  
39.                       R-freea          18        864         .05k  
40.                       free           1477    5524568        3.65k  
41.                       freeabl       79548  101879808        1.25k  
42.                       recr          32380   36033448        1.09k  
43.                     4 R-free           21   17629416      819.82k  
44.                       R-freea          42       2016         .05k  
45.                       free           2540    7092424        2.73k  
46.                       freeabl       70133  270332800        3.76k  
47.                       recr          15924   57263032        3.51k  
48.          3          1 R-free           26   21826896      819.82k  
49.                       R-freea          52       2496         .05k  
50.                       free             26      20520         .77k  
51.                       perm             33  414355416   12,261.94k  
52.                     2 R-free            4    3357984      819.82k  
53.                       R-freea           8        384         .05k  
54.                       free           4693    7053032        1.47k  
55.                       freeabl       49723   14339800         .28k  
56.                       recr          52771   42357312         .78k  
57.                     3 R-free           11    9234456      819.82k  
58.                       R-freea          22       1056         .05k  
59.                       free           3594    9280904        2.52k  
60.                       freeabl       95823  121934488        1.24k  
61.                       recr          39643   44097504        1.09k  
62.                     4 R-free           25   20987400      819.82k  
63.                       R-freea          50       2400         .05k  
64.                       free           2822    7291680        2.52k  
65.                       freeabl       84443  323149712        3.74k  
66.                       recr          19148   67997008        3.47k  
67.          4          1 R-free           27   22666392      819.82k  
68.                       R-freea          54       2592         .05k  
69.                       free             26      18088         .68k  
70.                       perm             40  430295384   10,505.26k  
71.                     2 R-free            6    5036976      819.82k  
72.                       R-freea          12        576         .05k  
73.                       free           4818   11473920        2.33k  
74.                       freeabl       46089   39963224         .85k  
75.                       recr          54061   44188072         .80k  
76.                     3 R-free            9    7555464      819.82k  
77.                       R-freea          18        864         .05k  
78.                       free           1427    4109504        2.81k  
79.                       freeabl       80026  102379080        1.25k  
80.                       recr          33217   36949240        1.09k  
81.                     4 R-free           21   17629416      819.82k  
82.                       R-freea          42       2016         .05k  
83.                       free           1993    6228464        3.05k  
84.                       freeabl       70581  269087136        3.72k  
85.                       recr          16614   59372656        3.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的数据：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

1.  ==============================  
2.  Memory Utilization of Subpool 3  
3.  ================================  
4.       Allocation Name          Size  
5.  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  \_\_\_\_\_\_\_\_\_\_  
6.  "free memory              "    81466568  
7.  "miscellaneous            "           0  
8.  "dpslut\_kfdsg             "         512  
9.  "trace buffer             "      737280  
10. "trace\_knlasg             "         504  
11. "gcs res hash bucket      "     1048576  
12. "gcs res latch table      "       12288  
13. "evaluation con           "           0  
14. "sql area                 "   344545752  
15. "UNDO STAT INFO           "       59904  
16. "txncallback              "      141744  
17. "transaction              "     2103264  
18. "ges resource pools       "        3968  
19. "sessions                 "     4526488  
20. "dlo fib struct           "      128032  
21. "KJCTS process batching st"         240  
22. "row cache                "        3272  
23. "KCB where statistics arra"       25888  
24. "KCB buffer wait statistic"       32000  
25. "KCB incremental ckpt entr"         512  
26. "invalid low rba queue    "        1024  
27. "table definiti           "      108704  
28. "temporary tabl           "        4136  
29. "KCL instance cache transf"      131072  
30. "resumable                "        2720  
31. "KESTB existence bitvec se"         128  
32. "type object de           "      392448  
33. "enqueue\_hash             "      318960  
34. "KSXR pending consumption "       20192  
35. "KTI SGA freeable small po"           0  
36. "trigger defini           "      885472  
37. "trigger source           "       99264  
38. "trigger inform           "         960  
39. "KTCN: Obj Invalidation Se"        2336  
40. "kmgsb circular statistics"      108800  
41. "kgl lock hash table state"       45360  
42. "kglsim size of pinned mem"        8024  
43. "kelr system metrics table"         280  
44. "kzctxgjsi ksuseclid memor"      117360  
45. "kzctxgjci ksuseclid  memo"           0  
46. "CCursor                  "    95912048  
47. "ksr message pool free que"      188960  
48. "ksb ci process list (each"         144  
49. "ksunfy: nodes of hierarch"         320  
50. "ksuloi: long op free list"         256  
51. "kwqmncal: allocate buffer"        4048  
52. "ksim group query request "           0  
53. "ksuxds ksuseclid  memory "           0  
54. "call                     "       87304  
55. "dictionary cache         "           0  
56. "KSXR pending reply queue "      255488  
57. "hng: All sessions data fo"           0  
58. "ksfv subheap descriptor  "         184  
59. "gcs resources            "   169082312  
60. "gcs affinity             "        8320  
61. "gcs opaque in            "       12312  
62. "PCursor                  "    50743128  
63. "ges resource             "      539376  
64. "fdrec\_kffsg              "          24  
65. "work area tab            "       80640  
66. "kglsim main lru count    "       38400  
67. "plwpil:wa                "        4264  
68. "grptab\_kfgsg             "        2464  
69. "AW SGA                   "          40  
70. "KEWS sesstat seg tbl     "           8  
71. "kebm slave descriptors   "        1456  
72. "kglsim hash table bkts   "     1048576  
73. "KSXR global channels     "        1288  
74. "ges enqueues             "    17333720  
75. "PLS chunk                "         352  
76. "KSQ event description    "        1440  
77. "KESTB existence bitvec   "        4096  
78. "gcs shadows              "   101246344  
79. "qmtb\_init\_data           "         224  
80. "Core dump directory      "         264  
81. "sort segment handle      "        7480  
82. "SERVICE NAME ENTRY       "          48  
83. "PQ/BizCard               "        1536  
84. "qtree\_kwqbspse           "          40  
85. "latch descriptor table   "        1576  
86. "recovery domain          "       29856  
87. "parameters               "       30056  
88. "SHARED SERVERS INFO      "         240  
89. "qtree\_kwqbsgn            "          40  
90. "post agent               "           0  
91. "pspool\_kfsg              "          80  
92. "plwsppwp:wa              "           0  
93. "PL/SQL DIANA             "    14050624  
94. "segmented arrays         "        2072  
95. "Checkpoint queue         "     4097024  
96. "sim lru segments         "        2560  
97. "sim segment hits         "        2560  
98. "sim state object         "          40  
99. "partitioning d           "      199616  
100. "ASH buffers              "     8388608  
101. "message pool freequeue   "      276336  
102. "PL/SQL MPCODE            "     4499360  
103. "PL/SQL PPCODE            "     3984944  
104. "procs: ksunfy            "     1512000  
105. "primem\_kfmdsg            "        1032  
106. "SYSTEM PARAMETERS        "       76624  
107. "object queue hash buckets"      262656  
108. "object queue hash table d"        7552  
109. "object level stats hash t"         512  
110. "object stat dummy statprv"         144  
111. "sim cache sizes          "         320  
112. "logout storm management  "       24000  
113. "pl/sql source            "       21256  
114. "sys event stats          "      199136  
115. "parameter handle         "       67896  
116. "Parameter Handle         "        1656  
117. "channel handle           "      828672  
118. "API blockers array       "          64  
119. "PARAMETER TABLE          "        2048  
120. "PARAMETER ENTRY          "           8  
121. "LGWR post requested array"          24  
122. "bloom filter             "        3104  
123. "param hash values        "        5984  
124. "sql area:PLSQL           "    11477776  
125. "PX subheap desc          "         256  
126. "repository               "      213544  
127. "sql area:KOKA            "       16192  
128. "archive\_lag\_target       "        9624  
129. "state objects            "         640  
130. "latch nowait fails or sle"      116832  
131. "sched job slv            "        5952  
132. "pso tbs: ksunfy          "      390000  
133. "dummy                    "      269928  
134. "Sort Segment             "       37440  
135. "Cursor Stats             "     6095760  
136. "Banner Storage           "        2048  
137. "quiescing session        "        3872  
138. "API data buffer          "          16  
139. "buffer handles           "     1020000  
140. "prmtzdini tz region      "      408320  
141. "sga node map             "          16  
142. "savepoints               "           0  
143. "Managed Standby Proc Arra"       24576  
144. "OS proc request holder   "        4664  
145. "db\_files                 "      416576  
146. "PX server msg stats      "        2288  
147. "KQR M PO                 "      283376  
148. "kks stats                "          40  
149. "parameter table block    "      483168  
150. "KSFV SGA                 "         824  
151. "plugin datafile array    "       36016  
152. "plwda:PLW\_STR\_NEW\_RVAL   "          24  
153. "plwspv:PLW\_STR\_NEW\_VAL   "          16  
154. "KGKP sga                 "          32  
155. "BRANCH TABLE SEGMENTED AR"       70176  
156. "mvobj part des           "      306544  
157. "parameter value memory   "         216  
158. "multiblock re            "       98496  
159. "parameter text value     "        1080  
160. "parallel\_max\_servers     "        8192  
161. "KGLS heap                "    13290800  
162. "KGSKI sga                "          80  
163. "resize request state obje"      368000  
164. "MTTR advisory            "     1462832  
165. "monitoring co            "       12480  
166. "rules engine aggregate st"        1416  
167. "krbmror                  "       36400  
168. "joxs heap                "         136  
169. "krbmrsr                  "         152  
170. "ksfqpar                  "        4008  
171. "SGA - SWRF DrvMet Runtime"        2656  
172. "SGA - SWRF Metrics ksuTim"          72  
173. "SGA - SWRF RawMet Runtime"        1408  
174. "SGA - SWRF Metrics WCTime"          32  
175. "SQL Memory Manager Base W"       13400  
176. "change notification regis"        4096  
177. "simulator latch/bucket st"       59392  
178. "Prefetch history buffer  "        2832  
179. "change notification obj m"        4096  
180. "KQR ENQ                  "       16512  
181. "kksss                    "       16464  
182. "API data buffer length   "           0  
183. "kokcd                    "           0  
184. "kohsg                    "           8  
185. "Sequence Background Insta"          88  
186. "ksfqpn                   "         416  
187. "KGLS SP                  "        4704  
188. "knstsg                   "          48  
189. "latch classes            "         352  
190. "system default language h"         568  
191. "name-service entry       "        2592  
192. "API data buffer array    "           0  
193. "kzull                    "        4096  
194. "kzulu                    "         392  
195. "kfgsga                   "         104  
196. "library cache            "    46604712  
197. "kcrrny                   "       25320  
198. "spfile cleanup structure "       16760  
199. "xssinfo                  "        5952  
200. "buffer\_pool\_desc\_array   "        3384  
201. "row cache child latch    "        3360  
202. "rm request queue link    "        5320  
203. "SCHEDULING POLICY TABLE  "         160  
204. "namhsh\_kfdsg             "        4104  
205. "Closed Thread SCN Bitvec "        8448  
206. "Client ID trace settings "        3872  
207. "osp allocation           "       21104  
208. "os statistics            "        9192  
209. "plwppwp:PLW\_STR\_NEW\_LEN\_V"          16  
210. "plwgc: plwgc\_garbage\_clea"           0  
211. "plwiiw: kglpql warnings  "           0  
212. "object queue             "      808080  
213. "obj stat memo            "      599184  
214. "obj htab chun            "      122960  
215. "object level             "      111888  
216. "XCT XGA                  "           0  
217. "SGA - SWRF Metric Eidbuf "      900840  
218. "Processor group descripto"          64  
219. "Prefetch client count per"          32  
220. "X$SKGXPIA                "        2680  
221. "simulator hash buckets   "     2101248  
222. "State object subpools    "         896  
223. "API data buffer length ma"           0  
224. "AWR Table Info (KEW layer"         872  
225. "character set memory     "        4856  
226. "sim segment num bufs     "        1280  
227. "character set object     "      129728  
228. "session idle latches     "        2560  
229. "qesmmaInitialize:        "         112  
230. "returns from remote ops  "       49152  
231. "name-service             "        4080  
232. "SGA - SWRF Metric CHBs   "       10912  
233. "listener addresses       "          32  
234. "db\_block\_hash\_buckets    "    67108864  
235. "KSI resource types       "        2704  
236. "kglsim object batch      "     4196304  
237. "trigger condition node   "          72  
238. "ksws service events      "       18560  
239. "Heap0: KGL               "    11642128  
240. "fixed allocation callback"         392  
241. "kqlpWrntoStr:value       "           0  
242. "KEWS statistic name      "         424  
243. "KEWS statistic maps      "        1096  
244. "KCL partition table      "      131072  
245. "kebm slave message       "          88  
246. "kcbl state objects       "       12800  
247. "free rm request queue lin"           0  
248. "xsoqsehift               "        3104  
249. "DBWR event stats array   "         192  
250. "kgllk hash table         "      659456  
251. "event descriptor table   "         192  
252. "kpssnfy: kpsssgct        "          32  
253. "kpscad: kpscscon         "        1952  
254. "dbwriter coalesce buffer "     3158016  
255. "kglsim hash table        "        8208  
256. "gcs resource freelist dyn"         256  
257. "gcs shadow locks dyn seg "         256  
258. "kks stats latch          "         160  
259. "KTC latch cleanup        "         576  
260. "ges enqueue max. usage pe"          64  
261. "ges lmd process descripto"        2760  
262. "KTU latch cleanup        "        2496  
263. "kscdnfyinithead          "          16  
264. "X$KSVIT table            "         512  
265. "kqlpaac:value-1          "          64  
266. "KCL buffer header        "      192064  
267. "kxfpdp pointers          "       28800  
268. "kodosgi kopfdo           "         104  
269. "kglsim latches           "         136  
270. "TXN TABLE SEGMENTED ARRAY"       54784  
271. "KJCT remote i            "        1640  
272. "KKJ SHRD WRQS            "         288  
273. "KJC dest ctx             "        3560  
274. "kwrsnfy: kwrs            "        1624  
275. "kwqmn:tskdata            "           0  
276. "KKKI consumer            "        4136  
277. "dbwr suspend/resume ptr a"          16  
278. "dbwr actual working sets "          64  
279. "KGSKI schedule           "           0  
280. "temp lob duration state o"        3296  
281. "ges regular msg buffers  "     3078008  
282. "jsksncb: 9               "       28672  
283. "Transportable DB Converte"        2552  
284. "KTU lat struct           "         800  
285. "kks stats hds            "         256  
286. "KSFD SGA I/O b           "     4190248  
287. "HTTP fixed headers       "          72  
288. "UNDO INFO SEGMENTED ARRAY"      649856  
289. "ges process hash table   "      132000  
290. "jsksncb-latch            "        1280  
291. "kfkid hrec               "          24  
292. "KTCCC OBJECT             "           0  
293. "KTPR HIST TB             "        2808  
294. "KTF MAPPINGS             "       12288  
295. "kksss-heap               "       35136  
296. "kglsim heap              "     3431232  
297. "event statistics per sess"     7665280  
298. "eventlist to post commits"          16

从上面的数据可以看到，第3个sub pool中，占用较多的内存是gcs resources、gcs shadows以及sql area。但是没有明显的异常。  
下面是第3个sub pool中第1个mini-heap中free memory的更详细数据：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

1.  SQL> break on ksmchidx on ksmchdur  
2.  SQL> select  
3.    2    ksmchidx,ksmchdur,  
4.    3    case  
5.    4          when ksmchsiz < 1672 then trunc((ksmchsiz-32)/8)  
6.    5          when ksmchsiz < 4120 then trunc((ksmchsiz+7928)/48)  
7.    6          when ksmchsiz < 8216 then 250  
8.    7          when ksmchsiz < 16408 then 251  
9.    8          when ksmchsiz < 32792 then 252  
10.   9          when ksmchsiz < 65560 then 253  
11.  10          when ksmchsiz >= 65560 then 253  
12.  11     end bucket,  
13.  12    sum(ksmchsiz)  free\_space,  
14.  13    count(\*)  free\_chunks,  
15.  14    trunc(avg(ksmchsiz))  average\_size,  
16.  15    max(ksmchsiz)  biggest  
17.  16  from  
18.  17    sys.x$ksmsp  
19.  18  where  
20.  19    inst\_id = userenv('Instance') and  
21.  20    ksmchcls = 'free'  
22.  21  group by  
23.  22    case  
24.  23          when ksmchsiz < 1672 then trunc((ksmchsiz-32)/8)  
25.  24          when ksmchsiz < 4120 then trunc((ksmchsiz+7928)/48)  
26.  25          when ksmchsiz < 8216 then 250  
27.  26          when ksmchsiz < 16408 then 251  
28.  27          when ksmchsiz < 32792 then 252  
29.  28          when ksmchsiz < 65560 then 253  
30.  29          when ksmchsiz >= 65560 then 253  
31.  30     end ,  
32.  31    ksmchidx, ksmchdur  
33.  32  order by ksmchidx , ksmchdur  
34.  33  /  
35.   
36.   KSMCHIDX   KSMCHDUR     BUCKET FREE\_SPACE FREE\_CHUNKS AVERAGE\_SIZE    BIGGEST  
37. \---------- ---------- ---------- ---------- ----------- ------------ ----------  
38.          3          1          5         72           1           72         72  
39.                               13        136           1          136        136  
40.                               27        248           1          248        248  
41.                               48        416           1          416        416  
42.                               56       1920           4          480        480  
43.                               66       1680           3          560        560  
44.                               68       4608           8          576        576  
45.                              164       1344           1         1344       1344  
46.                              180       1472           1         1472       1472  
47.                              188       1536           1         1536       1536  
48.                              190       1552           1         1552       1552  
49.                              199       1624           1         1624       1624  
50.                              204       1880           1         1880       1880  
51.                              207       2032           1         2032       2032

可以看到，最大的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，但是正如前面所说，这种方法有比较大的缺陷。

[view plain]: http://www.laoxiong.net/an-ora-04031-case.html#
[Simplified Approach to Resolve ORA-4031]: http://askdba.org/weblog/2008/07/simplified-approach-to-resolve-ora-4031/