Oracle 11g RAC 警告处理 续集

 分析：

metalink给出的分析和解决方案我的理解如下，如有错误请指正。
一、目前现状是有警告信息，还未出现ora-1578错误，我们目前可以做出的选择有以下几种：
1、解决此问题
    解决方式可以参考给出的方案a和方案b，由于此问题并非oracle RAC软件配置导致的问题，而是由裸设备配置aix导致的问题。由于裸设备配置参数都由先前管理员按照规定设定，我查阅了日志：
    CRMPODB2[/tmp]#cat oraclelv.sh

mklv -y'cp_crs1024m' -t 'raw' oraclevg 8 hdiskpower4

mklv -y'cp_vote1024m' -t 'raw' oraclevg 8 hdiskpower4

mklv -y'cp_system_1024m' -t 'raw' oraclevg 10 hdiskpower4

mklv -y'cp_pwdfile_100m' -t 'raw' oraclevg 1 hdiskpower4

mklv -y'cp_sysaux_800m' -t 'raw' oraclevg 10 hdiskpower4

mklv -y'cp_undo1_4096m' -t 'raw' oraclevg 40 hdiskpower4

mklv -y'cp_undo2_4096m' -t 'raw' oraclevg 40 hdiskpower4

mklv -y'cp_temp_4096m' -t 'raw' oraclevg 40 hdiskpower4

mklv -y'cp_example_800m' -t 'raw' oraclevg 10 hdiskpower4

mklv -y'cp_users_800m' -t 'raw' oraclevg 10 hdiskpower4

确认裸设备没有加-T O参数。
在aix和oracle9/10的某些版本中有过此问题导致的极端情况，导致ora-1578。产生重大错误。但在oracle11g中没有明确指出此问题是否已经修复。因此建议首先考虑aix调整方案采用方案a进行修正。

方案b采用前务必先对数据库进行备份。

方案b简单的描述是按照裸设备调整后的情况再进行重新的oracle安装和rac的实施，时间周期会导致系统至少1天不可用。

即使方案a操作失败，依然可以使用方案b进行此问题的修复。但会花费较多的时间。


2、忽略此问题
首先，忽略此问题并不是放任不管。这样违背系统管理的基本要求。忽略此问题是建议对此问题进行深入的研究，依据专家意见及现场观察分析，控制此问题导致ora－1578错误的几率，达到对此风险的全面掌控，而形成系统管理的经验积累。

问题原因是裸设备没有- T O，-T O 对于大 vg 格式卷组，-T O 选项表示逻辑卷控制块不会占用逻辑卷的首块。因此，该空间可供应用程序数据使用。应用程序可以用 IOC INFO ioctl 识别此类逻辑卷。逻辑卷具有设备子类型 DS_LVZ。不使用该选项创建的逻辑卷具有设备子类型 DS_LV。对于旧的且可伸缩的 vg 格式卷组忽略该选项。

一般情况下，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的注意事项

      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

为了解决这个问题，AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后，创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间， LVCB 的信息保存在 VGDB(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 工具可以做到。Updated: offset 命令工具需要安装 RAC 组件才可用，Oracle 另外提供了一个补丁来弥补这个问题，在 Patch 3242957 中可以找到，直接解压缩，把工具提取出来即可用。 通过另一个工具可以看到相关信息：

    $ 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 则会报告读取数据文件头错误

在oracle11g RAC选件中offset已经修复了很多此类问题。因此经过深入分析，得出结论，目前的几个警告信息最后导致ora-1578的原因有3种：
1、外部lun的操作，对vg的移动、修改等
2、oracle做异步写的时候会让aix日志产生错误的信息。
3、系统掉电、意外停机等。

在oracle11g中导致出现这种情况的可能性非常小，但不排除也有极端出现的可能。

该系统尽量不要在外部进行vg操作，保证供电及意外停机。至于第2种情况，在oracle11gRAC环境下可以暂时忽略。做好每天的备份，以防止极端情况的出现。

另外给出一个aix下的lvcb问题的解决方案，以供参考：
在AIX系统中，用逻辑卷治理器（LVM）来治理存贮设备，这是他差别于传统的UNIX系统的一个重要特征，也是AIX系统的一大优势。

大多数用户的应用系统把数据库空间直接建立在逻辑卷上，而且使用裸设备的方式存放数据，由于数据库厂商使用不了不同的方法访问裸逻辑卷设备，就出现这样一个问题：数据库程式是否覆盖逻辑卷的LVCB。

我们都知道，逻辑卷控制块（LVCB）保存着逻辑卷的重要信息，他位于在逻辑卷开始，占用了512个字节。逻辑卷控制块包括的信息有：逻辑卷创建日期、逻辑卷的映像拷贝数和安装点（如果在逻辑卷上创建了一个JFS文件系统，才有安装点）。使用命令/usr/sbin/getlvcb能够获得逻辑卷的 LVCB。
下面是用getlvcb命令显示逻辑卷lv1中的LVCB信息：

#getlvcb -TA lv00
AIX LVCB
intrapolicy = m
copies = 1
interpolicy = m
lvid = 000d287353697130.16
lvname = lv1
label = /allenfs
machine id = D28734C00
number lps = 1
relocatable = y
strict = y
stripe width = 0
stripe size in exponent = 0
type = jfs
upperbound = 32
fs = log=/dev/hd8:options=rw:account=false
time created = Fri Apr 13 17:16:35 2001
time modified = Fri Apr 13 17:16:38 2001

在getlvcb命令执行后，输出结果的第一行是“AIX LVCB”，这是AIX逻辑卷的标志。上面的显示的LVCB信息同样保存ODM数据库中，getlvcb命令是直接从逻辑卷上获得LVCB的内容。许多 LVM命令在运行时需要更新LVCB的内容，并且要确保LVCB的内容和LVM一致。更新LVCB之前，先读取旧的LVCB内容，分析其是否有效，如果确定其正确有效，则更新，否则就会出现问题，不能更新LVCB，同时提示如下错误信息：

Warning, cannot write lv control block data
用户为了能够让应用程式直接访问逻辑卷而创建了一个裸逻辑卷，大多数情况下应用程式会覆盖逻辑卷的LVCB，然而这并不是致命性的问题，用户仍然能在这个逻辑卷上执行维护命令：extendlv、mklvcopy、rmlv和crfs ?d（这个命令会损坏LVCB中的所有信息），但并不是所有的LVM命令都能成功执行，例如就无法输入（Import）一个逻辑卷，所以他需要一个正确有效的LVCB才能执行成功。

因此通过应用程式直接访问LVCB是比较危险的，直接访问裸逻辑卷一般用于数据库系统。数据库系统使用裸设备存放数据以提高性能，例如informix的数据空间（DBSpace）能建立在一个熟设备上（例如文件系统中的一个文件），也可建立在一个裸设备上（即裸逻辑卷，有时也称为生设备），当建立在裸逻辑卷时，最佳不要让数据空间位于裸逻辑卷的开始，应该有一个偏移量（offset），偏移量的大小应大于LVCB的大小，一般用一个AIX逻辑块的大小做偏移量，即4096字节。不过有一些数据库厂商利用他们自己的方法治理逻辑卷，却覆盖了LVCB。

如果不知道逻辑卷开始的512个字节是LVCB，数据库程式覆盖了一个完整的LVCB，就破坏了逻辑卷的LVCB，这样非常有可能损坏数据库，要解决数据库问题只能找数据库厂商，而大多数数据库系统的最新版本都避免了这种问题的发生，除非是用户在建立数据空间时没有考虑LVCB的存在。

用上面提到的getlvcb命令能检查逻辑卷的LVCB是否被损坏，如果字符串“AIX LVCB”出现，则表明LVCB是好的，除此之外，还能用下面的命令检查逻辑卷的LVCB是否完整：

#od -c /dev/hd1
0000000 A I X L V C B ＼0 ＼0 j f s ＼0 ＼0 ＼0
0000020 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0
0000040 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 0 0 0 d 2 8
0000060 7 3 5 3 6 9 7 1 3 0 . 1 6 ＼0 ＼0 ＼0
0000100 ＼0 ＼0 ＼0 l v 0 0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0
0000120 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0
*
0000200 ＼0 ＼0 ＼0 F r i A p r 1 3 1 7
0000220 : 1 6 : 3 5 2 0 0 1 ＼n ＼0 ＼0 ＼0 ＼0
0000240 ＼0 F r i A p r 1 3 1 7 : 1
0000260 6 : 3 8 2 0 0 1 ＼n ＼0 ＼0 ＼0 ＼0 ＼0 D
0000300 2 8 7 3 4 C 0 0 ＼0 y m m ＼0 y ＼0
0000320 ＼0 001 ＼0 001 / a l l e n f s ＼0 ＼0 ＼0 ＼0
0000340 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0
*
0000520 ＼0 ＼0 ＼0 ＼0 l o g = / d e v / h d 8
0000540 : o p t i o n s = r w : a c c o
0000560 u n t = f a l s e ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0
0000600 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0 ＼0
*
… …

当出现“AIX LVCB”字样，就说明LVCB是好的，否则就被损坏。如果逻辑卷的LVCB被损坏，而关于LVCB的内容还在ODM数据库中保存着，因此通过下面的命令能恢复逻辑卷上的LVCB：
#echo "AIX LVCB＼0" | dd of=/dev/lv1 bs=1 count=9
#updatelv lv1 datavg (lv0是逻辑卷名，他属于datavg卷组)

第一条命令是把逻辑卷标志写到从逻辑卷开始的9个字节中。第二命令是把ODM数据库中关于这个逻辑卷的LVCB内容写到从逻辑卷开始的512个字节中。

如果LVCB中的fs字段内容被删掉了，还必须用chfs命令按照ODM数据库中的其他内容，更新这一项：
# chfs -a log=/dev/hd8 /allenfs

如果在ODM数据库中未找到关于这个逻辑卷的信息，那么这个逻辑卷可能就无救了。

原文链接： http://blog.csdn.net/jaminwm/article/details/4205162