AIX RAW LVM 的 4k Offset 问题.docx
- 文档编号:30711850
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:9
- 大小:33.62KB
AIX RAW LVM 的 4k Offset 问题.docx
《AIX RAW LVM 的 4k Offset 问题.docx》由会员分享,可在线阅读,更多相关《AIX RAW LVM 的 4k Offset 问题.docx(9页珍藏版)》请在冰豆网上搜索。
AIXRAWLVM的4kOffset问题
AIXRAWLVM的4kOffset问题
作者:
Fenng|可以转载,转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址:
这可能是Oracle在AIX平台上最重要的一个潜在问题。
一般情况下,AIX的逻辑卷前4k用于存储controlblock(LVCB),在Oracle9iR2之前,Oracle软件自动跳过这4k而不用。
这带来了一个潜在的问题,当Oracle的db_block_size大于4k的时候,一个Block可能跨在两个PV/LUN/磁盘上(如果做了条带化,那么将总有数据块跨在两个条带上--其实也还是将跨在不同的PV/LUN/磁盘上。
这样当系统崩溃的时候,很有可能造成大量的IO不完整,一个PV上IO写入,另一边可能未完成,启动Oracle的时候将会看到ORA-1578错误,这几乎是致命的。
为了解决这个问题,AIX推出了BigVolumeGroups作为应对。
建立BigVG后,创建LV的时候可以通过-TO的参数强制征用LV的前4K空间,LVCB的信息保存在VGDA(volumegroupdescribearea)里面。
前4k空间被使用的LV有了一个新的设备子类型(devsubtype)标记:
DS_LVZ,通过lslv可以看到。
(Oracle也在9.2.0.3之后自动识别AIX的新LV类型,直接开始使用LV的前4K空间)
对于AIX的可扩展性VG,则默认创建的LV就会DS_LVZ类型,不使用-TO也是这样子。
BigVG可能只是一个过度类型。
在IBM的系统手册中可以看到:
TheIOCINFOioctloperationreturnsthedevinfostructure,asdefinedinthe/usr/include/sys/devinfo.hfile
如何知道当前裸设备创建的时候使用了-TO?
Oracle10g的文档中说$ORACLE_HOME/bin/offset工具可以做到。
可是我居然找不到这个工具。
莫非是忽悠人来着?
通过另一个工具可以看到相关信息:
$dbfsize/dev/rfoo01_pay
Databasefile:
/dev/rfoo01_pay
Databasefiletype:
rawdevicewithout4Kstartingoffset
Databasefilesize:
9208192byteblocks
要想得到完美的东西太难了,AIX在BIGVG上仍然还有很多问题,目前已知的当属这个“MKLV-TOONBIGVOLUMEGROUPSFAILSTOPUTSOMELVINFORMATION”最为严重--得不到正确的devsubtype类型,Oracle则会报告读取数据文件头错误,这个更要人命。
DBA这个工作,还真是脑袋悬在腰带上,风险莫测。
--EOF--
Updated:
offset命令工具需要安装RAC组件才可用,Oracle另外提供了一个补丁来弥补这个问题,在Patch3242957中可以找到,直接解压缩,把工具提取出来即可用。
这篇【AIXRAWLVM的4kOffset问题】来自|
del.icio.us|雅虎收藏+
ByFenngonMay7,20073:
32PM|Permalink|TrackBacks(0)|Database|Edit
ShareThis
Generator|Trampoline|外贸英才网|Vinylfence
VerticalPackagingMachine|DigitalBloodPressureMonitor
窗体顶端
窗体底端
自定义搜索
本文相关评论|Comments(27)
Fenng
的评论:
补充一下,offset工具在选用了RAC工具后才会有,也可以通过安装一个Patch来使用这个工具
May7,20074:
50PM
biti_rainy的评论:
幸亏发现了这个问题,否则如果将来存储扩容、os正好升级到AIX5.3.0.5,那就麻烦大了!
May7,20075:
05PM
David.Guo的评论:
唉,脑袋放在裤腰带上还是比较安全的
问题是不知道什么时候被厂商玩一把,
有问题就是不告诉你,忽悠你,看你咋的
May7,200710:
33PM
木匠的评论:
在这里请教一个问题
系统硬件升级,在未来流行的OracleRAC平台里面,
选AIXonP5还是HP-UXonItaniumII?
或者还有其它选择?
我们准备脱离Linux+Intelx86.
多谢.
May8,200712:
48AM
Fenng
的评论:
现在市场上看,肯定IBM强势一些,HP在走下坡路
May8,20079:
11AM
wanghai的评论:
木匠你们为什么要脱离Linux+Intelx86?
有什么问题吗?
May8,20079:
30AM
vecentli的评论:
cow!
这样的经验是无价的,谢谢分享啊!
May8,200711:
43AM
木匠的评论:
感谢Fenng的回复,我的调到澳大利亚OSS的旧同事也是这么说,首推AIX.
wanghai,
也不为啥,可能是公司盈利了,想买更好的硬件,让我选型.
另外数据库应用的吞吐量到了瓶颈.
我感觉OracleonLinux+x86还是相当稳定的.
如果处理能力够用.
May8,20071:
30PM
sclzmbie的评论:
不懂,不过觉得容错这个东西本来就不完美,关键的disk完蛋了还有什么好说的~
May8,20072:
11PM
sclzmbie的评论:
天!
这个留言系统真够可以的,第一遍贴不上,第二次就发现贴2遍了!
!
!
May8,20072:
13PM
piner的评论:
还算发现的及时的,详细情况还可以参考我这里
May8,20072:
58PM
catchtime的评论:
请教个问题,AIX下创建LV时默认blocksize为应该4K,没想明白为什么4K的偏移量就会导致oracle的某个block可能跨越PV,,如果是8K的话还可以理解。
May10,200711:
53AM
Fenng
的评论:
AIX下创建LV时默认blocksize为应该4K?
这个说法从何得来?
May10,200712:
21PM
kamus的评论:
我没太看明白,“这样当系统崩溃的时候,很有可能造成大量的IO不完整,一个PV上IO写入,另一边可能未完成”这个现象是可能存在的,但是跟“逻辑卷4K的控制块”有什么必然的联系呢?
另外,貌似目前为止我个人还没有因为这个4K而发现什么问题。
May12,20076:
03PM
Fenng
的评论:
亏你还是Oracle的,:
0
这个问题,Oracle专门有说明文档的啊
May13,200712:
55PM
老农的评论:
如果不做strip,就没有所说的这个问题,只有做了stip,才会有可能有
如果做了strip,那stripsize多大是看你的选择,一般是从4k到128k。
在这种情况下,有可能会出现这样的情况:
因为缺省让出的4k的offset,有的db_block不全在一个strip里,部分被分到了下一个strip里,散乱到其他LUN/PV上,出现潜在的麻烦。
如果offset正好是stripsize的大小或倍数,那这种问题也没有了,所以,也怪ORACLE设offset太小气了,如果弄个1M,那这事都没有。
我以前搞INFORMIX,习惯的offset就是5M。
很多人说这是OS的BUG,其实不然。
如果说BIGVG里的LV的识别出现误判,那的确属于OS的BUG。
但归根结底,是属于ORACLE的offset没选择好而导致,属于ORACLE没能考虑到LV的情况合理规划空间的使用,如果ORACLE的offset选择合适了,哪来这个问题呢?
应该是应用去适应OS,而不是OS去适应应用。
ORACLE如果认真,是完全能避免这个问题的。
当然,OS做调整,方便应用,那当然更好。
比方说,ORACLE没有OS/400的版本,那是OS/400的问题还是ORACLE的问题啊?
May14,20072:
47AM
老农的评论:
当然,最简单的还是就用ScalableVG
May14,20072:
49AM
老农的评论:
不好意思,我上面说的有缺陷,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,一个oracleblock大小的倍数就可以
#对,这是更准确
4、ScalableVG不是每个AIX版本都有的,5.2就没有
#没错。
所以我强烈建议用AIX5.3,它已经出来3年了。
May14,200712:
30PM
老农的评论:
不好意思,我上面说的有缺陷,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,一个oracleblock大小的倍数就可以
#对,这是更准确
4、ScalableVG不是每个AIX版本都有的,5.2就没有
#没错。
所以我强烈建议用AIX5.3,它已经出来3年了。
May14,200712:
34PM
Fenng
的评论:
呵呵,我这个Blog留言系统不太好
至于IBMBigVG与ScalableVG的稳定性,其实也不好说。
按理说,BigVG出来的时间更长,但是这次一样遇到了这么严重的Bug:
iy94343
lvcb只用512,我是知道的,但是操作系统的分配单位就是4K,一般来说,Oracle是不会直接去抢这个4K剩余的空间吧
至于Oracle识别不同的LV类型,这的确是Oracle的设计问题
May14,20071:
35PM
Fenng
的评论:
呵呵,我这个Blog留言系统不太好
至于IBMBigVG与ScalableVG的稳定性,其实也不好说。
按理说,BigVG出来的时间更长,但是这次一样遇到了这么严重的Bug:
iy94343
lvcb只用512,我是知道的,但是操作系统的分配单位就是4K,一般来说,Oracle是不会直接去抢这个4K剩余的空间吧
至于Oracle识别不同的LV类型,这的确是Oracle的设计问题
May14,20071:
38PM
老农的评论:
BigVG的推出,本意并不是去掉在LV头部的LVCB,而是支持更大的VG而已,把LVCB不放在LV上只是一个不常用的option,所以有这个BUG我觉得不难理解。
而scalableVG则是彻底考虑到LVCB的问题了,所以应该要好的多。
May14,20071:
45PM
Fenng
的评论:
BigVG就是为了解决在LV头部的LVCB的问题的
IBM某个fix里面应该描述了这个解决方案。
可扩展的VG倒是应该使用的
May14,20072:
02PM
Fenng
的评论:
BigVG就是为了解决在LV头部的LVCB的问题的
IBM某个fix里面应该描述了这个解决方案。
可扩展的VG倒是应该使用的
May14,20072:
07PM
老农的评论:
BigVG的推出,本意并不是去掉在LV头部的LVCB,而是支持更大的VG而已,把LVCB不放在LV上只是一个不常用的option,所以有这个BUG我觉得不难理解。
而scalableVG则是彻底考虑到LVCB的问题了,所以应该要好的多。
May14,20072:
15PM
老农的评论:
BIGVG如果是为了解决LVCB在LV上的问题的话,建LV的时候就不应该再带选项,至少smit里就应该缺省这样,但实际上没有,所以就说明了这不过是顺带而为。
May14,20072:
46PM
老农的评论:
还有些人没明白为什么会出现跨LUN/PV,我在这里举了例子,并有图示意:
May27,20075:
30AM
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- AIX RAW LVM 4k Offset 问题
![提示](https://static.bdocx.com/images/bang_tan.gif)