这可能是 Oracle 在 AIX 平台上最重要的一个潜在问题。
一般情况下，AIX 的逻辑卷前 4k 用于存储 control block (LVCB)，在 Oracle 9iR2 之前，Oracle 软件自动跳过这 4k 而不用。这带来了一个潜在的问题，当 Oracle 的 db_block_size 大于 4k 的时候，一个 Block 可能跨在两个 PV/LUN/磁盘 上(如果做了条带化，那么将总有数据块跨在两个条带上--其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候，很有可能造成大量的 IO 不完整，一个 PV 上 IO 写入，另一边可能未完成，启动 Oracle 的时候将会看到 ORA-1578 错误，这几乎是致命的。
为了解决这个问题，AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后，创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间， LVCB 的信息保存在 VGDA(volume group describe area) 里面。前 4k 空间被使用的 LV 有了一个新的设备子类型(devsubtype)标记: DS_LVZ，通过 lslv 可以看到。(Oracle 也在 9.2.0.3 之后自动识别 AIX 的新 LV 类型，直接开始使用 LV 的前 4K 空间)
对于 AIX 的可扩展性 VG，则默认创建的 LV 就会 DS_LVZ 类型，不使用 －T O 也是这样子。Big VG 可能只是一个过度类型。
在 IBM 的系统手册中可以看到：
The IOCINFO ioctl operation returns the devinfo structure, as defined in the /usr/include/sys/devinfo.h file
如何知道当前裸设备创建的时候使用了 -TO ? Oracle 10g 的文档中说 $ORACLE_HOME/bin/offset 工具可以做到。可是我居然找不到这个工具。莫非是忽悠人来着? 通过另一个工具可以看到相关信息：
$ dbfsize /dev/rfoo01_pay Database file: /dev/rfoo01_pay Database file type: raw device without 4K starting offset Database file size: 920 8192 byte blocks
要想得到完美的东西太难了， AIX 在 BIG VG 上仍然还有很多问题，目前已知的当属这个“MKLV -TO ON BIG VOLUME GROUPS FAILS TO PUT SOME LV INFORMATION”最为严重--得不到正确的devsubtype 类型，Oracle 则会报告读取数据文件头错误，这个更要人命。
DBA 这个工作，还真是脑袋悬在腰带上，风险莫测。
--EOF--
Updated: offset 命令工具需要安装 RAC 组件才可用，Oracle 另外提供了一个补丁来弥补这个问题，在 Patch 3242957 中可以找到，直接解压缩，把工具提取出来即可用。
补充一下, offset 工具在选用了 RAC 工具后才会有，也可以通过安装一个Patch来使用这个工具
幸亏发现了这个问题，否则如果将来存储扩容、os正好升级到 AIX 5.3.0.5 ，那就麻烦大了！
唉,脑袋放在裤腰带上还是比较安全的
问题是不知道什么时候被厂商玩一把,
有问题就是不告诉你,忽悠你,看你咋的
在这里请教一个问题
系统硬件升级,在未来流行的Oracle RAC平台里面,
选 AIX on P5 还是 HP-UX on Itanium II ? 或者还有其它选择?
我们准备脱离Linux + Intel x86.
多谢.
现在市场上看，肯定 IBM 强势一些，HP 在走下坡路
木匠你们为什么要脱离Linux + Intel x86？有什么问题吗？
cow！
这样的经验是无价的，谢谢分享啊！
感谢Fenng的回复,我的调到澳大利亚OSS的旧同事也是这么说,首推AIX.
wanghai,
也不为啥,可能是公司盈利了,想买更好的硬件,让我选型.
另外数据库应用的吞吐量到了瓶颈.
我感觉Oracle on Linux + x86还是相当稳定的.
如果处理能力够用.
不懂，不过觉得容错这个东西本来就不完美，关键的disk完蛋了还有什么好说的～
天！ 这个留言系统真够可以的，第一遍贴不上，第二次就发现贴2遍了！！！
还算发现的及时的，详细情况还可以参考我这里
http://www.ixdba.com/html/y2007/m05/94-aix-lv-4k-datafile.html#comments
请教个问题，AIX下创建LV时默认block size为应该4K，没想明白为什么4K的偏移量就会导致oracle的某个block可能跨越PV，，如果是8K的话还可以理解。
AIX下创建LV时默认block size为应该4K?
这个说法从何得来 ?
我没太看明白，“这样当系统崩溃的时候，很有可能造成大量的 IO 不完整，一个 PV 上 IO 写入，另一边可能未完成”这个现象是可能存在的，但是跟“逻辑卷4K的控制块”有什么必然的联系呢？
另外，貌似目前为止我个人还没有因为这个4K而发现什么问题。
亏你还是 Oracle 的，:0
这个问题，Oracle 专门有说明文档的啊
如果不做strip，就没有所说的这个问题，只有做了stip，才会有可能有
如果做了strip，那strip size多大是看你的选择，一般是从4k到128k。在这种情况下，有可能会出现这样的情况：因为缺省让出的4k的offset，有的db_block不全在一个strip里，部分被分到了下一个strip里，散乱到其他LUN/PV上，出现潜在的麻烦。
如果offset正好是strip size的大小或倍数，那这种问题也没有了，所以，也怪ORACLE设offset太小气了，如果弄个1M，那这事都没有。我以前搞INFORMIX，习惯的offset 就是5M。
很多人说这是OS的BUG，其实不然。
如果说BIG VG里的LV的识别出现误判，那的确属于OS的BUG。
但归根结底，是属于ORACLE的offset没选择好而导致，属于ORACLE没能考虑到LV的情况合理规划空间的使用，如果ORACLE的offset选择合适了，哪来这个问题呢？
应该是应用去适应OS，而不是OS去适应应用。ORACLE如果认真，是完全能避免这个问题的。
当然，OS做调整，方便应用，那当然更好。
比方说，ORACLE没有OS/400的版本，那是OS/400的问题还是ORACLE的问题啊？
当然，最简单的还是就用Scalable VG
不好意思，我上面说的有缺陷，piner帮我指出了一些，我也又订正了一下：
1、不仅仅是strip的问题，只要一个lv跨越在多个pv上，就可能有这个问题，因为PP的大小肯定也是一个整数，如128M，那么(128M-4k)/8K还是除不尽的。
#确实是，我忽略了这个。
2、这个lv的offset，不是oracle定出来的，是OS定出来的，Oracle只是从最开始能写数据的地方开始写数据，除非oracle强行偏移8K（一个block大小），或者block的倍数
#这个你错了。LVCB只占512byter。至于从哪里开始写，那完全是ORACLE自己定位的。文件系统让出4K，那是AIX建FS的时候定义的。起码我用INFORMIX，就可以指定offset是多少，这就证明是ORACLE自己没做到。
3、偏移大小，不一定非要一个strip的倍数以上，只要是满足上面的2，一个oracle block大小的倍数就可以
#对，这是更准确
4、Scalable VG不是每个AIX版本都有的，5.2就没有
#没错。所以我强烈建议用AIX5.3,它已经出来3年了。
不好意思，我上面说的有缺陷，piner帮我指出了一些，我也又订正了一下：
1、不仅仅是strip的问题，只要一个lv跨越在多个pv上，就可能有这个问题，因为PP的大小肯定也是一个整数，如128M，那么(128M-4k)/8K还是除不尽的。
#确实是，我忽略了这个。
2、这个lv的offset，不是oracle定出来的，是OS定出来的，Oracle只是从最开始能写数据的地方开始写数据，除非oracle强行偏移8K（一个block大小），或者block的倍数
#这个你错了。LVCB只占512byter。至于从哪里开始写，那完全是ORACLE自己定位的。文件系统让出4K，那是AIX建FS的时候定义的。起码我用INFORMIX，就可以指定offset是多少，这就证明是ORACLE自己没做到。
3、偏移大小，不一定非要一个strip的倍数以上，只要是满足上面的2，一个oracle block大小的倍数就可以
#对，这是更准确
4、Scalable VG不是每个AIX版本都有的，5.2就没有
#没错。所以我强烈建议用AIX5.3,它已经出来3年了。
呵呵，我这个Blog留言系统不太好
至于 IBM Big VG 与 Scalable VG 的稳定性，其实也不好说。按理说，Big VG 出来的时间更长，但是这次一样遇到了这么严重的Bug ：iy94343
lvcb 只用 512，我是知道的，但是操作系统的分配单位就是4K，一般来说，Oracle是不会直接去抢这个4K剩余的空间吧
至于Oracle识别不同的LV类型，这的确是Oracle的设计问题
呵呵，我这个Blog留言系统不太好
至于 IBM Big VG 与 Scalable VG 的稳定性，其实也不好说。按理说，Big VG 出来的时间更长，但是这次一样遇到了这么严重的Bug ：iy94343
lvcb 只用 512，我是知道的，但是操作系统的分配单位就是4K，一般来说，Oracle是不会直接去抢这个4K剩余的空间吧
至于Oracle识别不同的LV类型，这的确是Oracle的设计问题
Big VG的推出，本意并不是去掉在LV头部的LVCB，而是支持更大的VG而已，把LVCB不放在LV上只是一个不常用的option，所以有这个BUG我觉得不难理解。
而scalable VG则是彻底考虑到LVCB的问题了，所以应该要好的多。
Big VG 就是为了解决在LV头部的LVCB的问题的
IBM 某个 fix 里面应该描述了这个解决方案。
可扩展的VG 倒是应该使用的
Big VG 就是为了解决在LV头部的LVCB的问题的
IBM 某个 fix 里面应该描述了这个解决方案。
可扩展的VG 倒是应该使用的
Big VG的推出，本意并不是去掉在LV头部的LVCB，而是支持更大的VG而已，把LVCB不放在LV上只是一个不常用的option，所以有这个BUG我觉得不难理解。
而scalable VG则是彻底考虑到LVCB的问题了，所以应该要好的多。
BIG VG如果是为了解决LVCB在LV上的问题的话，建LV的时候就不应该再带选项，至少smit里就应该缺省这样，但实际上没有，所以就说明了这不过是顺带而为。
还有些人没明白为什么会出现跨LUN/PV，我在这里举了例子，并有图示意：http://bbs.loveunix.net/viewthread.php?tid=72034&extra=page%3D2&page=2