AIX LVM LVCB 和 Oracle 4k Offset的思考

mvdkgretnk

　　AIX LVM LVCB 和 Oracle 4k Offset的思考
　　
引言
　　前段时间看了piner，Fenng和老农关于AIX LVCB对于oracle影响的讨论，感觉有收获，所以总结了大家的看法和自己的心得。具体讨论见下面的链接：
　　http://bbs.loveunix.net/viewthread.php?tid=72034&extra=page%3D2&page=1
　　http://www.dbanotes.net/database/aix_raw_lvm_4k_offset.html#comments
　　http://www.ixdba.com/html/y2007/m05/94-aix-lv-4k-datafile.html#comments
　　欢迎大家的讨论。
　　
问题现象和原因
一般情况下，AIX的每一个逻辑卷前512字节被称为logical-volume control block (LVCB)，包含了LV的一些信息。在 Oracle 9iR2 之前，为了避免和LVCB的冲突，Oracle 软件会跳过前4k字节不用。LVCB的和Oracle跳过4K的特点带来的问题：
　　如果一个VG中包含多个PV，PV做了条带化（stripe），创建的LV跨在不同的PV上，这样会导致下面的问题，例如：如果stripe是32K，db_block是8K，如果没有offset，则4个db_block就全在一个stripe里了，不会跨PV。而有了4K的offset，则肯定第四个db_block就跨stripe了，也就成了一个Oracle DB block跨在多个LUN/PV上了，如下图（例子来自于老农的文章）：
http://118.img.pp.sohu.com/images/blog/2007/7/19/16/19/11476b6d4a6.jpg
　　当系统崩溃的时候，很有可能造成大量的 IO 不完整（如果OS写了一个PV上的半block之后，来不及写下一个PV上的半个block，如果是在同一个PV则可以保证一个block同时被更新），启动 Oracle 的时候将会看到 ORA-01578：“ORACLE data block corrupted (file # %s, block # %s)” 错误，大量的corrupted block对于数据可能是致命的。
　　
AIX解决方法（来自piner）
　　AIX在Oracle 9iR2以后，引进了一种新的LV类型，也就是“Z”类型LV，这种类型的LV通过lslv lv_name或者lslv -L lv_name可以看到它的类型为：DS_LV。例如：
　　# lslv -L lv_test_2g_001
　　DEVICESUBTYPE : DS_LVZ
　　或者，Oracle的dbfsize也可以检查
　　$ dbfsize /dev/rlv_test_2g_001
　　Database file: /dev/rlv_test_2g_001
　　Database file type: raw device without 4K starting offset
　　Database file size: 261248 8192 byte blocks
　　如以上的结果，则显示这个LV是没有4k头部的”Z”类型的LV，如果是普通类型的lv，LV类型是DS_LV，这种类型的LV，在lslv的命令中没有任何SUBTYPE类型说明。这样的LV需要特定的VG才能支持，因为它没有LVCB了（其实LVCB的信息都保存到了VGDA中），那么，LV肯定就要靠VGDA来管理了。
　　
采用Big VG的注意事项（来自piner）
Big VG的一个bug，就是使用-T O，创建成功的DS_LVZ类型的LV，在经过chlv或者是其它lvm命令，如varyoff/varyon之后，这个标志会消失。这个情况是比较可怕的，如你采用新创建的lv创建了数据文件，但是，后来，因为HA切换或者其它原因varyoff/varyon了这个VG，甚至exportvg/importvg了这个VG，新的LV在数据库看来，不是DS_LVZ类型的LV，数据库将试图跳过4k的偏移，但是偏移其实是不存在的。具体解决方案就是，请使用scalable类型的VG或者是打以上的补丁：
　　Problem is caused by defect IY94343 in AIX Operating System.
　　解决方案：http://www-1.ibm.com/support/docview.wss?uid=isg1IY94343
　　影响的用户：
　　Users of BIG volume groups with the bos.rte.lvm fileset at the 5.3.0.53 or 5.3.0.54 level.
　　
Veritas VM的解决方法
在AIX操作系统环境下Veritas VM 兼容AIX Logical Volume Manager (LVM), Oracle同样跳过4k。Veritas VM同样使用一种新的LV类型（devsubtype：DS_VMZ）。
　　Oracle相关支持的信息：
　　Oracle is enhancing both 9iR2 and 10g to recognize this new type of Volume Manager volume. A patch from Oracle will be available soon that needs to be applied to 9.2.0.5 and 10.1. The reference bug number for this Oracle patch is 3712203.
　　AIX OS相关支持的信息
　　This ODM patch recognizes DS_VMZ type RAW Volume Manager volumes. Without this patch, when ODM is enabled, the Oracle instance will fail with error "ORA-01251: Unknown File Header Version read".
　　http://entkb.symantec.com/security/output/a269928.html
　　
AIX VG相关信息
AIX 5.3 VG的类型包括：普通的VG，Big VG，Scalable VG。
　　mkvg创建普通的VG，缺省最大32 PV/1016个PP；
　　mkvg –B创建Big VG，缺省128PV/1016 PP；
　　可以使用mkvg -t选择其它PP数目，对于Big VG，mkvg -t 2表示支持64PV/2032PP，具体见下图：
　　通过mkvg -S可以创建Scalable-type VG。缺省1024PV/256LV/32768PP。
　　对于普通的VG，创建的都是普通的DS_LV类型的LV
　　对于Big VG，是唯一允许同时存在这两种LV类型(DS_LVZ类型没有4k头部的LV, 普通DS_LV类型的lv)的VG，如果指定-T O，则创建DS_LVZ类型的LV，否则，创建普通类型的LV，例如：#mklv -y’lv_test’ -t’raw’ -T O testvg 8 hdisk3
　　对于Scalable-type VG类型的VG，创建的都是扩展的DS_LVZ类型的LV
　　
思考
1．出问题的前提：用了AIX裸设备做datafile，且做了stripe，且LV不是DS_LVZ类型。
　　2．建议使用Scalable VG（Scalable VG在5.2没有）
　　3．如果Oracle软件写数据的偏移大小是oracle block大小的倍数，就不会出现上面的问题（例如：偏移4k,oracle block size 4k就没有问题；如果偏移可以设置例如8k, Oracle bock size 8k/4k，也不会有问题）
　　4．另一个问题：如果一个LV跨越在多个PV上，不论是否做了stripe，就可能有类似的问题，因为PP的大小肯定也是一个整数，如128M，那么(128M-4k)/8K还是除不尽的（来自piner的文章）。我个人认为：这个是需要考虑的问题，但是远没有stripe带来的影响大。Stripe的情况下会出现大量的DB Block位于不同的PV， 这样系统崩溃会出现大量block corrupted。 如果仅仅是因为某个LV 跨越在多个PV上的问题，这样的影响就小多了，前提是：系统crash的时候正在写LV最后的那个block，而且仅仅一个block的损坏，对oracle数据库还不一定是致命的。
　　
参考
LVCB包含的一些LV信息，例如：lvid，lvname，lvname，machine id，获取LVCB信息的命令
　　# getlvcb -TA datalv
　　AIX LVCB
　　intrapolicy = m
　　copies = 1
　　interpolicy = m
　　lvid = 000ce0e40000d6000000010f0b787726.3
　　lvname = datalv
　　label = /data
　　machine id = CE0E4D600
　　number lps = 1600
　　relocatable = y
　　strict = y
　　stripe width = 0
　　stripe size in exponent = 0
　　type = jfs2
　　upperbound = 32
　　fs = vfs=jfs2:log=/dev/loglv00:options=rw:account=false
　　time created = Fri Nov 24 14:17:35 2006
　　time modified = Fri Nov 24 14:18:15 2006
　　转载于：http://bldmickey.blog.sohu.com/55905939.html

　　from:http://hi.baidu.com/yinyuman/blog/item/b3c01d3834f578fbb311c738.html