最近看到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- -----
