一个Oracle server process进程会消耗多少内存?

Posted by boypoo on April 19th, 2015

做运维的兄弟有时候是挺悲催的,动辄就被开发或者应用的同事问,你们数据库是怎么回事,我的应用又不能用了!

其实好的运维,前提是要有好的开发,至少是要有善于改变,愿意改变的开发。

我们在做服务器配置规划,涉及到内存的时候,都会考虑下操作系统自身的内存、SGA、PGA、所有连接到数据库进程消耗的内存、其他应用进程消耗的内存。

这中间,不太好估算的是server process消耗内存的估算。从我们在电信、金融这样一些相对比较大的系统使用来看,HPUX下(11g)每个server process进程大概在10M~12M之间,HPUX下大概在10M~20M之间。有些进程如果只是连接,没有产生过任何查询或者DML的话,消耗的内存可能低于5M。

也因此,一旦应用上线后,遇到内存“不够”,某些个别程序遇到问题时,运维就会被challenge,这些应用以前都是好好的,为什么不行了?

 

有个新的例子是这样的,一个批处理的进程,消耗了50G内存,居然都没有跑完。

过程代码是这样(仅更改了敏感内容):

SQL> DECLARE
  2
  3  TYPE TP_RRRIDTP_RRRIDTP_RRRID             IS TABLE OF VARCHAR2(50) INDEX BY BINARY_INTEGER;
  4  TYPE TYPE_XC_CODE           IS TABLE OF ACTUARY.TBL_TRAD.XC_CODE%TYPE INDEX BY BINARY_INTEGER;
  5  VV_RRRID                     TP_RRRIDTP_RRRIDTP_RRRID;
  6  V_XC_CODE                   TYPE_XC_CODE;
  7
  8  BEGIN
  9
 10
 11
 12  SELECT A.ROWID,B.XC_CODE BULK COLLECT INTO VV_RRRID,V_XC_CODE
 13  FROM ZBCS.TBL_UL A,
 14       ZBCS.CLASSCODE_SUM B
 15  WHERE A.XZCODE = B.XZCODE
 16  AND A.GSCODE = ‘SHH’
 17  ;
 18
 19  FORALL I IN VV_RRRID.FIRST..VV_RRRID.LAST
 20
 21  UPDATE ZBCS.TBL_UL
 22  SET XC_CODE = V_XC_CODE(I)
 23  WHERE ROWID = VV_RRRID(I);
 24  COMMIT;
 25
 26  DBMS_OUTPUT.PUT_LINE(TO_CHAR(SYSDATE,’YYYY-MM-DD HH24:MI:SS’));
 27
 28  END;
 29  /
DECLARE
*
ERROR at line 1:
ORA-04030: out of process memory when trying to allocate 1917720 bytes (PLS
non-lib hp,DARWIN)
ORA-06512: at line 19

这个表本身虽然不算太大,半个月的时间增长近2000万,其中一个分区接近一半的记录。在查询小分区的时候语句没有问题,但是查询最大这个分区数据的时候就ORA-04030.

当然,改进的方法不难,在fech的时候加以limit限制(5000或者10000都可以)即可。

要说的是,类似的应用写法,在不同的开发商中,确是普遍存在的。好的开发干个2-3年就跳槽或者升职了,写这样代码的人总是新手,出了问题总是运维在熬夜分析(你不能总是一上来就指出开发有问题啊,他们有惯用的语句:我们什么都没改啊,以前跑的好好的!所以要通过各种分析,拿出证据,就是他的问题)。

那么,一个oracle连接进程到底消耗多少内存呢?当然实际的只能从V$process去查了。上面的通用粗糙算法大体也没有问题。

问题在于,你不能让开发帮你捣蛋。

怎么破?

对开发代码进行审核评估是一个方法,我们目前在做。

但是,如实的说,做起来,由于前端“客户”客户的功能需要,开发老板要满足需求,运维老板如果不够强硬,还是举步维艰的。

好的情况是,之前是“功能驱动开发”,现在逐渐兴起的“测试驱动开发”已经使状况变得越来越好了。

 

 

2014年年终总结

Posted by boypoo on January 1st, 2015

说是时间跑得太快,仍然有时间是自己浪费的,好在我渐渐地唤醒自己了,虽然慢了一些。

2014年做得最不好的事情有两件,一个是跟家人和老朋友的沟通不多,很长时间不沟通了,就有点渐渐的害怕沟通起来,一来二去几个月都不沟通,明天,就在明天,要像《我家买了动物园》的主角说的一样“鼓起勇气的20秒”,开始跟朋友们联络起来;一个是承诺了的书,没有写完,更多是能力的原因,我想写出去的书还是要对得起读者,在写的过程中发现难度确实很大,因为没有人写过这方面的书,明年一定会写完。

有几件值得开心的事:更多优秀的同事进入我的团队,特别是其中一员等了整整两年,结果证明等待是值得的;虽然从04年开始组建团队带团队,甚至也考了PMP,读了MBA,但我要说的是今年我觉得自己找到一些带团队的感觉了,2014年我们一起走过,相信2015年你们会发现跟我更加容易沟通,我们的目标也会实现得更顺利些;客户的拓展也取得了突破,多年的种籽总有发芽的时候,只要我们还是诚心相对,明年应该是茁壮成长。

2015要做的事:

1、首先是个人的,减肥。好吧,我承认之前都是亲人、朋友们要求我减肥,今天是我自己想减了,目标,从80KG降低到70KG,时间2015年10月1日。

2、团队,还需要更多优秀的伙伴加入,上海、合肥、济南、南京,你有激情、想靠自己的努力完成自己的心愿,勤奋好学,找我吧。相信有你们的加入,2015会更加有趣有成就感。

3、14年没完成的写作,15年继续接一本翻译Tom kyte大神的《深入浅出Oracle体系结构 第三版》。

4、坐一次邮轮,平生第一次用一下护照,目的地和时间待定。

你相信我能完成么?

有你的鼓励与支持,我相信,没有问题。

《Oracle核心技术》第二次印刷勘误

Posted by boypoo on May 14th, 2014

先说翻译小组的事,目标是翻译那些有用的Oracle基础文档,QQ群:301189430

加入之前先按英文格式提交一章翻译稿:http://docs.oracle.com/cd/E11882_01/server.112/e41573/perf_overview.htm#PFGRF025

Read the rest of this entry »


Copyright © 2007 数据工人. All rights reserved.