我把我的整个过程写在这里，希望能给大家提供一个思路和借鉴。
环境：
OS:AIX 5307
DB:ALTIBASE 3
EMC DMX1000
第一次出现问题
问题现象：
在白天的业务高峰期，210G内存被消耗完。内存数据库同步积压，积压的日志文件数达到2000个多个，也出现了SWAP OUT的情况。主机相应变慢，但还没有hang住。
在出现这个问题的时候，首先检查了系统的内存占用情况，发现内存被消耗完，noncomp（文件型页面缓存）占用比较高，同时IO也存在等待的情况（当时的情况没有保存，无法重现了）。因为一直运行也比较正常，存储层的东西没怎么修改过，所以当时尝试修改了系统参数max_perm%和 min_perm%，修改之后，noncomp占用依然，因为这两个参数只是一个大概的值，并不会严格限定noncomp内存的使用，于是在加上参数 strict_maxperm = 1，严格限定noncomp的内存占用，修改的结果是导致同步进程出现异常，无法正常进行复制。时间比较紧迫，就采用了以下方法解决：
1、停止复制。
2、就直接从其他的逻辑分区上划了25个G的内存过来。
3、当天晚上再重做一次全同步。
问题解决。
============================================
第二次出现问题
在第一次解决之后，观察了几天，系统还算稳定。但是在半个月之后，又出现了前面的问题。已经尝试加过内存，不能再继续加了，明显治标不治本，而且我们也没那么多内存来不停的加。
当时就停止复制，释放内存，当天晚上再重新全同步。但这只能是权宜之计，不能隔段时间就做一次这样的全同步，决心彻查一下问题。
在对当时的topas，nmon等的结果分析，我认为，主要是因为磁盘的IO等待太高，导致文件的读写被拖延，从而导致noncomp的内存占用不断攀升。我发现一个现象，从io层面看，io分布不均匀，在一个时间段中，总有一个hdiskpower busy为100％，但是大约1个小时之后，会换另外一个hdiskpower busy为100％，而且，这个100％的盘实际读写的量并不是很高，大概为6M/s。当时我的判断就是存在热点盘，并且在存储层面没有做raid 0。
因为这个问题几次出现，影响到我们的业务，决定彻查。于是找了EMC原厂的人过来的人过来商讨优化方法，emc建议抓一天的数据做一个存储分析，看看是否存在热点盘。几天以后，emc的结果出来了，emc认为没有单独的热点盘，全部盘都是热点盘，都在满负荷运行。另外，关于我提出的没有做条带的疑惑，EMC的答复是条带肯定做了。
emc给出的建议是：
1）扩充现有的内存(增加2块16GB cache)
2）另外发现只有几个前端端口的IOPS较高，其他的前端端口比较空闲，建议把繁忙LUN再增加对前端端口的映射。
这个存储其实也比较老了，存储上挂了好几个业务系统，磁盘都忙也是正常的。而且EMC是以24小时为单位看的，所以我觉得得到这样的结果也正常，因为我们busy100％的盘始终在轮换，从整体的效果来看，每块盘都忙。
针对EMC的解决方案，扩充cache板，也许对系统有一定的提升，但是实际的效果很难说，我觉得基本不会有太大的提升，能提升个5%也就差不多了。
想要解决这个问题，还是得找其他的办法。另外，我还是怀疑条带没做，还想继续检查确认条带的问题。
在系统中，我们在crontab中布置了一个nmon作业，来监控系统的使用。于是我就找了其中的一天分析。结果发现一个比较奇怪的现象。altibase数据库有3个文件系统：
/altibase_dbs1
/altibase_dbs2
/altibase_logs
数据在写入的时候，会先写/altibase_dbs1，一段时间之后，再写/altibase_dbs2，然后再写 /altibase_dbs1...，如此交替。/altibase_logs则始终在写。写入的量上/altibase_logs为（dbs1＋dbs2）中写入的量的2倍。这三个文件系统都基本不存在读。如果按照这个写入的来量来推算，那应该是logs下面的盘比较忙，但是实际的情况是dbs1和dbs2的盘非常忙，正在写入的盘busy为100％，但是logs正在写入的盘busy只有50％。
因为不清楚altibase在做checkpoint的时候，数据块的写入策略，所以比较难以解释。当时猜想altibase在写数据文件的时候是针对修改了的数据块进行更改写入，是随机小数据块写入，在磁盘上寻道的时间比较长，所以写入的量不大，但是磁盘非常的忙。同时，我也认为磁盘没有做条带化，所以才导致这个结果。
一切以事实为准。所以我向原厂确认两点：
1）altibase数据库在checkpoint的时候写入的策略。原厂工程师最终答复：
发生 checkpoint 的时候，对dirty page的flush，是根据数据文件顺序写， 而且是写好一个写另一个。
第一次发生checkpoint 的时候 ，mydb-0-0, mydb-0-1, mydb-0-2..（位于/altibase_dbs1），根据数据文件的顺序进行flush。
第二次发生checkpoint 的时候 ，mydb-1-0, mydb-1-1, mydb-1-2..（位于/altibase_dbs2），根据数据文件的顺序进行flush。
第三次发生checkpoint 的时候 ，mydb-0-0, mydb-0-1, mydb-0-2..（位于/altibase_dbs1），根据数据文件的顺序进行flush。
...
mydb-0-n是一个一个的物理文件（每个大小我这里定义的是1G），altibase没有表空间的概念。在没有做条带的文件系统中，这种写入策略就会导致磁盘写入效率比较低。
2）找来emc原厂的工程师，现场检查每个/altibase_dbs1，/altibase_dbs2，/altibase_logs中pv（hdiskpower）在物理磁盘上是如何分布的？最终检查的结果终于证实了我的猜想，只做了raid1。
emc在划分的时候，将一块物理硬盘（146G）分成10个 volumn （每个14g），然后从第一块硬盘中取出一个volumn，比如volumn11，从第二块硬盘中取出一个volumn，比如volumn21，..，从第九块硬盘中取出一个volumn（volumn91），这9个volumn组成一个文件系统/altibase_dbs1。然后volumn12，volumn22，...，volumn92组成文件系统/altibase_dbs2。
然后volumn13，volumn23，...，volumn93组成文件系统/altibase_logs。
这样，每个物理硬盘中还有其他的volumn，其余的volumn则被其他的系统使用，主要是被我们另一个oracle数据库使用，oracle的数据库比较繁忙。所以现在就比较清楚，为什么出现前面的情况了。altibase的数据文件mydb-0-n每个是1g，而我们划分的volumn每个是 14g，基本上每个mydb-0-n是在同一个volumn中的，也就是在同一个物理硬盘中，同时这个物理硬盘还被其他的oracle数据使用，所以 altibase本身的写入量虽然不大，但是会出现busy 100％的情况。
解决方案
问题已经比较清楚了，我当时建议优化可以考虑从存储、主机、数据库3个方面来做：
1、主机级
当前lv创建在参数设置不是很合理。当前我们配置的INTER-POLICY:minimum ，也就是说数据在写入磁盘的尽量分布在最少的盘上，如果IO的量比较大，就容易造成单块盘的busy过高，引起等待。
建议重新创建vg，并且打开条带化写入的功能，条带化应该能缓解硬盘的IO压力。
2、存储级
1）加cache板，我们还有16G的cache板没加上去，加16G的cache在存储上，应该有比较明显的效果。但是当时emc回复需要下电才能加板，那就存在存储在下电以后无法起来，所以操作的风险很大。（最终还是加了cache板，因为最后确认不需要下电）。
2）做raid0策略。这个过于复杂，对我们的系统影响太大，所以实际上不可行。
3、数据库级
altibase数据库连接比较多，消耗了很多的物理内存，将连接数能降下来一些，也可以改善主机的情况。
对于altibase的写入策略，如果同时写多个数据文件，那也存在问题。因为同时打开，要占用内存，而且文件很大，对内存的占用也不少。这种策略上修改也比较困难，也不是短时间就可以解决的。
主机级的操作影响的范围最小，效果最好，但是也最麻烦。我将/altibase_dbs1，/altibase_dbs2，/altibase_logs 所有涉及的物理硬盘全部找出来，以及上面划分的pv的情况，以及每个pv给哪个系统使用了，然后挑选负担比较轻的物理硬盘中的volumn，组成 /altibase_dbs1和/altibase_dbs2，在主机层打开条带功能。
vg重建方案如下：
PV 逻辑分区编号 物理硬盘编号 该物理硬盘上其他的逻辑分区 oracle占用的逻辑分区数
hdiskpower4 0200 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower5 0201 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower6 0202 1b,da 1b2-1c2-1d2-1e2-1f2-202-212-222-232-242-2e8 5
hdiskpower7 0203 1c,db 1b3-1c3-1d3-1e3-1f3-203-213-223-233-243-2e9 5
hdiskpower8 0204 1d,cb 1b4-1c4-1d4-1e4-1f4-204-214-224-234-244-2ea 5
hdiskpower9 0205 1a,db 1b5-1c5-1d5-1e5-1f5-205-215-225-235-245-2eb 5
hdiskpower10 0206 1b,cb 1b6-1c6-1d6-1e6-1f6-206-216-226-236-246-2ec 5
hdiskpower11 0207 1c,ce 1b7-1c7-1d7-1e7-1f7-207-217-227-237-247-2ed 6
hdiskpower12 0208 1d,dc 1b8-1c8-1d8-1e8-1f8-208-218-228-238-248-2ee 6
hdiskpower13 0209 1a,cc 1b9-1c9-1d9-1e9-1f9-209-219-229-239-249-2ef 6
hdiskpower14 020A 1b,dc 1ba-1ca-1da-1ea-1fa-20a-21a-22a-23a-24a-2f0 6
hdiskpower15 020B 1c,dd 1bb-1cb-1db-1eb-1fb-20b-21b-22b-23b-24b-2f1 6
hdiskpower16 020C 1d,cd 1bc-1cc-1dc-1ec-1fc-20c-21c-22c-23c-24c-2f2 6
hdiskpower17 020D 1a,dd 1bd-1cd-1dd-1ed-1fd-20d-21d-22d-23d-24d-2f3 6
hdiskpower18 020E 1b,cd 1be-1ce-1de-1ee-1fe-20e-21e-22e-23e-24e-2f4 6
hdiskpower19 020F 1c,cc 1bf-1cf-1df-1ef-1ff-20f-21f-22f-23f-24f-2f5 5
hdiskpower20 0210 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower21 0211 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower54 0063 1b,d4 014-03b-063-08b-103-12b-153-17b-1a3 4
hdiskpower55 0064 1c,d5 015-03c-064-08c-104-12c-154-17c-1a4 3
hdiskpower56 0065 1d,c5 016-03d-065-08d-105-12d-155-17d-1a5 3
hdiskpower57 0066 1a,d5 017-03e-066-08e-106-12e-156-17e-1a6 3
hdiskpower58 0067 1b,c5 018-03f-067-08f-107-12f-157-17f-1a7 3
hdiskpower59 0068 1c,c6 009-040-068-090-0b8-0e0-108-130-158-180-198 4
hdiskpower60 0069 1d,d6 012-041-069-091-0b9-0e1-109-131-159-181-1a1 4
hdiskpower61 006A 1a,c6 01a-042-06a-092-0ba-0e2-10a-132-15a-182-1a9 4
hdiskpower62 006B 1b,d6 01b-043-06b-093-0bb-0e3-10b-133-15b-183-1aa 5
hdiskpower63 006C 1c,d7 01c-044-06c-094-0bc-0e4-10c-134-15c-184-1ab 5
hdiskpower64 006D 1d,c7 01d-045-06d-095-0bd-0e5-10d-135-15d-185-1ac 5
hdiskpower65 006E 1a,d7 01e-046-06e-096-0be-0e6-10e-136-15e-186-1ad 6
hdiskpower66 006F 1b,c7 01f-047-06f-097-0bf-0e7-10f-137-15f-187-1ae 6
hdiskpower67 0070 1c,c8 011-048-070-098-0c0-0e8-110-138-160-188-1a0 6
hdiskpower68 0071 1d,d8 019-049-071-099-0c1-0e9-111-139-161-189-1a8 6
lv的划分需要尽量跨在多个物理硬盘上，dbs1和dbs2的lv最好能避开oracle，所以需要尽量划在oracle占用比较少的物理硬盘上，建议的lv划分如下：
lv00 (/altibase_dbs1): hdiskpower 4,5,54,55,56,57,6,7,8,9,10,11 -12个pv
lv01 (//altibase_dbs2): hdiskpower 20,21,58,59,60,61,12,13,14,15,16,17 -12个pv
lv02 (/altibase_logs) : hdiskpower 18,19,62,63,64,65,66,67,68 -9个pv
lv 的Stripe Size为64K。stripe width 为4。
后记：
条带后的效果非常明显，同步不再存在积压情况，在条带之后的1年，没有再出现任何问题。
其实这也不是第一次出现问题。以前也出现过，只不过一般也都是半年才出现个一次。
其实这个事情上给我们几个教训：
1、系统在设计阶段你就得做好规划。从底向上，得有一个通盘的考虑。
2、给EMC这样的原厂厂家提需求的时候，最好能细节化。比如详细的你对binfile要求。在后面的另一个项目中，又郁闷了一次。新买的DMX4存储，在美国就给灌好了binfile，这个binfile我没有提很多细节的东西。结果因为赶进度，没有时间再重新调整了。存储的划分没有达到我的一个比较理想的情况。
3、原厂的话不能尽信。很多的东西你必须得亲眼看到才行。这也是无数次的教训了。
4、有时候你要坚持你的判断，相信自己。
环境：
OS:AIX 5307
DB:ALTIBASE 3
EMC DMX1000
第一次出现问题
问题现象：
在白天的业务高峰期，210G内存被消耗完。内存数据库同步积压，积压的日志文件数达到2000个多个，也出现了SWAP OUT的情况。主机相应变慢，但还没有hang住。
在出现这个问题的时候，首先检查了系统的内存占用情况，发现内存被消耗完，noncomp（文件型页面缓存）占用比较高，同时IO也存在等待的情况（当时的情况没有保存，无法重现了）。因为一直运行也比较正常，存储层的东西没怎么修改过，所以当时尝试修改了系统参数max_perm%和 min_perm%，修改之后，noncomp占用依然，因为这两个参数只是一个大概的值，并不会严格限定noncomp内存的使用，于是在加上参数 strict_maxperm = 1，严格限定noncomp的内存占用，修改的结果是导致同步进程出现异常，无法正常进行复制。时间比较紧迫，就采用了以下方法解决：
1、停止复制。
2、就直接从其他的逻辑分区上划了25个G的内存过来。
3、当天晚上再重做一次全同步。
问题解决。
============================================
第二次出现问题
在第一次解决之后，观察了几天，系统还算稳定。但是在半个月之后，又出现了前面的问题。已经尝试加过内存，不能再继续加了，明显治标不治本，而且我们也没那么多内存来不停的加。
当时就停止复制，释放内存，当天晚上再重新全同步。但这只能是权宜之计，不能隔段时间就做一次这样的全同步，决心彻查一下问题。
在对当时的topas，nmon等的结果分析，我认为，主要是因为磁盘的IO等待太高，导致文件的读写被拖延，从而导致noncomp的内存占用不断攀升。我发现一个现象，从io层面看，io分布不均匀，在一个时间段中，总有一个hdiskpower busy为100％，但是大约1个小时之后，会换另外一个hdiskpower busy为100％，而且，这个100％的盘实际读写的量并不是很高，大概为6M/s。当时我的判断就是存在热点盘，并且在存储层面没有做raid 0。
因为这个问题几次出现，影响到我们的业务，决定彻查。于是找了EMC原厂的人过来的人过来商讨优化方法，emc建议抓一天的数据做一个存储分析，看看是否存在热点盘。几天以后，emc的结果出来了，emc认为没有单独的热点盘，全部盘都是热点盘，都在满负荷运行。另外，关于我提出的没有做条带的疑惑，EMC的答复是条带肯定做了。
emc给出的建议是：
1）扩充现有的内存(增加2块16GB cache)
2）另外发现只有几个前端端口的IOPS较高，其他的前端端口比较空闲，建议把繁忙LUN再增加对前端端口的映射。
这个存储其实也比较老了，存储上挂了好几个业务系统，磁盘都忙也是正常的。而且EMC是以24小时为单位看的，所以我觉得得到这样的结果也正常，因为我们busy100％的盘始终在轮换，从整体的效果来看，每块盘都忙。
针对EMC的解决方案，扩充cache板，也许对系统有一定的提升，但是实际的效果很难说，我觉得基本不会有太大的提升，能提升个5%也就差不多了。
想要解决这个问题，还是得找其他的办法。另外，我还是怀疑条带没做，还想继续检查确认条带的问题。
在系统中，我们在crontab中布置了一个nmon作业，来监控系统的使用。于是我就找了其中的一天分析。结果发现一个比较奇怪的现象。altibase数据库有3个文件系统：
/altibase_dbs1
/altibase_dbs2
/altibase_logs
数据在写入的时候，会先写/altibase_dbs1，一段时间之后，再写/altibase_dbs2，然后再写 /altibase_dbs1...，如此交替。/altibase_logs则始终在写。写入的量上/altibase_logs为（dbs1＋dbs2）中写入的量的2倍。这三个文件系统都基本不存在读。如果按照这个写入的来量来推算，那应该是logs下面的盘比较忙，但是实际的情况是dbs1和dbs2的盘非常忙，正在写入的盘busy为100％，但是logs正在写入的盘busy只有50％。
因为不清楚altibase在做checkpoint的时候，数据块的写入策略，所以比较难以解释。当时猜想altibase在写数据文件的时候是针对修改了的数据块进行更改写入，是随机小数据块写入，在磁盘上寻道的时间比较长，所以写入的量不大，但是磁盘非常的忙。同时，我也认为磁盘没有做条带化，所以才导致这个结果。
一切以事实为准。所以我向原厂确认两点：
1）altibase数据库在checkpoint的时候写入的策略。原厂工程师最终答复：
发生 checkpoint 的时候，对dirty page的flush，是根据数据文件顺序写， 而且是写好一个写另一个。
第一次发生checkpoint 的时候 ，mydb-0-0, mydb-0-1, mydb-0-2..（位于/altibase_dbs1），根据数据文件的顺序进行flush。
第二次发生checkpoint 的时候 ，mydb-1-0, mydb-1-1, mydb-1-2..（位于/altibase_dbs2），根据数据文件的顺序进行flush。
第三次发生checkpoint 的时候 ，mydb-0-0, mydb-0-1, mydb-0-2..（位于/altibase_dbs1），根据数据文件的顺序进行flush。
...
mydb-0-n是一个一个的物理文件（每个大小我这里定义的是1G），altibase没有表空间的概念。在没有做条带的文件系统中，这种写入策略就会导致磁盘写入效率比较低。
2）找来emc原厂的工程师，现场检查每个/altibase_dbs1，/altibase_dbs2，/altibase_logs中pv（hdiskpower）在物理磁盘上是如何分布的？最终检查的结果终于证实了我的猜想，只做了raid1。
emc在划分的时候，将一块物理硬盘（146G）分成10个 volumn （每个14g），然后从第一块硬盘中取出一个volumn，比如volumn11，从第二块硬盘中取出一个volumn，比如volumn21，..，从第九块硬盘中取出一个volumn（volumn91），这9个volumn组成一个文件系统/altibase_dbs1。然后volumn12，volumn22，...，volumn92组成文件系统/altibase_dbs2。
然后volumn13，volumn23，...，volumn93组成文件系统/altibase_logs。
这样，每个物理硬盘中还有其他的volumn，其余的volumn则被其他的系统使用，主要是被我们另一个oracle数据库使用，oracle的数据库比较繁忙。所以现在就比较清楚，为什么出现前面的情况了。altibase的数据文件mydb-0-n每个是1g，而我们划分的volumn每个是 14g，基本上每个mydb-0-n是在同一个volumn中的，也就是在同一个物理硬盘中，同时这个物理硬盘还被其他的oracle数据使用，所以 altibase本身的写入量虽然不大，但是会出现busy 100％的情况。
解决方案
问题已经比较清楚了，我当时建议优化可以考虑从存储、主机、数据库3个方面来做：
1、主机级
当前lv创建在参数设置不是很合理。当前我们配置的INTER-POLICY:minimum ，也就是说数据在写入磁盘的尽量分布在最少的盘上，如果IO的量比较大，就容易造成单块盘的busy过高，引起等待。
建议重新创建vg，并且打开条带化写入的功能，条带化应该能缓解硬盘的IO压力。
2、存储级
1）加cache板，我们还有16G的cache板没加上去，加16G的cache在存储上，应该有比较明显的效果。但是当时emc回复需要下电才能加板，那就存在存储在下电以后无法起来，所以操作的风险很大。（最终还是加了cache板，因为最后确认不需要下电）。
2）做raid0策略。这个过于复杂，对我们的系统影响太大，所以实际上不可行。
3、数据库级
altibase数据库连接比较多，消耗了很多的物理内存，将连接数能降下来一些，也可以改善主机的情况。
对于altibase的写入策略，如果同时写多个数据文件，那也存在问题。因为同时打开，要占用内存，而且文件很大，对内存的占用也不少。这种策略上修改也比较困难，也不是短时间就可以解决的。
主机级的操作影响的范围最小，效果最好，但是也最麻烦。我将/altibase_dbs1，/altibase_dbs2，/altibase_logs 所有涉及的物理硬盘全部找出来，以及上面划分的pv的情况，以及每个pv给哪个系统使用了，然后挑选负担比较轻的物理硬盘中的volumn，组成 /altibase_dbs1和/altibase_dbs2，在主机层打开条带功能。
vg重建方案如下：
PV 逻辑分区编号 物理硬盘编号 该物理硬盘上其他的逻辑分区 oracle占用的逻辑分区数
hdiskpower4 0200 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower5 0201 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower6 0202 1b,da 1b2-1c2-1d2-1e2-1f2-202-212-222-232-242-2e8 5
hdiskpower7 0203 1c,db 1b3-1c3-1d3-1e3-1f3-203-213-223-233-243-2e9 5
hdiskpower8 0204 1d,cb 1b4-1c4-1d4-1e4-1f4-204-214-224-234-244-2ea 5
hdiskpower9 0205 1a,db 1b5-1c5-1d5-1e5-1f5-205-215-225-235-245-2eb 5
hdiskpower10 0206 1b,cb 1b6-1c6-1d6-1e6-1f6-206-216-226-236-246-2ec 5
hdiskpower11 0207 1c,ce 1b7-1c7-1d7-1e7-1f7-207-217-227-237-247-2ed 6
hdiskpower12 0208 1d,dc 1b8-1c8-1d8-1e8-1f8-208-218-228-238-248-2ee 6
hdiskpower13 0209 1a,cc 1b9-1c9-1d9-1e9-1f9-209-219-229-239-249-2ef 6
hdiskpower14 020A 1b,dc 1ba-1ca-1da-1ea-1fa-20a-21a-22a-23a-24a-2f0 6
hdiskpower15 020B 1c,dd 1bb-1cb-1db-1eb-1fb-20b-21b-22b-23b-24b-2f1 6
hdiskpower16 020C 1d,cd 1bc-1cc-1dc-1ec-1fc-20c-21c-22c-23c-24c-2f2 6
hdiskpower17 020D 1a,dd 1bd-1cd-1dd-1ed-1fd-20d-21d-22d-23d-24d-2f3 6
hdiskpower18 020E 1b,cd 1be-1ce-1de-1ee-1fe-20e-21e-22e-23e-24e-2f4 6
hdiskpower19 020F 1c,cc 1bf-1cf-1df-1ef-1ff-20f-21f-22f-23f-24f-2f5 5
hdiskpower20 0210 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower21 0211 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower54 0063 1b,d4 014-03b-063-08b-103-12b-153-17b-1a3 4
hdiskpower55 0064 1c,d5 015-03c-064-08c-104-12c-154-17c-1a4 3
hdiskpower56 0065 1d,c5 016-03d-065-08d-105-12d-155-17d-1a5 3
hdiskpower57 0066 1a,d5 017-03e-066-08e-106-12e-156-17e-1a6 3
hdiskpower58 0067 1b,c5 018-03f-067-08f-107-12f-157-17f-1a7 3
hdiskpower59 0068 1c,c6 009-040-068-090-0b8-0e0-108-130-158-180-198 4
hdiskpower60 0069 1d,d6 012-041-069-091-0b9-0e1-109-131-159-181-1a1 4
hdiskpower61 006A 1a,c6 01a-042-06a-092-0ba-0e2-10a-132-15a-182-1a9 4
hdiskpower62 006B 1b,d6 01b-043-06b-093-0bb-0e3-10b-133-15b-183-1aa 5
hdiskpower63 006C 1c,d7 01c-044-06c-094-0bc-0e4-10c-134-15c-184-1ab 5
hdiskpower64 006D 1d,c7 01d-045-06d-095-0bd-0e5-10d-135-15d-185-1ac 5
hdiskpower65 006E 1a,d7 01e-046-06e-096-0be-0e6-10e-136-15e-186-1ad 6
hdiskpower66 006F 1b,c7 01f-047-06f-097-0bf-0e7-10f-137-15f-187-1ae 6
hdiskpower67 0070 1c,c8 011-048-070-098-0c0-0e8-110-138-160-188-1a0 6
hdiskpower68 0071 1d,d8 019-049-071-099-0c1-0e9-111-139-161-189-1a8 6
lv的划分需要尽量跨在多个物理硬盘上，dbs1和dbs2的lv最好能避开oracle，所以需要尽量划在oracle占用比较少的物理硬盘上，建议的lv划分如下：
lv00 (/altibase_dbs1): hdiskpower 4,5,54,55,56,57,6,7,8,9,10,11 -12个pv
lv01 (//altibase_dbs2): hdiskpower 20,21,58,59,60,61,12,13,14,15,16,17 -12个pv
lv02 (/altibase_logs) : hdiskpower 18,19,62,63,64,65,66,67,68 -9个pv
lv 的Stripe Size为64K。stripe width 为4。
后记：
条带后的效果非常明显，同步不再存在积压情况，在条带之后的1年，没有再出现任何问题。
其实这也不是第一次出现问题。以前也出现过，只不过一般也都是半年才出现个一次。
其实这个事情上给我们几个教训：
1、系统在设计阶段你就得做好规划。从底向上，得有一个通盘的考虑。
2、给EMC这样的原厂厂家提需求的时候，最好能细节化。比如详细的你对binfile要求。在后面的另一个项目中，又郁闷了一次。新买的DMX4存储，在美国就给灌好了binfile，这个binfile我没有提很多细节的东西。结果因为赶进度，没有时间再重新调整了。存储的划分没有达到我的一个比较理想的情况。
3、原厂的话不能尽信。很多的东西你必须得亲眼看到才行。这也是无数次的教训了。
4、有时候你要坚持你的判断，相信自己。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10867315/viewspace-580381/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/10867315/viewspace-580381/
扫一扫
975
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
