Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2519136
  • 博文数量: 323
  • 博客积分: 10211
  • 博客等级: 上将
  • 技术积分: 4934
  • 用 户 组: 普通用户
  • 注册时间: 2006-08-27 14:56
文章分类

全部博文(323)

文章存档

2012年(5)

2011年(3)

2010年(6)

2009年(140)

2008年(169)

分类: Oracle

2009-01-01 14:31:11

  在lu论坛看到对这个问题的讨论,觉得AIX工程师和ORACLE工程师都应该引起注意。在SCARABLE VG里不会存在这个问题,但在normal vg里就需要注意了,特别是normal vg转scarable vg的时候。还有oracle在运行的时候,一个block跨越了lun/disk的时候。最后在使用big vg遭遇bug的时候。以下是选自PINER blog上的文章,他对此做了详细的描述。
 
原文地址:
 

在Oracle 9iR2以前,在IBM AIX上使用lv raw(裸设备)作为Oracle数据文件的话,lv头部是存在一个4k的lv管理区的。正因为这个4k的lv头部,会导致8k以及8k以上的Oracle block(Oracle块)在使用这样的lv的时候,或者是lv strip(lv条带)的时候,可能会导致一个block跨在2个pv上面。最严重的后果就是,如果os写了一个pv上的半个块之后,来不及写下一个pv上的半个块(如果是在同一个pv则可以保证一个block同时被更新),这个时候系统崩溃或者掉电,将导致这个块前后不一致,也就是块corrupted:ORA-01578, 00000, “ORACLE data block corrupted (file # %s, block # %s)”。

为了改变这个现状,AIX在Oracle 9iR2以后,引进了一种新的LV类型,也就是“Z”类型LV,这种类型的LV通过lslv lv_name或者lslv -L lv_name可以看到它的类型为:DS_LVZ

#lslv -L lv_test_2g_001

...... DEVICESUBTYPE : DS_LVZ

或者,Oracle的dbfsize也可以检查

$dbfsize /dev/rlv_test_2g_001

Database file: /dev/rlv_test_2g_001 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类型说明。

这样的LV需要特定的VG才能支持,因为它没有lv的头部了,那么,lv肯定就要靠VGDA来管理了。

这样的LV就是Big VG或者是5.3开始引进的Scalable-type VG,加上原始的VG,那么,在最新的5.3系统中,将有3中VG类型的差别,而5.2则只有big VG与普通VG。

通过mkvg -B可以创建big vg,通过mkvg -S可以创建Scalable-type VG,至于这两个VG类型上的差别,可以查看man mkvg,我在这里只说明它们在对“Z”类型LV,也就是DS_LVZ类型(没有4k头部的lv)以及普通DS_LV类型的lv上的差别。

1、对于Big VG,是唯一允许同时存在这两种LV类型的VG,如果我们指定-T O(注意,这里是大写的字母O),则创建DS_LVZ类型的LV,否则,创建普通类型的LV。如

#mklv -y’lv_test’ -t’raw’ -T O testvg 8 hdisk3

2、对于普通的VG,不管你使用什么命令创建lv,都是普通的DS_LV类型的LV

3、对于Scalable-type VG类型的VG,不管你使用什么方式的命令创建lv,都是扩展的DS_LVZ类型的LV

到这里,AIX应当只终于有一个彻底的解决方案了,根据你的实际情况,你可以选择不同的VG来管理你的LV。

问题似乎说的很清楚了,解决方案也很完美了,那么,结束了吗?没有,因为有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

的这个版本,包括以后,出现了一个bug,正确的OS版本应当是5305或者是5209?(5.2的小版本我不太清楚是哪一个,只能靠检查文件集版本了)以后,big vg出现了一个bug,就是使用-T O,创建成功的DS_LVZ类型的LV,在经过chlv或者是其它lvm命令,如varyoff/varyon之后,这个标志会消失。这个情况是比较可怕的,如你采用新创建的lv创建了数据文件,但是,后来,因为HA切换或者其它原因varyoff/varyon了这个VG,甚至exportvg/importvg了这个VG,新的LV在数据库看来,不是DS_LVZ类型的LV,数据库将试图跳过4k的偏移,但是偏移其实是不存在的。具体解决方案就是,请使用scalable类型的VG或者是打以上的补丁:

Problem is caused by defect IY94343 in AIX Operating System.

Solution is to apply fix:

其实,除了AIX自己的LVM,veritas的LVM管理在AIX上也有同样的问题,为了解决这个问题,veritas LVM推出了一种叫DS_VMZ类型的LV for aix。为了支持这个类型,Oracle 9205或者10.1以后,有一个对应的patch需要注意:patch 3712203:

3712203 BACKPORT THE ZSUBTYPE PATCH FOR VERITAS DEVICE FOR 9.2.0.X AND 10.1.0.X.

相关讨论,可以参考

 

--当数据库的数据文件建在AIX normal vg里的lv上,由于normal vg的限制我们需要将normal vg改成scarable vg。改完后oracle数据库就起不来了。因为:在normal vg里的lv,oracle会跳过4K然后读取数据文件的数据。改为scarable vg后,oracle直接从lv头部去读,这样当然是读不到的。因为数据并没有往前移。我们可以用以下命令把lv的整个数据向前移动4K:dd if=/dev/lvname of=/dev/lvname  seek=0 skip=1 bs=4k

 

阅读(1477) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~