【转载】AIX LVM LVCB 和 Oracle 4k Offset的思考

转载于 2015-02-01 07:30:47 发布 · 1.2k 阅读

34 篇文章

订阅专栏

本文探讨了AIX Logical Volume Manager (LVM) 中 Logical Volume Control Block (LVCB) 对Oracle数据库的影响，尤其是在条带化配置下出现的数据块损坏问题。文章详细介绍了如何利用新型DS_LVZ类型的逻辑卷来规避这一问题，并提供了针对不同AIX VG类型的建议。

本文转自：http://bldmickey.blog.sohu.com/55905939.html

原文作者：bldmickey@gmail.com

2007-07-19 17:05 阅读(1274)评论(0)编辑删除

版权声明：转载时请务必以超链接形式标明文章原文出处和作者信息
个人声明：文章中的内容如果引用了您的原创,给您带来了负面的影响,请联系我
技术支持：如果有任何文章相关的技术问题,请联系 bldmickey@gmail.com

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上了，如下图（例子来自于老农的文章）：

当系统崩溃的时候，很有可能造成大量的 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 devicewithout 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数据库还不一定是致命的。