西宁旅记:管中窥豹

6月11日5点天刚蒙蒙亮，极不自然地醒过来，因为要赶飞机的缘故又是一夜没睡好；从家中打车到浦东机场需用一个多小时，抵达时已经6点半了，我要搭乘7点50分的飞机，自上海出发到西安转机到青海西宁。这次是公司在开拓青海省期间的一次技术交流，对象是西宁市的一家政府下属单位。

早晨的浦东机场已经十分忙碌，考虑到是世博期间人流更胜往常；这里是大魔都一处永不停歇的驿站，在这里人流喷涌，为这个国家带来所有未知机遇。

一行无话，11点40分抵达西安，西安的机场还是挺大的，至少在西部诸省仍是佼佼者；我一直很向往这个古老城市：秦，两汉，唐;这个城市记录了中华最辉煌的年代，在我心目中这种气度不是帝都所能比的，不过这次是无缘游访了。

1点钟不到终于到达目的地，青海省西宁市这个边陲省会；从机场向外看去一望无际的土山让生长在上海没有出过远门的我有些惊讶，西宁机场不大，虽然离地震已经过去一段时间了但仍到处插着”青海长青，玉树不倒”的标语，西宁机场目下正在扩建，灾后重建需要一个现代化的机场。

落地后赶忙和负责西北地区的张，胡两位取得了联系，他们下榻在中心广场的如家，据说是此地的市中心，而自机场打的到市区则似乎是统一的一百元；西宁市的的士规格参差不齐，但车顶上大大的广告牌似乎要比上海的还要先进，部分的士甚至是私家的车子，起步费统一的6元；上车前最好问清楚是否能给发票，不然可能会很麻烦。

载我的那位的哥十分健谈，据他介绍青海自古是移民地区，目前是以汉族为主，而部分口音类似于南京周边的方言。青海亦是三江源头为长江，黄河，澜沧江的源头汇水区，比较好玩的景区有青海湖和贵德，土产有牦牛干，人参果，裸鲤，毛毯等。谈话中时间过得飞快，期间途遇到2个收费站，让我对外地的路费有了新的认识。进入城区后先上到高架，大致可以一览市区全貌，据司机师傅介绍目前西宁市区的房价是在6千左右，要想在此处安家却也不容易啊！

在城区里穿行片刻就抵达了旅馆，与本地的2位从未谋面的同事寒暄过后，自然是要先祭祭五脏的；他们带我去旅馆旁边一个样式古老的美食城就餐，西北向来以面食出名，古来就说西北的水偏碱做面食十分相宜，其名声远胜南方，此外就多是牛羊肉，大盘鸡之属了。牛羊肉做主食，南方人多半受不了，我点了一叠面，口味尚佳，比起上海六七元的阳春面这里要便宜得多了。

吃完饭匆匆赶赴客户单位，路上竟堵了许久，想不到此处下午1点多也会有rush hour。

来到客户单位已是2点多，从客户的张科长，朱工程师口中大致了解了系统规模，这里主用的一套Linux上的RAC系统共有3个节点，硬件是三台Dell的3950 Pc Server以及一台IBM DS4700存储，三个实例接受不同地区的业务，客户目前对这套RAC系统的性能不顶满意，希望此次技术交流能够提出初步的方案，另外他们对与主机上较高的内存使用率表示疑问。

我首先抓取了RDA以及AWR报告，托福于这些工具Oracle的诊断调优信息收集已经十分集成了。这个系统居然还采用了ASM,Linux上RAC系统大致可以采取以下几种存储管理方式:裸设备(最容易也最麻烦),NFS(生产环境无法用),ASM(Oracle 推荐),OCFS2(11g被抛弃了),其他GPFS(譬如RedHat GPFS,Veritas Cluster Filesystem);10g下最时髦的管理方式还属ASM,ASM技术新颖，但普遍认为10gASM还不够成熟，至少客户应用上经验不足，一旦出现问题，除了向Oracle GCS求助外很少能找到其他解决方法。而且这套ASM系统直接使用形如/dev/sd*的块设备作为disk，不同于裸设备，使用块设备将会引起操作系统对块的进一步缓存(OS CACHE)，这套系统除了跑数据库外没有其他应用，总内存为24g而每个实例使用的SGA不足5g,绝大多数内存都用作了缓存块设备。

[oracle@qhds2 ~]$ free
total       used       free     shared    buffers     cached
Mem:      16408324   16276472    131852          0      44184   13969312
-/+ buffers/cache:    2262976      14145348
Swap:      2031608      90224    1941384

如上所示空闲物理内存131852即128M,OS cache为13G。Oracle使用的高速缓存(Buffer_Cache)要较OS的cache更为有效，而目前三个实例设置的Buffer_cache为2-3G不等，建议客户调大Buffer_Cache至5-10G，同时为杜绝操作系统因物理内存不足，瞬间换页造成宕机事件发生的可能性，建议客户将Linux内核参数vm.min_free_kbytes 设置为512000(即总是保留500M的空闲物理内存)。

数据库中三个实例，整体负载(Load)处于较低的水平。相对而言1号实例最高,16小时快照内1号实例上Average Active Session（平均活动会话数，为10g中数据库负载的重要指标）为(AAS=DB_TIME/Elapsed=2327/960)2.42；2号实例上AAS为592/960=0.61；3号上AAS为1405/960=1.463。
分析AWR 报告可以发现：

1号实例:

2号实例:

3号实例:

主要的几个等待是:

• ENQ:TM- Contention
• Gc cr multi block request
• CPU-TIME

“Gc Multi Block request”为全局缓存多块请求事件，是一种集群类等待事件。当RAC中每个实例所涉及的数据严重交叉时该事件将成为数据库的主要性能瓶颈。在不能通过改善应用程序集群适应性或对表进行实例划分分区的情况下，建议客户将RAC中的多个实例划为主用和备用实例以获取更好的性能。举例来说可以将硬件性能较好的一号主机作为主用主机，而二三号主机作为备用主机平时不接受应用程序会话，在一号主机需要OFFLINE时做应急用。客户使用RAC系统的最主要目的是为了获取高可用性，而通过向客户解释RAC Global Cache大致的工作原理后，客户首肯了这个方案。

EnQ:TM-Contention即TM锁队列等待，一般是应用程序对表执行共享级以上的表锁时(包括:S,SSX,X锁)且锁定时间过长或表上有外键约束引起的，大多数OLTP类型应用中对整个表的S,SX,X锁是不必要的，只需要行级锁(ROW LEVEL LOCK)即可以满足需要。客户本身也在怀疑应用程序存在问题，但苦于没有有力证据，无法督促开发商修改程序，又因为目前这套应用数据量，业务量都较小，这种矛盾仍不尖锐，所以总是没有行之有效地整改。

讨论完这些已将界6点，匆匆和同事回旅馆吃了晚饭。趁着天还没彻底晚，打的找了当地一个专卖土特产的超市，因为不想回去是负重过高，随便买了几包牦牛干，人参果。这忙碌的一天也就算完了，回旅馆睡觉！

第二天早晨抓紧时间再赶到客户处，另看了一套系统，因为要赶下午2点的飞机，所以行色匆匆，客户平常是使用本地java客户端的EM和10g上web形式的EM监控数据库的，在机房中的笔记本上使用SYS用户可以成功登陆，但在科室里的台式机上登陆就报用户名/密码错误的信息，初步怀疑是设置了SQLNET.ORA的某些参数，由于时间无多，这个问题只能摆脱后续的工程师解决了，呵呵！

回程仍需到西安转机，不过由于机票订得晚，经济舱已经满座了，十分不巧地做了会头等舱，也算一种福利吧。

呵呵，西宁二十四小时，对这个城市管中窥豹了！