LVCB与ORACLE的问题

  在lu论坛看到对这个问题的讨论，觉得AIX工程师和ORACLE工程师都应该引起注意。在SCARABLE VG里不会存在这个问题，但在normal vg里就需要注意了，特别是normal vg转scarable vg的时候。还有oracle在运行的时候，一个block跨越了lun/disk的时候。最后在使用big vg遭遇bug的时候。以下是选自PINER blog上的文章，他对此做了详细的描述。

 

原文地址：

 

在Oracle 9iR2以前，在IBM AIX上使用lv raw（裸设备）作为Oracle数据文件的话，lv头部是存在一个4k的lv管理区的。正因为这个4k的lv头部，会导致8k以及8k以上的Oracle block（Oracle块）在使用这样的lv的时候，或者是lv strip（lv条带）的时候，可能会导致一个block跨在2个pv上面。最严重的后果就是，如果os写了一个pv上的半个块之后，来不及写下一个pv上的半个块（如果是在同一个pv则可以保证一个block同时被更新），这个时候系统崩溃或者掉电，将导致这个块前后不一致，也就是块corrupted:ORA-01578, 00000, “ORACLE data block corrupted (file # %s, block # %s)”。

为了改变这个现状，AIX在Oracle 9iR2以后，引进了一种新的LV类型，也就是“Z”类型LV，这种类型的LV通过lslv lv_name或者lslv -L lv_name可以看到它的类型为：DS_LVZ

#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才能支持，因为它没有lv的头部了，那么，lv肯定就要靠VGDA来管理了。

这样的LV就是Big VG或者是5.3开始引进的Scalable-type VG，加上原始的VG，那么，在最新的5.3系统中，将有3中VG类型的差别，而5.2则只有big VG与普通VG。

通过mkvg -B可以创建big vg，通过mkvg -S可以创建Scalable-type VG，至于这两个VG类型上的差别，可以查看man mkvg，我在这里只说明它们在对“Z”类型LV，也就是DS_LVZ类型（没有4k头部的lv）以及普通DS_LV类型的lv上的差别。

1、对于Big VG，是唯一允许同时存在这两种LV类型的VG，如果我们指定-T O（注意，这里是大写的字母O），则创建DS_LVZ类型的LV，否则，创建普通类型的LV。如

#mklv -y’lv_test’ -t’raw’ -T O testvg 8 hdisk3

2、对于普通的VG，不管你使用什么命令创建lv，都是普通的DS_LV类型的LV

3、对于Scalable-type VG类型的VG，不管你使用什么方式的命令创建lv，都是扩展的DS_LVZ类型的LV

到这里，AIX应当只终于有一个彻底的解决方案了，根据你的实际情况，你可以选择不同的VG来管理你的LV。

问题似乎说的很清楚了，解决方案也很完美了，那么，结束了吗？没有，因为有bug

在文件集

bos.rte.lvm 5.2.0.97 (5200-09-03) and later bos.rte.lvm 5.3.0.53 (5300-05-04) and later

的这个版本，包括以后，出现了一个bug，正确的OS版本应当是5305或者是5209?（5.2的小版本我不太清楚是哪一个，只能靠检查文件集版本了）以后，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.

Solution is to apply fix:

其实，除了AIX自己的LVM，veritas的LVM管理在AIX上也有同样的问题，为了解决这个问题，veritas LVM推出了一种叫DS_VMZ类型的LV for aix。为了支持这个类型，Oracle 9205或者10.1以后，有一个对应的patch需要注意：patch 3712203：

3712203 BACKPORT THE ZSUBTYPE PATCH FOR VERITAS DEVICE FOR 9.2.0.X AND 10.1.0.X.

相关讨论，可以参考

 

--当数据库的数据文件建在AIX normal vg里的lv上，由于normal vg的限制我们需要将normal vg改成scarable vg。改完后oracle数据库就起不来了。因为：在normal vg里的lv，oracle会跳过4K然后读取数据文件的数据。改为scarable vg后，oracle直接从lv头部去读，这样当然是读不到的。因为数据并没有往前移。我们可以用以下命令把lv的整个数据向前移动4K：dd if=/dev/lvname of=/dev/lvname  seek=0 skip=1 bs=4k