offset 4k oracle aix raw

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以后都没次问题了。

 

from:http://hi.baidu.com/rain_at_dna/blog/item/400b1b8b694648d0fc1f102a.html

 

###################################################################

###################################################################

AIX RAW LVM 的 4k Offset 问题:

 

Fri Jan 16 09:59:39 2009
WARNING: You are creating/reusing datafile /oradata/bldb/sysaux01.dbf.
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.
WARNING: You are creating/reusing datafile /oradata/bldb/sysaux01.dbf.
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.
WARNING: You are creating/reusing datafile /oradata/bldb/sysaux01.dbf.
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.
WARNING: You are creating/reusing datafile /oradata/bldb/sysaux01.dbf.
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.
Sat Jan 17 16:59:32 2009

这可能是 Oracle 在 AIX 平台上最重要的一个潜在问题。

一般情况下，AIX 的逻辑卷前 4k 用于存储 control block (LVCB)，在 Oracle 9iR2 之前，Oracle 软件自动跳过这 4k 而不用。这带来了一个潜在的问题，当 Oracle 的 db_block_size 大于 4k 的时候，一个 Block 可能跨在两个 PV/LUN/磁盘 上(如果做了条带化，那么将总有数据块跨在两个条带上--其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候，很有可能造成大量的 IO 不完整，一个 PV 上 IO 写入，另一边可能未完成，启动 Oracle 的时候将会看到 ORA-1578 错误，这几乎是致命的。

为了解决这个问题，AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后，创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间， LVCB 的信息保存在 VGDA(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 工具可以做到。可是我居然找不到这个工具。莫非是忽悠人来着? 通过另一个工具可以看到相关信息：

$ 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 则会报告读取数据文件头错误，这个更要人命。

 

from:http://2jliu.itpub.net/post/21805/477345