offset 命令存在于rac版本里，oracle block on raw lv 存在 offset，aix通常4k（下面veritas一说是Oracle为了保持数据文件在裸设备和文件系统上位置的一致性。文件系统默认block size为4K）。

如果你的offset rawlv不为0，这说明你仍在用 Original VG 或者Big VG（而没有用mklv -TO），因为5.3以后有的Scalable VG上面建rawlv时，子设备类型默认为 DS_LVZ ，那么Oracle9201（？需验证） （若是veritas的rawlv，则是9205?9206以后）会根据这个子设备类型不再忽略first 4k block。

怎样确认目前使用的VG类型呢？很简单，lsvg，看 MAX PVs:

32:Original VG

128:Big VG

1024:Scalable VG

rootvg默认为Original VG

系统默认创建的vg也为Original VG

Original VG 转成Scalable VG，VG必须varyoff，且每个pv都有剩余的足够的未使用pp

如果该VG上存放的是oracle数据，转换之前，oracle一定要备份，因为OS可能会改变块的位置，详见man(该测试，未实际动手试过，而且环境也不可能正好达到man上的环境，来验证是否会导致数据库块失效

/*后记补充

把BIG VG 转换成SCABLE VG，需要把VG varyoff。
man中说如果VGDA需要的PP(on the edge of the disk) 已经被分配，那么这些PP会被移动到同一PV里其它可用的PP中，剩下的那些非VGDA使用的PP将会被重新编号，这将改变该VG中所有PV里LP和PP的映射。此处还有一个搞笑的地方，AIX chvg中文手册中说 VG在并行方式下联机，不能使用-G标志,但是英文手册中没这么写。而实际上，并行方式下是可以使用-G的。

*/

这么看来，再来思考一下，转换的操作是PP层的，Oracle使用的是LP层的，所以应该没有什么关系，但是转换完成后，first block会被移到offset 0的位置吗？不一定吧？最大的可能是offset 0~4k被空了出来。除非创建新的lv才会从offset 0开始，或者rman backup database/restore database 估计会把偏移的问题纠正过来。很可怜，我的生产系统正好是offset的牺牲品，感觉上来说，除了halt -q的突然宕机的数据安全性以外，性能影响估计也很大。

)

AIX RAW LVM 的 4k Offset 问题

前提是否是使用raw lv才会发生呢？

（Yes??

http://seer.entsupport.symantec.com/docs/269928.htm

Until Oracle version 9iR2, Oracle always skipped the first 4K bytes of a RAW LVM. The Oracle header block starts at offset 4K of the RAW volume.   To make Volume Manager RAW volumes compatible with Logical Volume Manager (LVM), Oracle also skips the first 4K of a Volume Manager RAW volume.   For databases having   db_block_size larger than 4K, this causes misaligned I/O at the stripe boundary of a striped volume. 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.
To solve this misaligned I/O issue, in 9iR2 AIX introduced a new type of volume with devsubtype DS_LVZ. This kind of LVM is also called a "z" type volume. From 9iR2 onwards, Oracle started recognizing these new "z" type volumes and does not skip the first 4K bytes in the volume.

VERITAS also enhanced Volume Manager and introduced a new type of volume with devsubtype as DS_VMZ. This kind of volume is also termed "o" type Volume Manager volume. 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.

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

这段文章中都是讲raw lv的，所以FS应该是被排除在外的，而且FS又有一系列复杂的cache机制，估计应该不会有上述的问题，？？也不尽然吧？？但是4k所引起的性能问题，FS应该也一样有吧？？）

这种可能的环境为：

(Original VG 或 Big VG未使用 -T O)+db_block_size > 4k+lv跨越多个pv

我的生产系统恰是这种环境！~~~

不可能的环境：

(Scalable VG 或 Big VG使用 -T O) 或 db_block_size = 4k 或 lv不跨越多个pv

推荐做法：

（写此文时还不能确定文件系统是否也会发生大虾们所讨论的问题）

使用Scalable VG、远离raw lv、使用ASM/CFS

文中所链接的bug：

http://www-1.ibm.com/support/docview.wss?uid=isg1IY94343

描述：大概就是讲5.2，5.3的系统在特定的版本里会出现 mklv -TO后再有chlv或者任何将会更改VGDA或者一个reboot 操作后，原本的lslv中的子设备类型DS_LVZ 会改变，这样Oracle 无法startup……后面的解决状况估计也比较麻烦，不想再去想象；而Oracle运行的过程中，应该没有人去做chlv的操作吧？？

大概是5210、5306、5307以后都没次问题了。