April 16, 2007
将在阿里巴巴"中国网络工程师侠客行"大会演讲
作者:eygle
出处:http://blog.eygle.com
感谢Piner和Biti以及诸位阿里朋友的推荐，下个月将要出席阿里巴巴举行的“首届中国网络工程师侠客行大会暨中国互联网技术精英论坛”。
关于这个大会，Fenng和Chedong都已经做过了宣传：）
关于大会这个名字-“首届中国网络工程师侠客行大会”，我觉得颇值得商榷，如果断句为"首届中国网络，工程师侠客行大会"则更为妥当一些，如果是“网络工程师”，被狭义解读，则可能会让大家觉得范围有些歧义。
在这次大会上，会议主办方为我安排了一个讲演时间，关于这个讲演题目颇费了一番思量，阿里是一个DBA高手云集之地，到这样的地方演讲对我实在是一个考验，周末陪着老婆在公园里转了两天，还不时思考这个题目的问题；直到今天下午再次收到阿里的MM催促的邮件，才蓦然想到一个题目：Oracle Database 10g：开启全方位性能优化的时代
最近在写作我的新书，对于Oracle10g的很多变革及巨大改进有了更深一步的体会，有时候不禁为Oracle的某些想法及技术规划拍案叫绝，所以趁此机会，把自己的一些体会和大家就此分享一下吧。这个演讲将是框架性及细节性的一个结合，对于非技术人员，我希望大家能够了解一下Oracle的优化结构及变迁，这个是具有普遍参考意义的；对于Oracle技术人员，我则可以和大家分享一下我的一些有意思的思考和研究。希望能把这个普通的题目讲出一点新东西。
当然参加这次会议最主要的，可以在人间天堂的杭州，相会众多的老朋友。
国内的技术会议慢慢多了起来，这真是一个好的现象，几个月内我参加过的就已经有：
2006年12月1日，中国软件技术大会
2007年1月19-20日：2007中国开发者精英论坛-暨ITPUB/IXPUB年会
2007年4月6日：2007中国软件技术英雄会-暨CSDN社区英雄榜颁奖典礼
ITPUB和CSDN的大会都是以社区为主，而阿里这次大会明显规模要更庞大，嘉宾也全是重量级人物（除了俺），看看会议的名字也要气派了许多：
2007年5月19-20日：首届中国网络工程师侠客行大会暨中国互联网技术精英论坛”
希望通过这些会议的组织和推动，中国的技术气氛能够慢慢成熟起来。也同时预祝“侠客行”大会能够圆满成功。
对了，马云有没有考虑给每个参会嘉宾分配一个侠客id呢？
-The End-
Posted by eygle at 3:51 PM | Comments (12)
DBA警世录:Oracle的共享内存段
作者:eygle
出处:http://blog.eygle.com
最近看到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 -ef|oracle 服务都没了
由于脚本中缺少必要的判断，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-
Posted by eygle at 11:59 AM | Comments (2)