AIX5.3.0.5 BIG VG 的 LVCB 差点坑了我

biti_rainy

以前在 AIX 5.3.0.2 的时候，我们使用 mkvg   -B   参数创建 big vg ,使用  -T O 参数创建 LV ，这样oracle 在使用raw device的时候,可以使用 lvcb 的 4k 空间 。 \r\n这样有一个好处，就是oracle 的8k 的block size ，在lv有做stripe 的情况下，可以避免一个 oracle block 跨越在两个 pv 上。  在很极端的主机hang的情况下，一个oracle  block 如果正好在两个 pv上则可能被分为2个io ，如果恰好只完成了一个，那么oracle 的block就可能是 corrupt 状态。\r\n\r\n虽然这个概率很小，但是能避免我们就是需要避免的。\r\n\r\n这次我们安装了 AIX 5305，结果，mkvg -B 创建的vg，lvcb 依然存在并且无法被oracle 使用。\r\n这太出乎我的意料了。 最后测试使用了  mkvg -S  创建的增强型的vg，这个终于可以使用前4k 空间了。\r\n\r\n居然有这种事情。 51假期结束，我将去测试目前5302升级到5304的系统，看新创mkvg -B创建的vg 是如何的表现（5304上从5302升级来的是正常的）。  假如5304也一切ok，那5304的os升级到 5305 又是如何一个表现呢？  那不叫人吐血？这还需要仔细测试。

花好月不圆

老大 ,我用4k 的db block size 也有warning 啊 \r\n估计不是 lvcb的问题. \r\n也许 oracle 认为有问题,实际没有问题, \r\n我string dd 出来的8k, 绝大部分没有数据, 少数有以前遗留的数据

花好月不圆

我的 是5305-06\r\n\r\n我每次 也是big vg  和 -T O 参数,但 \r\n只有一次成功建立过没有任何warning 的库. \r\n并且 很奇怪的是 先升级到10203 是无法建库的

biti_rainy

最初由 花好月不圆 发布\r\n[B]老大 ,我用4k 的db block size 也有warning 啊 \r\n估计不是 lvcb的问题. \r\n也许 oracle 认为有问题,实际没有问题, \r\n我string dd 出来的8k, 绝大部分没有数据, 少数有以前遗留的数据 [/B]

\r\n\r\n我的环境也是  5305-06\r\n\r\n我这个不是  warning的问题\r\n我是再坐 standby,如果 将 数据文件 直接  dd 进去 不考虑 跳过前 4k ,则 oracle 无法识别 数据文件. \r\n\r\n若再数据库中增加数据文件,dd 出来 包括前4k ,则 数据文件也无法识别的(使用 dbv检查).\r\n若 将数据库中数据文件 跳过 前 4k  dd出来,则 dbv 可以正确识别 .\r\n\r\n几种组合测试表明,oracle 不能 使用 rlv 的前4k. 而使用  mkvg  -S就能正常使用  rlv 的前 4k.

花好月不圆

这次我们安装了 AIX 5305，结果，mkvg -B 创建的vg，lvcb 依然存在并且无法被oracle 使用。\r\n这太出乎我的意料了。 最后测试使用了 mkvg -S 创建的增强型的vg，这个终于可以使用前4k 空间了。\r\n\r\n===============================================\r\n\r\n那么．你这样创建的LV  你确定　lvcb 存在于lv 的头部？\r\n\r\n\r\n我这样创建lvcb 是没有在lv头部的，只有建库时，好象有问题，就是那些警告．　

biti_rainy

最初由 花好月不圆 发布\r\n[B]这次我们安装了 AIX 5305，结果，mkvg -B 创建的vg，lvcb 依然存在并且无法被oracle 使用。\r\n这太出乎我的意料了。 最后测试使用了 mkvg -S 创建的增强型的vg，这个终于可以使用前4k 空间了。\r\n\r\n===============================================\r\n\r\n那么．你这样创建的LV  你确定　lvcb 存在于lv 的头部？\r\n\r\n\r\n我这样创建lvcb 是没有在lv头部的，只有建库时，好象有问题，就是那些警告．　 [/B]

\r\n\r\n\r\n\r\n\r\n关键的问题是  oracle 自己没有使用rlv的前4k.lvcb是否在  rlv的头部并不重要,即使你不在头部,oracle要跳过 4k ,那也没办法. 事实上我将文件dd 进rlv去直接覆盖了 前4k 的,lv的访问本身 没问题,就是oracle无法识别这个文件. 所以我认为 lvcb应该在 vgda中肯定是有的,关键是 oracle 调用os 命令的时候 ,判别出现了偏差.\r\n\r\n你的情况到底是怎样的 ,你其实并没有证明 . oracle又提示,也许就表明没有使用那 4k 而是在 4k之后开始使用的 .\r\n\r\n证明的方式很简单,就是你把 整个  rlv dd 到文件系统上,用  dbv来检查,如果一开始就报  corrupt 那就说明前4k 有保留,如果正常那就说明前4k 已经被数据文件使用.

logzgh

biti你看看\r\nhttp://www-1.ibm.com/support/docview.wss?uid=isg1IY94343\r\n\r\n你是不是命中这个bug了？

biti_rainy

最初由 logzgh 发布\r\n[B]biti你看看\r\nhttp://www-1.ibm.com/support/docview.wss?uid=isg1IY94343\r\n\r\n你是不是命中这个bug了？ [/B]

\r\n\r\n应该就是这个bug :sweat2:

biti_rainy

最初由 logzgh 发布\r\n[B]新版本不稳定啊。^_^ [/B]

\r\n\r\n如果谁的数据库服务器是升级到这个版本……然后导致数据库无法识别文件……那不哭死啊。  数据库大又不知道这个补丁的话，处理起来麻烦死了。

Fenng

Oracle 有个 offset 工具可以检查一下\r\n\r\n现在我很头疼