AIX5L中创建零偏移量LV

在AIX5.3上实施Oracle10gr2 RAC，采用裸设备，在alert日志中报告如下错误：
WARNING: Oracle recommends creating new datafiles on devices with zero offset. The command "/usr/sbin/mklv -y LVname -T O -w n -s n -r n VGname NumPPs" can be used. Please contact Oracle customer support for more details.

成功解决后，关于此问题整理如下
查询表明，Oracle在使用LV时，得到创建的LV不是0偏移量的LV，看来Oracle还是挺智能的，如果能在建库的时候报出错误来的话就更好了，至少不用重建一次库了，呵呵。
AIX中支持的VG类型
在AIX5.3中，系统支持三种类型的VG，分别是Original VG、Big VG、Scalable VG（AIX5.3的新特性）。
mkvg命令默认将创建Origninal VG：最大支持32 physical volumes and 255 logical volumes
mkvg –B命令将创建Big VG：最大支持128 physical volumes and 512 logical volumes
mkvg –S命令将创建Scalable VG:最大支持1024 physical volumes, 256 logical volumes and 32k physical partitions
(Note: with –v , Number of logical volumes can be increased to 4096 , and with –P , Total number of partitions in the volume group can be increased to 2048k .   Increasing maxlvs and maxpps beyond the default values for a scalable volume group can significantly increase the size of the VGDA proportionately.  The maxlvs and maxpps values should only be increased as needed because they cannot be decreased. Meanwhile, as the VGDA space increases all VGDA update operations can take longer and longer to run.)
关于LVCB
Each logical volume has a logical-volume control block (LVCB) located in the first 512 bytes. Data begins in the second 512-byte block. This area holds important information such as the creation date of the logical volume, information about mirrored copies, and possible mount points in the JFS.
In a raw logical volume, the LVCB is not protected. If an application overwrites the LVCB, commands that normally update the LVCB will fail and generate a message. Although the logical volume might continue to operate correctly and the overwrite can be an allowable event, overwriting the LVCB is not recommended.
应用程序直接访问LVCB是比较危险的，因此在建立数据文件使用的裸设备时，不能从逻辑卷开始位置，而是应该有一个偏移量(offset)，偏移量的大小应大于LVCB的大小，一般用一个AIX逻辑块的大小做偏移量，即4096字节。Oracle数据库会自动跳过前 4k不用，这样保证了lvcb不会被覆盖，但这带来了另一个潜在的问题，当 Oracle的db_block_size大于4k的时候，一个Block可能跨在两个PV/LUN/磁盘上(如果做了条带化，那么将总有数据块跨在两个条带上--其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候，很有可能造成大量的IO不完整，一个PV上IO写入，另一边可能未完成，启动Oracle的时候将会看到ORA-1578 错误，这几乎是致命的。不仅仅是strip的问题，只要一个lv跨越在多个pv上，就可能有这个问题，因为PP的大小肯定也是一个整数，如128M，那么(128M-4k)/8K还是除不尽的。
For example, for database with a db_block_size of 16K and a RAW volume with stripe layout and stripe width 32K, every other db_block spans two LUNS/disks.
如图，这是strip大于db_block而且又含有offset的情况，在block4上有db_block跨越strip的问题
DS_LV和DS_LVZ
原有的带有偏移量的lv类型就叫做DS_LV。未解决上述问题，AIX引进了一种新的LV类，也就是“Z”类型LV，这种类型的LV通过lslv -L lv_name可以看到它的类型为：DS_LVZ。
#lslv -L lv_test
    ......
    DEVICESUBTYPE : DS_LVZ
或者，Oracle的dbfsize也可以检查
$dbfsize /dev/rlv_test
    Database file: /dev/rlv_test
    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类型说明。
ORACLE工具也可以得到数据文件对应lv类型的显示：
$ dbfsize /dev/rlv_test2
Database file: /dev/rlv_test2
Database file type: raw device without 4K starting offset
Database file size: 920 8192 byte blocks

零偏移量LV的创建：
1.在Origninal VG中，不论是否使用“-T O”参数，创建出来的lv都是DS_LV类型。
2.在Scalable VG中，不论是否使用“-T O”参数，创建出来的lv都是DS_LVZ类型。
3.在Big VG中，使用“-T O”参数，创建出来的lv都是DS_LVZ类型，而不使用则是DS_LV类型。

由此可见，为了解决alert日志中报告的问题，使用scalable VG或是big VG创建DS_LVZ类型的LV(zero offset)即可解决。
但对于Big VG，OS这边还有一个很严重的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
的这个版本，包括以后，Big VG使用“-T O”，创建成功的DS_LVZ类型的LV，在经过chlv或者是其它lvm命令，如varyoff/varyon之后，这个标志会消失。这个情况是比较可怕的，如你采用新创建的lv创建了数据文件，但是，后来，因为HA切换或者其它原因varyoff/varyon了这个VG，甚至exportvg/importvg了这个VG，新的LV在数据库看来，不是DS_LVZ类型而是DS_LV的类型LV，数据库就将试图跳过4k的偏移，但是偏移其实是不存在的。具体解决方案就是，使用scalable类型的VG或者是打IY94343的补丁。
http://www-1.ibm.com/support/docview.wss?uid=isg1IY94343

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16689238/viewspace-534842/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16689238/viewspace-534842/