1. TSM（Tivoli Storage Manager）在产品易用性方面真是不如Veritas的NBU，甚至也不如HP的Omni DP。
2. 高端带库的I/O速度不弱于盘阵，跟I/O通道个数以及驱动器个数关系很大。
3. 使用2个channel往84块单盘300G的底层作了0+1 RAID的21个物理卷组成的ASM磁盘组中（好拗口 …）restore 2T大小的数据库耗时6小时。
4. 目前看来，所有的ASM磁盘组信息都没有存在任何配置文件中，无论是进入asmcmd还是选择v$asm相关视图，都是实时从PV头部读取的信息。所以在ASM使用外部冗余的磁盘组中一块PV坏掉以后，可以直接用dd来清除该磁盘组中所有其他disk的头部信息，然后重新创建磁盘组，然后用RMAN恢复数据库，这也是当ASM磁盘组崩溃以后唯一的修复方法。
5. 条带并不是越多越好。在这个环境中，112块disk在硬件级别做了RAID 0+1的条带和镜像，操作系统中对这112/2*300G=16T的存储做了56个PV，如果在创建LV的时候又选择了条带选项（二次条带化），那么读性能将会严重下降，每秒只能达到60M的读，而如果去除二次条带化，则读性能可以上升到每秒200M。
原因：在将数据写入做了二次条带化的存储上时，首先数据在操作系统级别被打散为56个stripe，然后每个stripe在硬件级别又再次被打散为56个stripe，这样并行写的性能是没有问题的，但是在读取的时候，由于请求的数据在硬件级别是被打散在56块disk中的，而硬件级别的缓存机制在读取一块disk上的数据时将会缓存相邻的大量数据，而这些缓存对于此次读取来说都是无用的，当从另外一个disk中再读取需要的数据时，缓存又需要被腾空再容纳这个disk上的数据，但是这次缓存中又只有很小一部分数据是有用的，因此当PV越多的时候，二次条带将导致越大的性能下降。
6. 10g的新功能change tacking貌似有些bug，在头天晚上启动了change tacking，然后做了level 0备份，2.1T的数据文件总共备份出200G的备份集，第二天做了level 1备份，居然备份出2.1T的备份集，也就是change tracking告诉RMAN在这一天里面所有的data block都发生了变化，所以RMAN备出了数据库中所有block，但是实际上这很明显是不可能的，因为当天的归档日志备份只有500多M，第三天仍旧是level 1备份，就比较正常了，当天产生60多G的归档日志，但是level 1备份只花费了3分钟，这是change tracking真正的威力显示了。
好深奥。
很勤奋啊帅哥，最近研究不少东西啊！
正在全程support目前国内最大的Oracle 10gR2 RAC + ASM项目，所以这些研究都是被迫的，不过这种被迫我还是很enjoy的，比自己看书做实验效率高多了。
关于5的说法有点问题的，从lv条带到硬件条带，并不是落在所有的硬盘上了，与条带大小有关系。
lv条带不适合太多，不是这个原因，而是因为
1、底层已经条带，这里条带不能带来跨越到更多的磁盘上
2、条带的太多了，毕竟是软条带，有关系负担。
而且，你们在最底层用112做一个raid组，也不是太合适的。
to piner
112块做0+1，所以实际上只有56块做了条带，每块300G，10000转，盘阵是IBM的DS4800，属于中端盘阵吧，在你的经验里面应该可以达到1G吞吐量？我看DS4800的介绍上也只是最多支持1.6G吞吐量而已。
需要16T的存储空间，如果不用112块做RAID组，该如何操作？
你说的原因仅仅是解释了条带太多并不能带来性能提高，而在我的测试里面去除LV条带，读性能上升3倍，恐怕也不仅仅是因为软条带的管理负载吧。因为使用软条带的时候，写性能并没有下降。
DS4800跟emc cx3-80是差不多的对等产品，都是4GB的产品线，cx3-80测试的时候，每块硬盘可以到8M的流量，我们当时105张硬盘，就到了快1G
你可以做多个raid组，可能争用更少一些，软条带适合作在不同的raid组上面，一个raid组上做软条带没有意义。
读的性能差，很可能是因为在排队。
留言留不上了，郁闷
嗯。。你被Spam Karma 2当成spam了。。。哈哈，恢复了。
关于RAID组，我的描述里面省略了，其实并不是只有一个RAID组，14块盘做一个RAID组，56块盘的条带是4个RAID组组成的。
我们的测试中每块盘的IO似乎也不低，6-7M应该是有的，但是整个加在一起就完全不是线性的关系了，下次我再咨询一下IBM的工程师。
话说的太满了,最大的?
2007年那会儿国内还有更大的商用项目超过6节点的RAC？