上篇说了一个cx700与powerpath的故事，既然写了，那么也把另外一个故事写下来，个人感觉，这个故事或许比上一个故事更有意思，也更有借鉴意义，因为在实际工作中，可能会经常遇到。

故事的起源就在于我们的HA的aix主机，以前只有一块光纤卡通过一个光纤交换机连接到cx700。现在，找IBM再买了一块光纤卡，准备安装上去，通过另外一个光纤交换机连接到cx700，把双通道路径扩展成为4通道路径。

既然是HA的机器，停机问题不大，找一个晚上，约上IBM的工程师，Dell的工程师，恩，就是我上篇说到的那个很会电话的工程师，这次他表现一样不错，我们一起去了机房。

我们的想法是感觉比较容易的，不就是如下步骤末：

1、在IBM主机里面插上新卡

2、IBM主机认到卡，并状态正常

3、光纤交换机那里认到卡，能获得WWN

4、把光纤交换机的zone配置一下，加入新的卡的WWN或者是port，并enable配置

5、检查cx700的连接状态，现在是不是4个连接

6、主机上重新认盘，应当就是从以前的2个路径变成4个路径了

当然，有这么简单，就没有下面的故事了。

1与2都很正常，3的时候，如果是先认卡，再接的光纤线，主机这里需要再执行cfgmgr，其实就是给光纤交换机发一个信号，否则，光纤交换机认不到卡的WWN，这个也没有费什么时间就过了。步骤4我配置通过，步骤5，我与dell的工程师都检查了，连接状态那里的确是4个路径，都正常了，那么，开始步骤6。

我们先用rmdev -dl删除了以前的阵列上认到的盘，用cfgmgr -v去认，发现只有2条路径，甚至下了狠招，rmdev -Rdl fcs(x)，把整个光纤卡都删除了，重新认，还是只有2条路径。我们就开始郁闷了，于是dell的工程师开始打电话，我们开始继续检查。

·光纤交换机肯定正常，可以看到所有的光纤卡。

·zone的配置肯定也没有错，配置都enable了

·路径肯定正常，cx700上可以看到4条通道都正常

dell的工程师电话的同时，还不忘记问IBM的工程师，“我们那里都正常，应当是你们的问题”

IBM的工程师说，“盘都认不到，应当是你们哪里的问题”

时间就这么过去了，我在想是哪里出了问题呢，其实，也就是突然间，想到会不会是cx700的store group那里有问题，正常来说，store group只是决定了哪个主机能访问哪些lun，应当不会有问题，但是，现在能与主机扯上关系的，只有他了。立即行动，我先把主机上所有的阵列盘删除，然后我把HA的主机从store group中踢了出来，确定一下。再放进去，确认，主机上重新认盘，正常了。

dell的工程师还在电话呢，我与ibm的工程师于是一起叫道，“兄弟，别打电话了，已经好了”。

这个问题是好了，发现了一个新的问题，因为我们删除的太猛，认出来的硬盘都没有PVID以及VG信息了，而这个是HA的机器，这些硬盘其实都是正在使用的，无法使用常规的方法获得PVID与VG信息，也就是说，我们不能使用正常的importvg来导入VG，也没有办法使用chdev -l hdiskpower(x) -a pv=yes的方法获得PVID与VG信息。
怎么办？这下好了，dell的与ibm的工程师都去寻求帮助去了。

寻求帮助没有什么成果，那我只能来狠的了，因为HA的机器不能执行importvg的原因，就是因为主节点也正在使用这个VG，那么临时解除这个锁不就可以了。

    主节点：varyonvg -b -u vgname                      ###解锁
    HA的机器：importvg -L vgname hdiskpower(x)         ###读入信息
    主节点：varyonvg vgname                            ###加锁

注意，以上的操作具有风险性，特别是并发系统，如RAC上是不能随便解锁的，就是单节点，解锁操作也要小心谨慎。因为我们这里在晚上，压力小，而且时间短，关系就不大了。

经过以上的操作，HA也终于正常了。再仔细想想整个经过，其实，我们就是忽略了store group那里，我估计是store group把路径信息给记录进去了（或者是缓存起来了），因为它才是最终决定什么主机可以使用什么LUN，但是他不应当决定路径个数的。而第二个问题的出现，则是因为我们急于解决第一个问题，采用了一些非常规的操作才出现的。

其实，这个问题，也不仅仅是dell的工程师没有现场解决能力，在今年的cx3-80的测试上，emc的工程师遇到同样的问题时，一样束手无策。这里说到cx3-80，其实就是cx700的一个乘以2的翻版，把前后带宽，cache容量，磁盘最大连接个数都翻了一倍，但是后端的环路并没有增加，所以，如果追求高带宽的话，是一个不错的产品，如果追求IOPS，则需要考虑一下。

这次的测试，我们中途需要更换一个光纤卡（准确的说，是4台机器的RAC，每个机器要换一张光纤卡），我徒弟与2个EMC的工程师就过去了，到下午快下班的时候，我问我徒弟进度怎么样，他说EMC卡在那里了，已经2个小时了，我问什么原因，他说新换的卡，光纤路径认不到，emc的工程师正在向总部寻求帮助。后来知道，这两个工程师是比较年轻的工程师，还没有什么经验。

我晕，同样的问题，在cx3-80上同样存在。

我说，你让他们别打电话了，我知道怎么回事。

之后，我让他们把主机从store group中拿了出来，确认后再放进去，之后，他们告诉我，有2台主机正常了，但是2台主机不正常，ft，确认他们的操作也没有问题以后，我说，你们把ip给我，我登陆进去看看。

登陆到cx3-80，我检查了一下连接状态，才发现，原来他们这台cx3-80已经给N多人做过测试，连接状态里面全是乱七八糟的主机光纤卡，我看了看那两台不正常的主机，连接状态都不对，存在一定冲突，当然改store group是没有效果了。我先把那些乱七八糟的，以前注册进来的光纤卡，先全部删除，然后重新注册这两台机器的光纤卡，OK，正常了，为了确保没有问题，我把store group再操作了一次，让他们在主机上认一下，不久，他们告诉我，都正常了。

问题其实并不复杂，知道的人都简单，不知道的人都复杂，就是这样，往往是你觉得最不容易出现问题的那里，出现了问题。

应IT168编辑的盛情邀请，我最终还是决定写一篇我的存储故事，不象别人恢复多少多少数据那么紧张，那明显就是管理问题与规划问题，我这里也肯定没有这样的故事，因为不允许出现这样的故事。那么，我就把故事定位在了一个很小的故障解决上，这个事情不大，但是拖了我很长时间，也最终直接导致了我对EMC CX系列操作的非常熟练，包括上架、连接、升级存储的软件版本、改变任何配置等等操作。

本文既然投稿给了IT168，那么版权就归IT168所有，转载需要注明IT168的版权。

故事起源

在早先的时候，公司大量使用过EMC的Cx系列，不过，这些设备都是从dell那里买进的，也叫Dell EMC。那是一个什么样的时代啊，我们基本上对san与存储是一无所知，而Dell呢，虽然服务是好的，技术则是一般的，所以，第一个来给我们安装配置san的dell工程师，据说因为3天都没有配置成功，被fire掉了。

而正式开始重视san，还是在一次事故以后，有几台san环境中的机器，需要搬迁，之前我们把光纤线都做了标记，但是，可能是标记出了问题，真正再插入光纤线的时候，认不到原来的硬盘了。

痛定思痛，我们决定自己掌握存储技术，从一无所知，到现在能在san，存储产品上了解这么多的东西，很多都是自己经验的积累。下面我就描述我的经历中的，一个cx700软件版本与powerpath版本之间的小故事。

1、发现问题

问题的起因是我们安装了一台cx700的存储到一个新的aix主机上，dell的工程师直接在主机上安装了当时最新的powerpath版本，PP4.5，据说是一个比较稳定的版本，而之前我们用的都是PP4.2。当一却都做好之后，我开始测试存储的速度了，发现一个问题，存储的写速度怎么也上不去，最多每秒只有60M左右。

这个速度不是cx700的表现，然后，我们就开始找问题，最初的时候，怎么也没有想到powerpath，我们先检查硬件设备，如存储，光纤连接，光纤交换机。然后检查软件配置，如主机上的配置，光纤卡的参数，都没有发现任何问题。最后，甚至重新安装powerpath，问题依旧。这个时候，已经是晚上很晚了，我们都很郁闷，现场dell的一个销售说了声，会不会是powerpath的问题，我们换回老版本看看，于是换老版本，速度也就正常了，问题居然就这么解决了。

2、查找原因

设备是可以正常用了，但是，我们谁都不知道是什么原因，之后与dell交互过几次，基本怀疑是cx700的软件版本太老，其实就是cx700的flare operating environment，当时是2.14的版本。

直到我们要安装另外一台cx700到aix主机上的时候，才发现问题不是那么简单。我们先做了raid，发现软件版本是2.14，于是就升级到了当时最稳定的版本，2.19.030，在主机上安装了PP4.5，结果发现问题依旧。

因为这次的时间比较充足，决定要求dell查找一下原因，dell于是派了一个工程师过来，这个工程师技术一般，却有一个特长，就是能打电话，他可以不停的电话别人，从中国到新加坡，甚至到更远的澳洲。原来的问题不仅是没有解决，反复的安装测试，反而导致了另外的问题，如powerhdisk盘出现了混乱，pvid也出现了严重错误。因为新的错误的出现，他的电话不得不变的更多了。

我郁闷了，决定结束这次检查，我先是删除干净，再安装回PP4.2，凭借OS的经验解决了powerhdisk与pvid的问题，因为我害怕再弄下去，我也解决不了OS上的这些问题了。

问题依旧是没有解决，这样看来不是软件版本的问题。

3、柳暗花明

我已经习惯PP4.2了，就这么用着吧，后来，新采购了新的cx700，软件版本买过来就是2.19的，这次尝试安装了PP4.5，居然一切正常，又勾起我想解决前面的问题的欲望。于是，我拿这个正常的cx700与前面性能有问题的cx700反复测试，也没有发现哪里有不同，但就是在PP4.5上速度有差别。

问题的最终解决我也没有想到，一台软件版本从2.14升级到2.19的CX700，正好要重做，于是我重做了raid，本着找问题的精神，我还是装了PP4.5，居然这次正常了。

晕，对照以前的做法，唯一不同的就是，以前是先做raid，再升级软件，就不可以用PP4.5，现在是升级软件以后，再做RAID，居然就可以了。为了确定其正确性，我找了一个软件版本还是2.14的机器，先升级到2.19，连接PP4.5，就是速度有问题，但是重做raid后，速度就正常了。

问题最终是知道怎么回事了，但是，我也是一直郁闷着过来的，这样的问题，谁能想得到呢，难道Raid跟cx700的软件也挂上关系了。我也不想调查最终原因了，如果调查，可能只能问CX700的开发人员了。

在Oracle数据库系统中，很多人没有弄清楚自己的业务类型到底是什么，就在开始盲目的寻求优化方法，而往往是把OLAP的方法使用在OLTP上，或者是OLTP的方法使用在OLAP上。这样的使用，有的时候，对性能没有任何的提高，甚至是大大的影响了性能，得到适得其反的效果。所以，在优化系统之前，弄清楚自己的业务类型。

1、什么是OLTP

OLTP，也叫联机事务处理(Online Transaction Processing)，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的transaction以及execute sql的数量。在这样的系统中，每秒处理的transaction往往超过几百个，或者是几千个，select 语句的执行量每秒几千甚至几万个。典型的OLTP系统如电子商务系统，银行，证卷等等，如美国ebay的业务数据库，就是很典型的OLTP数据库。

OLTP系统最容易出现的瓶颈就是CPU与磁盘子系统。cpu则取决于逻辑读以及内部调用，如函数等等。一个执行频繁的SQL语句，如果每个语句可以减少很少的逻辑读，也相当于优化了一些逻辑读很差的大型语句。很多人不感觉不到这里的作用，觉得一个语句几十个逻辑读，执行时间基本为0，就不需要优化了，其实，只要他的执行次数非常频繁，而且有优化的余地，就一定要优化，如减少一定的逻辑读或者降低执行次数，都是优化方法。

另外，一些计算性的函数，如sum，count，decode被非常频繁的使用，也是非常消耗cpu的，我遇到一个系统，因为一个sql语句，大量的使用了sum与decode进行行列转换，结果这一个语句就耗费了整个机器一半以上的CPU。

那么，在一般的OLTP系统中，如果不考虑我上面说的函数问题，那么，逻辑读乘以执行次数，决定了cpu的消耗程度，如一个语句，每秒执行次数为500次，每个逻辑读为15，但是，通过优化，能让每个语句的逻辑读从15降到10，那么，每秒的逻辑读就可以减少500*5=2500个，其实就是相当于优化了一个执行频率为每秒1次，每次逻辑读为2500个的语句（注意，2500个逻辑读，在oltp系统是非常差的语句）。再如，假定一个1GHZ的cpu每秒能正常处理的逻辑读是100,000个，如果是10个逻辑读一个的语句，每秒可以处理10,000个，而1000个逻辑读一个的语句，每秒则只能处理100个。

同以上道理，物理读乘以执行次数，则决定了存储子系统的处理能力，在一个OLTP环境中，物理读一般都是db file sequential read决定的，也就是单块读，一个典型的OLTP系统，db file sequential read应当基本等于磁盘子系统的读的IOPS。而磁盘子系统的IOPS处理能力，与cache命中率以及磁盘个数有很大的关系。我的一些文章中，也分析到了这些问题，如一个15K转速的磁盘，每秒最多能处理的iops达到150个，基本就是极限了，如果cache不命中，那么100个磁盘，最多能处理的IOPS仅仅是15000个（但是，实际上，还基本达不到这个值）。

OLTP最常用的技术就是cache技术与btree索引，cache决定了很多语句不需要从磁盘子系统获得数据，所以，web cache与oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句是越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少关联。其它方面，基本不使用分区技术，MV技术，并行技术以及位图索引，因为并发量很高，批量更新可能要尽量快速提交避免阻塞的发生。

在ebay的数据库设计中，有一个很重要的点就是，数据库只负责存放数据，业务逻辑尽量在业务层实现，因为数据库扩展是困难的，而应用服务器扩展是简单的。其实，也就是说，在高可用的OLTP环境中，数据库使用越简单的功能越好。

2、什么是OLAP

OLAP，也叫联机分析(Online Analytical Processing)，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一个语句的执行时间可能会非常长，读取的数据也非常多。所以，这样的系统中，考核的标准往往决定于磁盘子系统的吞吐量。

磁盘子系统的吞吐量则直接取决于磁盘的个数，这个时候，cache基本是没有效果的，这个时候数据库的读写基本上是db file scattered read与direct path read/write。在我前面的一些文章中描述过，如果一个15K的磁盘的IO量每秒13M，那么，100个磁盘，最多能提供的吞吐量则是1300M/s（实际上，也基本达不到这个值）。如果磁盘个数足够的话，还需要考虑采用比较大的带宽，如4GB的光纤接口。

在OLAP系统中，常使用的技术有分区技术，并行技术。如分区技术可以使得一些大表的扫描变得很快（只扫描单个分区），而且方便管理。另外，如果分区结合并行的话，也可以使得整个表的扫描也会变得很快。并行技术除了与分区技术结合外，在oracle 10g中，与rac结合实现多节点的同时扫描，效果也非常不错，把一个任务，如select的全表扫描，平均的分派到多个rac的节点上去。

在OLAP系统中，不需要使用绑定变量，因为整个系统的执行量很少，分析时间对于执行时间来说，可以忽略，而且避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量的寻求速度上的优化，没有必要象OLTP需要快速提交，甚至要刻意减慢执行的速度。

3、总结

特别是在高可用的OLTP环境中，不要盲目的把OLAP的技术拿过来用，如分区技术，如果不是大范围的使用了分区关键字作为where条件，而采用其它的字段作为where条件，那么，如果是本地索引，你将不得不扫描多个索引，而性能变的更为低下。如果是全局索引，那分区的意义又何在，只是多出一份分区技术的license而已。

并行技术也是如此，一般是在大型任务的时候才使用，好比说，实际生活中，一个比较大型的工作，如翻译一本书，你可以先安排多个人，每个人翻译不同的章节，这样是可以提高翻译速度，但是，你现在只是翻译一页，你也去分配不同的人翻译不同的行，再组合起来，这个时间，你一个人或者早就翻译完了。

位图索引在我前几篇文章中有交代，如果用在oltp环境中，可能因为阻塞范围太大，很容易阻塞与死锁，但是，在olap环境中，可能会因为其特有的特性，提高olap的查询速度。mv也是基本一样，包括触发器等等，在dml频繁的oltp系统上，很容易成为瓶颈，而在olap环境上，则可能会因为使用恰当而提高查询速度。

更多的差别与技术，细说下来太多了，有些东西，是要靠大家慢慢去体会的，我这里也就不多说了，大家可以平常在自己的业务中多多体会。

前一篇我写了位图索引的阻塞与死锁分析，但是，那是在oracle 10g上做的，其实，Oracle 9i与oracle 10g的位图索引是有很大差别的。oracle 10g对比oracle 9i，在位图索引上做了非常多的改动，详细见

9i的位图索引内部研究:

http://www.itpub.net/showthread.php?threadid=114023

10g的位图索引内部研究:

http://www.itpub.net/showthread.php?threadid=743939

我这里不想讨论这些内部结构，只是想通过2个实验，来看看位图索引的阻塞范围。

我先拿9i做实验：

我们看看使用空间，初始化默认就是2个块，其中有一个是段头。

我们插入1000条数据，其中，flag字段为0与1，因为任何数与2 mod之后，都是0或者是1。

再检查使用情况

发现，1000条数据，就使用了6个块（包括一个段头），也就是新增了4个块。

再看看阻塞情况，注意，id=1与id=2的flag值肯定不一样。

会话1

会话2

可以看到这里阻塞了，也就是说，Oracle 9i的阻塞不考虑原来的值与新值，这个与下面测试的oracle 10g不一样。

我们另外再考虑一组测试，注意，这个测试中，如果原来是0，则更新成1，如果原来是1，则更新成0

会话1

会话2

会话3

通过以上可以发现，9i的阻塞是阻塞一个范围段，如以上就是8条记录，不管更新的值怎么样，就是把这范围段给阻塞了，这个也是与以下10g不同的一个地方。也就是说，在oracle 9i中，8条记录这个范围段以外的记录不被阻塞，我们通过如下的实验也可以发现只阻塞8条记录。

可以看到，除了前8条记录以外的所有记录，都更新成功了。

那么，在oracle 10g中，有些什么样的变化呢？其实，在我的上一篇文章中大致提到了，我们再看一下。我们同样创建一个表与位图索引。

以上的结果与9i相同，都是初始化2个块，其中一个是段头块。我们插入数据看看

以上看到第一个差别了，9i只插入1000条数据，就使用了6个块，但是，10g现在插入了2w条数据了，但是还是2个块，可见10g的位图索引具有比较好的压缩功能。

我们再插入10000条数据。

这次，才终于新增加了2个leaf block块，现在有4个块了。

那么，我们看看阻塞情况：

会话1

会话2

会话3

可以看到，10g的阻塞范围很大了，id=1阻塞了id=20000的记录，但是没有阻塞id=30000的记录，这里说明了，10g的阻塞是以索引块为单位的，阻塞了整个索引块中的记录，因为在插入20000条记录的时候还没有扩展新的索引块，可以说明id=1与id=20000是在一个索引块中的，而id=30000的时候，扩展了索引块，可以表示id=30000是在另外一个索引块中。我们进一步分析：

会话1

会话2

这里没有阻塞，这里也不同于9i了，说明10g的阻塞是与值有关系的，也就是10g的阻塞是看旧值与新值的，只阻塞同一个块中的旧值与新值，而不阻塞与新值以及旧值无关的值。

最后，总结一下，9i的阻塞范围是分段的，如8条记录，不管值如何，全部阻塞。而10g具有良好的位图索引的压缩功能，但是阻塞同一个索引块中的旧值与新值（这个范围可能比9i要大很多）。这些特性，怀疑与10g的压缩功能有关系。

最近的事情比较多，又是调试新设备，准备测试，又是alibaba的网络侠客行大会。这不，taobao又组织了新一轮的武林大会，全公司，十个帮派，浩浩荡荡的，杀到象山海边的一个四星级酒店——象山黄金海岸大酒店，座落在素有“仙岛奇礁、碧海金沙”之称的省级旅游度假胜地。

路上时间比较久，足足化了快5个小时，够累的，到达酒店，已经晚上9点多了，又赶到海边（就在酒店前面）去看了看，可惜的是，天色太晚了，什么也看不见。以前虽然多次经过海边，但这还是第一次实实在在的走在沙滩上，吹着清凉的海风，感受大海澎湃的力量。

酒店还不错，也能免费上网的，这不，趁着还没有睡，赶紧补一个blog。补完了就要早点睡了，明天还要起早床，参见明天的武林大会——

武林就是淘宝，淘宝就是江湖。

如果以后买服务器的时候，仅仅是问这个机器支持多少个CPU，也就是processor，可能就需要小心谨慎了，因为你有可能买一个cpu，结果要支付几个cpu的license。

不是没有可能，实际上，已经就有这样的情况了，那就是SUN CMT的出现，使得processor，也就是cpu，开始成为一个模糊的概念，而core（核）有可能取代cpu成为新的检查标准。

SUN CMT其实还是一个好东西，在一个芯片中，集成了多个Core，目前为止，可以在UltraSPARC构架上支持8个core，但是，SUN认为这个芯片是一个CPU，也就是一个processor，如一个UltraSPARC T1 CPU，可能有8个core。

但是，其它的厂商，如IBM，ADM/Intel等等，如果在一个CPU模块上同样集成多个Core，但是他们认为这个是多个CPU，也就是多个processor，如IBM的Power5的多核CPU模块，如果包含多个core，IBM则认为他是多个CPU。

影响最大的，应当就是按cpu收费的软件厂商了，如Oracle，所以，Oracle就开始不按照cpu来收费，而是按照core来收费，不同的是，不同厂商的可能折扣比例不一样，以下是一个公开的折扣比例

    Oracle Processor Licensing                                Cores     Processor Factor
    UltraSPARC T1                                             8         0.25
    AMD/Intel                                                 2         0.5
    All other Multi-core Chips (IBM Pseries, SM USIV, etc.)   2         0.75
    Single Core Servers                                       1         1.00

按照这个标准，一个UltraSPARC T1的cpu，对外宣称是一个cpu，虽然折扣很低了，但是，但是需要购买8*0.25=2个cpu license，一个双核的AMD/Intel芯片，包含2个core，对外也是2个cpu，但是也只需要购买2*0.5=1个cpu license。

另外，IBM虽然也支持多核，如8-way的CPU模块，但是从内部结构来看，也是等于4个双核。所以，多路的IBM的power cpu的收费可以简单的把cpu数量*0.75来购买license。

最后，可能看到的情况是，SUN一个cpu怎么需要买几个license，而别人几个cpu才买一个license。不要奇怪，这个，就是新的标准。

管理过多的文件

用户的某个目录下有非常多的文件，当用户使用ls列示所有文件或使用mv * 命令想把所有文件移至另一目录时，系统报错，相应操作无法进行。错误信息为：”Arguments too long”或”Array list too long”。

该错误的产生是由于/usr/include/sys/limits.h文件中ARG_MAX参数对应值的限制，最大值为24576，并且无法改变此限制。因此当某目录下的文件数超过24576时，可以使用下面的命令列示、删除或移动所有的文件：

1. 列示文件：

#find -name “*” | xargs ls -l

2. 删除文件，如：

#find ./ -name “*.log” -mtime +1|xargs [-n1] rm

or（注意，xargs后面是大写的i）

# find ./ -name “*.log” -mtime +1|xargs -I{} rm {}

or移动所有文件至目标目录：

#find -name “*” | xargs -I{} mv {} destinationdir

批量更新文件

有的时候，我们需要批量的更新所有的文件，但是shell中一个语句一般实现不了这样的要求，我们可以采用perl帮忙，如更新所有文件内容

perl -e ’s#\/u01\/data_archvie#\/u02\/logs\/admin#i’ -pi.bak `(find . -type f )`

这里-e的部分表示更新，#是分界符，-pi表示产生对应的备份文件

其中，find是可以根据自己的需要扩展的。

补充测试

就第一个问题，很多平台上都有这样的情况的，如linux，其他unix等，不过linux可以很方便的修改之后重新编译内核。我在5.3上做了一个测试，看样子有些东西与以前有差别了，现在ls是不会报这样的错误，起码在10万个文件的时候还没有报，同样，find -exec的方法也是可以的了。

#ls -l|wc

   100000  940953 7555769

rm是报错的，而且，这个错误从#define ARG_MAX 24576这个定义的值就开始报了，如果修改这个值，肯定是要重新编译内核的了。

#rm *.log

    ksh: /usr/bin/rm: 0403-027 The parameter list is too long.

mv同样是报错的

#mv *.log tmp/

    ksh: /usr/bin/mv: 0403-027 The parameter list is too long.

现在，find -exec方法也是可以的，除了rm可以使用这个方法，mv也可以使用-exec的方法

#find . -name “*.log” -exec rm {} \;

删除成功

昨天晚上正在打羽毛球，收到biti的短信，说我有2起违章，很久没有违章了，也很久没有去网上查过了，居然一下就有2起了？晕的。

想想从去年7月买车到现在，也就只因为超速违章过一次，虽然别人都说我的车开的快，但是，违章记录还是基本良好的，回家打开杭州市交通信息网，查了一下，只有一起啊，biti怎么说2起啊？我再把车牌修改成大写，再查，果然是两起，ft，这个破网站还分大小写的啊。

违章记录：

想起来了，保俶路那个是部门出去喝茶，是一个晚上，还在下雨，到目的地以后，我开的很慢，在找一个停车场，没有发现前面的红灯，其实这里是一个T字路口，路口也没有车，我的车就这么慢慢的滑过去了，直到我看到白光一闪的时候，才知道被拍了，这个时候我也才看到路口的红灯，好晕。

另外一个违章则是五一前去机房，在哪个路口为了赶时间，在左转或右转道上直行了，呵呵。按理说，这个地方已经是比较偏僻的地方了，居然还有这样的摄象机在拍摄违章，再晕。直从机房搬迁以后，就变的很远了，开车过去一般都要40分钟以上，打车一个来回的话要70-80块钱，但是我一般都是开车过去，不仅没有油钱报销，现在居然还被罚款了，哭。。。。。。

不过，高兴事也有的，昨天晚上，有个同事打羽毛球，非要说能打过我，要跟我比赛，谁输了请全部门（14号人）在杭州有名的餐馆——大宅门请大家吃饭。比赛三局，结果，2:0，我赢了，嘿嘿，有饭局了。

Aix 5L的文件系统主要有jfs与jfs2两种，jfs2是增强型的jfs文件系统，从AIX 5.3以后开始为默认文件系统，对64bit支持比较好，而且默认支持大文件。

可以用lsfs来查看文件系统，如

#lsfs -q /u01

    Name            Nodename   Mount Pt         VFS   Size    Options    Auto Accounting
    /dev/lv00       --         /u01             jfs   524288  rw         yes  no
    (lv size: 524288, fs size: 524288, frag size: 4096, nbpi: 4096, compress: no,
                bf: true, ag: 64)

这里展示了一个支持大文件的jfs文件系统

创建文件系统的时候，可以先创建lv再创建文件，也可以直接创建文件系统，但是如果直接创建文件系统的话，OS也会创建一个lv00/lv01这样类似的lv，为了管理方便，一般建议采用先创建lv，再创建文件系统，如创建一个jfs2的文件系统。

1、创建lv

#mklv -y’lv_u02′ -t’jfs2′ datavg 10 hdisk2

    lv_u02

以上操作也可以采用smit mklv来完成

2、在该lv上创建jfs2文件系统

#crfs -v jfs2 -d’lv_u02′ -m’/u02′ -A’yes’ -p’rw’ -a agblksize=’4096′

    File system created successfully.
    2621156 kilobytes total disk space.
    New File System size is 5242880

其中-d是lv名称，-m是mount点，-A是表示系统启动的时候自动挂载，-p表示权限，-a之后的表示块尺寸。

以上操作建议采用smit crfs操作，如

#smit crfs

选择Add an Enhanced Journaled File System

选择Add an Enhanced Journaled File System on a Previously Defined Logical Volume

填写LV名称，mount点，是否自动挂装，注意，如果是HA的共享文件系统，需要由HA挂装的文件系统，则不要自动挂装。

3、查看

#lsfs -q /u02

    Name            Nodename   Mount Pt         VFS   Size    Options    Auto Accounting
    /dev/lv_u02     --         /u02             jfs2  5242880 rw         yes  no
      (lv size: 5242880, fs size: 5242880, block size: 4096, sparse files: yes,
               inline log: no,inline log size: 0, reserved: 0, reserved: 0, DMAPI: no)

如果想删除文件系统，可以用rmfs命令操作，注意删除之前先umount这个文件系统，这个命令会删除文件系统所在的lv，但是如果直接删除lv，则不会删除上面存在的文件系统（其实文件系统已经没有了，但是文件系统的信息依然存在于OS中）。

#rmfs -r /u02

    rmlv: Logical volume lv_u02 is removed.

如上面的操作将删除lv_u02，-r参数表示连mount点一起删除。以上操作也可以使用smit rmfs来完成。

不管是jfs还是jfs2，都可以增加文件系统的大小，如

#chfs -a size=’3000M’ /u02

    Filesystem size changed to 6291456

或者使用smit chfs来操作

注：在5.3系统上运行的jfs2文件系统，可以减少尺寸。

可以采用mount与umount来挂装与卸载文件系统

#mount /u02

对于挂装的文件系统，可以用df来查看其大小及使用

#df -g /u02

    Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
    /dev/lv_u02        3.00      3.00    1%        4     1% /u02

如果有用户或程序在一个文件系统中活动，就无法拆卸（umount）这个文件系统，当使用umount命令时，会提示下面的错误：

Device busy 或者 A device is already mounted or cannot be unmounted

例如由于安装程序的异常终止或其它原因经常会遇到不能正常umount光驱（光驱是CDROM文件系统）的问题，当用户umount光盘驱动器时就产生错误0514-062: 指定的设备忙。

遇到这样的情况，先检查用户自己的当前工作目录是否在这个文件系统中，如果是，则用cd /命令使当前工作目录回到根目录，然后再试着拆卸文件系统；另外检查该文件系统下是否挂有子文件系统，如果有，先umount子文件系统。

如果还是不能umount文件系统，可能在文件系统有文件正在被打开使用，因此在umount文件系统之前应该关闭这些文件。有时候可能还有一些进程在使用这个文件系统的资源，可以使用fuser命令来检查有那些进程仍然在这个文件系统中活动。fuser命令将显示在这个文件系统中正在活动的所有进程ID号。下面就fuser命令使用的例子：

#fuser /dev/cd

    /dev/cd: 2910 3466

然后用kill命令将这些正在活动的进程杀死，然后再试着拆卸文件系统。例如：

#kill -9 2910 3466

如果使用fuser -u /dev/cd将在进程号后指出用户名。如果root用户用fuser -k /dev/cd命令，则给这些进程发出SIGKILL信号，来杀死这些进程，类似以上的2个过程的合并。

2004年上海的Oracle open world大会到现在，一晃三年就过去了，时间过的真快啊。翻出当时的资料，找到一张被www.oracle.com公布出来的照片，是我们一伙几个当时参加大会时，被oracle公司拍下来的。

同样的，关于那次oracle open world的内容，在我的职业生涯中也有描述：我的职业生涯之人物回顾：我认识的那些朋友们：

之后的一次大型见面会就是Oracle open world 2004了，才终于见识了eygle，chao_ping，gototop，kamus，ora-600，dcba，parrotao等等众多大虾，eygle当时是来接我的培训课程而早点过来的，并且在上海一起吃了顿便饭，那上海菜我可是真吃不习惯。chao_ping则主要是组织了一次cnoug的聚会，而且我当时还上台做了一个小的技术交流。

而今年的盛会可以参考：甲骨文全球大会·2007·亚太地区

那么，今年的oralce open world大会，会有哪些人去呢？