LVCB offset导致ORACLE数据恢复失败的问题

请高手解惑 [url=http://www.dbanotes.net/database/aix_raw_lvm_4k_offset.html#comments]http://www.dbanotes.net/database/aix_raw_lvm_4k_offset.html#comments[/url]
没看懂该文说的LVCB的4K偏移量会造成oracle data block可能会跨越2个PV

明显的系统外行的人写的，不必看他的。
LVCB的影响是有的，但不是他说的那样。现在建议用SCARABLE VG，没有这个问题。

农哥，你说的LVCB的影响是指什么，有没有什么文档供参考的？
另外AIX创建LV时的block size是不是默认4K？谢谢

不存在原文作者说的“oracle data block可能会跨越2个PV”问题，不知道他什么意思。

LVCB的影响是指这个
[url]http://www.google.com/search?q=AIX%20LVCB%20%E6%95%B0%E6%8D%AE%E5%BA%93&hl=zh-CN&lr=&nxpt=20.774388429191181377622[/url]
    大多数用户的应用系统把数据库空间直接建立在逻辑卷上，而且使用裸设备的方式存放数据，由于数据库厂商使用不了不同的方法访问裸逻辑卷设备，就出现这样一个问题：数据库程序是否覆盖逻辑卷的LVCB。

不过DB2不存在LVCB被覆盖的问题，其它数据库不了解。

呵呵，谢谢，我有点偷懒了

明显是 Oracle 外行的人在上面胡说啊 :)

回复 #2 老农 的帖子

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".


[url]http://entkb.symantec.com/security/output/a269928.html[/url]

这问题搞不清楚，再多年的Unix经验也不过就是经验而已

我只是说[url=http://www.dbanotes.net/database/aix_raw_lvm_4k_offset.html#comments]http://www.dbanotes.net/database ... ffset.html#comments[/url]的翻译理解有错误而已，有混乱不清楚的。

里面把简单的VGDA写成了VGDB，所以我就没认真看下去了

我并没有说LVCB没影响，而且说了现在建议使用scarable VG，完全避免LVCB的问题。
BIG VG也有参数移走LVCB，避免LVCB的影响。
即使有LVCB，LVCB也只有512BYTER，让多少出来，是ORACLE的事情。

建LV的时候，哪有block=4K这一说？block是在文件系统才说的。LV是以LP/PP为单位。

如果不做strip，就没有所说的这个问题，只有做了stip，才会有可能有

如果做了strip，那叫strip size，不叫block size。多大那是你的选择，从4k到128k。在这种情况下，才有所谓的db_block_size，因为缺省让出的4k的offset，可能出现每个db_block分到不只一个strip里，散乱到各LUN/PV上，出现潜在的麻烦。

但如果offset是strip size的倍数，也不会出这样的问题。
而且即使没有4k的offset，如果db_block_size 比strip size大，不也有同样的问题么？

这实际是怎么样选择stip size和db_block_size 匹配的问题。

不过我对VERITAS不太感冒，我早就了解VERITAS的做法了，广告为主。

LS的批评对，我没有仔细看原文，看到一个错误就懒得细看了，在此道歉。

很多东西，的确值得深入研究

[quote]原帖由 [i]老农[/i] 于 2007-5-13 13:40 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=659821&ptid=72034][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]
我只是说[url]http://www.dbanotes.net/database[/url] ... ffset.html#comments的翻译理解有错误而已，有混乱不清楚的。

建LV的时候，哪有block=4K这一说？block是在文件系统才说的。LV是以LP/PP为单位。

如果不做strip，就没有所说的这个问题，只有做了stip，才会有可能有

如果做了strip，那叫strip size，不叫blocksize。多大那是你的选择，从4k到128k。在这种情况下，才有所谓的db_block_size，因为缺省让出的4k的offset，可能出现每个db_block分到不只一个strip里，散乱到各LUN/PV上，出现潜在的麻烦。

但如果offset是strip size的倍数，也不会出这样的问题。
而且即使没有4k的offset，如果db_block_size 比strip size大，不也有同样的问题么？

这实际是怎么样选择stip size和db_block_size 匹配的问题。[/quote]

VGDB 不过是笔误罢了，何况后面不是有英文解释么? 那里说得Block 自然是 Oracle 的Block

你最后说Strip size 和db_block_size 匹配 ，莫非还有 strip size < db_block_size 的？否则，谈什么匹配? stripsize 必然要是 Db_block_size 的倍数 ，这根本不是什么 匹配不匹配的问题，


说得比较罗唆，不要误解了才是

其实这个问题在一些地方已经有人遇到了，只不过不知所以然忽略了过去罢了，PV/lun 很多的时候非常麻烦

话说回来，老农的Unix经验我很佩服的 :)

问题就在于我看到有错误，虽然这个错误明显是笔误，不过因为文章中没有表明是在条带化下出现的问题，所以我也看得糊涂，就懒得看下去了，因为LVCB的问题我是知道的，觉得肯定是别人没理解清楚而写的，就没看下去了。

恩，我也好像记得db_block_size 应该都小于strip size的，并且应该是strip size的1/n，但自己记不确切了。

如果ORACLE的offset正好是strip size的大小或倍数，那这种问题也没有了，所以，也怪ORACLE设offset太小气了，如果弄个1M，那这事都没有。我以前搞INFORMIX，习惯的offset 就是5M。

当然，最简单的还是就用Scalable VG

[quote]原帖由 [i]beginner-bj[/i] 于 2007-5-10 14:07 发表 [url=http://www.loveunix.net/discuz/redirect.php?goto=findpost&pid=658862&ptid=72034][img]http://www.loveunix.net/discuz/images/common/back.gif[/img][/url]
不存在原文作者说的“oracle data block可能会跨越2个PV”问题，不知道他什么意思。

... [/quote]

我说的是错的。我现在也明白其中的道理了。谢谢FENNG的指教。

[url=http://www.dbanotes.net]http://www.dbanotes.net[/url] 是个不错的BLOG，搞ORACLE的都应该去看看。

通过这个问题，我对AIX平台的RAW DEVICE有了一点新的看法：不同数据库眼中的RAW DEVICE是不同的。就普通的VG来说，DB2认为RAW DEVICE是LV的一部分，即刨去LVCB后剩下的那部分；ORACLE却认为RAW DEVICE就是整个的LV。

欢迎大家讨论和批评指正。

很多人说这是OS的BUG，其实不然。
如果说BIG VG里的LV的识别出现误判，那的确属于OS的BUG。

但归根结底，是属于ORACLE的offset没选择好而导致，属于ORACLE没能考虑到LV的情况合理规划空间的使用，如果ORACLE的offset选择合适了，哪来这个问题呢？

应该是应用去适应OS，而不是OS去适应应用。ORACLE如果认真，是完全能避免这个问题的。
当然，OS做调整，方便应用，那当然更好。
比方说，ORACLE没有OS/400的版本，那是OS/400的问题还是ORACLE的问题啊？

不好意思，我上面说的有缺陷，piner帮我指出了一些，我也又订正了一下：
1、不仅仅是strip的问题，只要一个lv跨越在多个pv上，就可能有这个问题，因为PP的大小肯定也是一个整数，如128M，那么(128M-4k)/8K还是除不尽的。
#确实是，我忽略了这个。

2、这个lv的offset，不是oracle定出来的，是OS定出来的，Oracle只是从最开始能写数据的地方开始写数据，除非oracle强行偏移8K（一个block大小），或者block的倍数
#这个你错了。LVCB只占512byter。至于从哪里开始写，那完全是ORACLE自己定位的。文件系统让出4K，那是AIX建FS的时候定义的。起码我用INFORMIX，就可以指定offset是多少，这就证明是ORACLE自己没做到。

3、偏移大小，不一定非要一个strip的倍数以上，只要是满足上面的2，一个oracle block大小的倍数就可以
#对，这是更准确

4、Scalable VG不是每个AIX版本都有的，5.2就没有
#没错。所以我强烈建议用AIX5.3,它已经出来3年了。

piner的blog：[url]http://www.ixdba.com/html/y2007/m05/94-aix-lv-4k-datafile.html#comments[/url]

-T O 这个O就是指的 Oracle

其实说是Oracle还是AIX的错误已经不重要的，重要的是能让更多的DBA/SA 意识到这个问题

我的AIX经验很少，以后还请老农多多指教

Big VG的推出，本意并不是去掉在LV头部的LVCB，而是支持更大的VG而已，把LVCB不放在LV上只是一个不常用的option，所以有这个BUG我觉得不难理解。

而scalable VG则是彻底考虑到LVCB的问题了，所以应该要好的多。

每个人都很难懂很多，所以，互相交流就能共同提高啊，你的批评就让我更深刻地注意到这个问题的重要性了。

还有些人没明白为什么会出现跨LUN/PV，我举个明显的例子吧：

比如，strip是32K，db_block是8K，如果没有offset，则4个db_block就全在一个stip里了，不会跨LUN/PV。
而有了4K的offset，则肯定第四个db_block就跨strip了，也就成了在多个LUN/PV上了

我的同事还按此画了一个图，看起来就更明了了，我帖出来：

但有人跟我说，db_block是有比strip大的情况的，我现在想找一些确认。

strip是可以设置为比block小，如4K，但是，如果这么设，应当就是在自己找事。

不过，我没有实际去测试过会不会有问题。

对，这样就即使没有offset也肯定出现db_block跨LUN/PV的情况了，图如下：

难得难得，aix与oracle各大高手齐聚一堂，搬个板凳学习，:victory: :victory: :victory:

不错，不错，这个贴子讨论的很有意义，不仅AIX上，Oracle应用中可，基本上每个应用在IO上都有逻辑存储结构和物理存储结构对齐的问题，包括文件系统，VM和裸设备。不仅在于数据可用性，还有读写性能上都有较大影响。做过system planing的同学可能体会也比较深。

大家继续深入讨论啊，把各级别存储组织方式都挖出来看看
:hug:

占个位置学习！