AIX RAW LVM 的 4k Offset 问题

这可能是 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 中可以找到,直接解压缩,把工具提取出来即可用。


  • http://www.dbanotes.net/ Fenng

    补充一下, offset 工具在选用了 RAC 工具后才会有,也可以通过安装一个Patch来使用这个工具

  • biti_rainy

    幸亏发现了这个问题,否则如果将来存储扩容、os正好升级到 AIX 5.3.0.5 ,那就麻烦大了!

  • http://www.oracledba.com.cn David.Guo

    唉,脑袋放在裤腰带上还是比较安全的
    问题是不知道什么时候被厂商玩一把,
    有问题就是不告诉你,忽悠你,看你咋的

  • http://zhu1.blogspot.com 木匠

    在这里请教一个问题
    系统硬件升级,在未来流行的Oracle RAC平台里面,
    选 AIX on P5 还是 HP-UX on Itanium II ? 或者还有其它选择?
    我们准备脱离Linux + Intel x86.
    多谢.

  • http://www.dbanotes.net Fenng

    现在市场上看,肯定 IBM 强势一些,HP 在走下坡路

  • http://www.orawh.com wanghai

    木匠你们为什么要脱离Linux + Intel x86?有什么问题吗?

  • http://vecentli.itpub.net vecentli

    cow!
    这样的经验是无价的,谢谢分享啊!

  • http://zhu1.blogspot.com 木匠

    感谢Fenng的回复,我的调到澳大利亚OSS的旧同事也是这么说,首推AIX.
    wanghai,
    也不为啥,可能是公司盈利了,想买更好的硬件,让我选型.
    另外数据库应用的吞吐量到了瓶颈.
    我感觉Oracle on Linux + x86还是相当稳定的.
    如果处理能力够用.

  • sclzmbie

    不懂,不过觉得容错这个东西本来就不完美,关键的disk完蛋了还有什么好说的~

  • sclzmbie

    天! 这个留言系统真够可以的,第一遍贴不上,第二次就发现贴2遍了!!!

  • http://www.ixdba.com piner

    还算发现的及时的,详细情况还可以参考我这里
    http://www.ixdba.com/html/y2007/m05/94-aix-lv-4k-datafile.html#comments

  • catchtime

    请教个问题,AIX下创建LV时默认block size为应该4K,没想明白为什么4K的偏移量就会导致oracle的某个block可能跨越PV,,如果是8K的话还可以理解。

  • http://www.dbanotes.net/ Fenng

    AIX下创建LV时默认block size为应该4K?
    这个说法从何得来 ?

  • http://blog.dbform.com kamus

    我没太看明白,“这样当系统崩溃的时候,很有可能造成大量的 IO 不完整,一个 PV 上 IO 写入,另一边可能未完成”这个现象是可能存在的,但是跟“逻辑卷4K的控制块”有什么必然的联系呢?
    另外,貌似目前为止我个人还没有因为这个4K而发现什么问题。

  • http://www.dbanotes.net/ Fenng

    亏你还是 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的问题啊?

  • http://www.LoveUnix.net 老农

    当然,最简单的还是就用Scalable VG

  • http://www.LoveUnix.net 老农

    不好意思,我上面说的有缺陷,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年了。

  • http://www.LoveUnix.net 老农

    不好意思,我上面说的有缺陷,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年了。

  • http://www.dbanotes.net/ Fenng

    呵呵,我这个Blog留言系统不太好
    至于 IBM Big VG 与 Scalable VG 的稳定性,其实也不好说。按理说,Big VG 出来的时间更长,但是这次一样遇到了这么严重的Bug :iy94343
    lvcb 只用 512,我是知道的,但是操作系统的分配单位就是4K,一般来说,Oracle是不会直接去抢这个4K剩余的空间吧
    至于Oracle识别不同的LV类型,这的确是Oracle的设计问题

  • http://www.dbanotes.net/ Fenng

    呵呵,我这个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的问题了,所以应该要好的多。

  • http://www.dbanotes.net/ Fenng

    Big VG 就是为了解决在LV头部的LVCB的问题的
    IBM 某个 fix 里面应该描述了这个解决方案。
    可扩展的VG 倒是应该使用的

  • http://www.dbanotes.net/ Fenng

    Big VG 就是为了解决在LV头部的LVCB的问题的
    IBM 某个 fix 里面应该描述了这个解决方案。
    可扩展的VG 倒是应该使用的

  • http://www.LoveUnix.net 老农

    Big VG的推出,本意并不是去掉在LV头部的LVCB,而是支持更大的VG而已,把LVCB不放在LV上只是一个不常用的option,所以有这个BUG我觉得不难理解。
    而scalable VG则是彻底考虑到LVCB的问题了,所以应该要好的多。

  • http://www.LoveUnix.net 老农

    BIG VG如果是为了解决LVCB在LV上的问题的话,建LV的时候就不应该再带选项,至少smit里就应该缺省这样,但实际上没有,所以就说明了这不过是顺带而为。

  • http://www.LoveUnix.net 老农

    还有些人没明白为什么会出现跨LUN/PV,我在这里举了例子,并有图示意:http://bbs.loveunix.net/viewthread.php?tid=72034&extra=page%3D2&page=2