>首页 > 电脑技术 > 数据库> > 正文

Oracle的共享内存段

最近看到ITPUB上有这样一个帖子,觉得有点意思,收录一下,以为借鉴。 这位朋友的Apache和Oracle运行在同一台主机上:  平台是redhat as 3 ,oracle 9204.  其他应用是apache,resin等。 因为以前发现apache运

    最近看到ITPUB上有这样一个帖子,觉得有点意思,收录一下,以为借鉴。

    这位朋友的Apache和Oracle运行在同一台主机上:

  平台是redhat as 3 ,oracle 9204.

  其他应用是apache,resin等。

    因为以前发现apache运行时间长以后会出现共享内存不足的错误,具体错误信息如下:

[Fri Apr 13 06:00:03 2007] [error] shm.create(): error creating shm 2 No sUCh file or Directory
[Fri Apr 13 06:00:03 2007] [error] shm.create(): error creating shm /home/apache/logs/shm.file
[Fri Apr 13 06:00:03 2007] [warn] pid file /home/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
[Fri Apr 13 06:00:03 2007] [emerg] (28)No space left on device: Couldn't create accept lock

    为了解决这个问题,这位同学的解决方法是:

  因此,我写了一个脚本,来定时检测并清理。一直很有效。

    当Apache和Oracle跑在同一台主机上时,这个脚本就出现了Bug:

  前一段时间,新开了一个小应用,也是apache的应用,由于没地方放了,就放到oracle机器上了,一直运行比较好;

  今天早上接到信息,说新开的这个apache应用服务停止了,打开log一看,又是共享内存的问题,二话不说,把原来的脚本在系统上跑了一遍,restart apache,ok。系统可以了。

  过了几分钟。问题大了,说oracle服务宕了。赶紧检查,ps -eforacle 服务都没了

    由于脚本中缺少必要的判定,Oracle的共享内存段也别清除,所以Oracle数据库也挂了,alterlog文集中记录了如下信息:

Errors in file /opt/oracle/admin/sc1/bdump/sc1_reco_5195.trc:
ORA-27157: OS post/wait facility removed
ORA-27300: OS system dependent operation:semop failed with status: 43
ORA-27301: OS failure message: Identifier removed
ORA-27302: failure occurred at: sskgpwwait1
Fri Apr 13 10:10:46 2007
Errors in file /opt/oracle/admin/sc1/bdump/sc1_smon_5193.trc:
ORA-27157: OS post/wait facility removed
ORA-27300: OS system dependent operation:semop failed with status: 43
ORA-27301: OS failure message: Identifier removed
ORA-27302: failure occurred at: sskgpwwait1
Fri Apr 13 10:10:46 2007
RECO: terminating instance due to error 27157
Fri Apr 13 10:10:46 2007
Errors in file /opt/oracle/admin/sc1/udump/sc1_ora_23824.trc:
ORA-27153: wait operation failed
ORA-27300: OS system dependent operation:semop failed with status: 22
ORA-27301: OS failure message: Invalid argument
ORA-27302: failure occurred at: sskgpwwait2
Fri Apr 13 10:10:46 2007
Errors in file /opt/oracle/admin/sc1/bdump/sc1_lgwr_5189.trc:

    Oracle数据库是需要再系统上分配共享内存段的,这个是基本的常识,在故障之后,这位同学才想起来:

[root@oracle]# ipcs -s ------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 4849664 nobody 600 1
0x00000000 4882433 nobody 600 1
0x00000000 4915202 nobody 600 1
0x00000000 4947971 nobody 600 1
0x00000000 4980740 nobody 600 1
0xbeae576c 5111813 oracle 640 201
0xbeae576d 5144582 oracle 640 201
0xbeae576e 5177351 oracle 640 201
0xbeae576f 5210120 oracle 640 201
0xbeae5770 5242889 oracle 640 201
0x00000000 5275658 nobody 600 1
0x00000000 5308427 nobody 600 1
0x00000000 5341196 nobody 600 1
0x00000000 5373965 nobody 600 1
0x00000000 5406734 nobody 600 1
0x00000000 5439503 nobody 600 1
0x00000000 5472272 nobody 600 1
0x00000000 5505041 nobody 600 1

  果然有oracle的共享内存,而我的脚本没有判定。假如只是删除apache用户的共享内存,可以这样 ipcs -s grep apache perl -e 'while () { @a=split(/s+/); print `ipcrm sem $a[1]`}' 假如大家谁的应用和我这个类似,一定注重。

    其实这个故障还是一个低价的故障,首先假如我们在不同的服务器上运行同一个脚本,严谨的做法是需要经过检查、测试,以确认其正常运行性,未经过测试靠猜想是不值得信任的。

    其次,作为严谨的一个方面,权限及运行脚本的用户身份是需要明确的,root用户执行任何操作都相当危险,应该慎之又慎。我在有些习惯DBA需要养成一文中对这方面曾有探讨。

     话又说回来,假如这是一个重要的业务数据库,这样的操作引发的故障将是极为恐怖的(当然重要的系统这样的错误基本上也不会发生),所以作为一个DBA应该对自己的行为三思、多思而后行。 -The End- -----

内存
加载更多