新写的DBA日记一章中的一节-存储底层
新写的DBA日记一章中的一节 感觉有点意思，预先和大家共享一下
由于DBA日记第二部正在修订，并且元旦要交给出版社，所以近期DBA日记没有更新了，请大家原谅，元旦后交稿后我会继续写第三部，欢迎大家阅读
3月5日 存储优化
今天终于见到老李的手下了，小张和小马前几天去参加了一个培训，今天才回来上班。我早上到办公室的时候，他们两个人正在看我昨天留下的安装指导书，老李自然是在里间办公室里喝着茶看着南方都市报。
我们四个人在老李的办公室里简单的开了个小会，就开始安装了。我的安装指导书采用了大量贴图的方式，足足有50多页，小张和小马按照安装步骤一个一个的去安装，一个上午的时间，就把CRS和数据库全部安装好了，在吃饭前居然开始建库了。看样子我这三天折腾的确是是走了不少的弯路。
午饭后，老李交给我一个表空间划分的文档，我拿过来一看，好家伙，50多个表空间，将近9TB的存储容量，要想把所有表空间都建起来，估计起码要一天的时间。我问老李，存储底层是怎么划分的，因为我看到的都是虚拟的LUN，并不知道底层存储的设计，所以无法在存储上作优化。老李也说他要求厂家划分LUN的时候直接做成底层打散的方式，我们就不需要再考虑IO的负载均衡了。厂家做完后也告诉老李按照他的要求划好了LUN,我们在做VG的时候就不需要考虑负载均衡的问题了。
既然如此那还不简单，于是我们把36个200G的LUN直接分成6个VG，每个VG 1200G,然后开始创建表空间。为了测试IO的性能，我们首先单独创建了一个32G的数据文件：
mklv -y'lv_data01' -T O -w n -r n -t'raw' vg_ora_dg 128
在这里使用-T O是为了创建一个0位移的裸设备，这个参数只在BIG VG和SCABLE VG中可以使用。一般情况下，AIX的每一个逻辑卷前512字节被称为logical-volume control block (LVCB)，包含了LV的一些信息。在 Oracle 9iR2 之前，为了避免和LVCB的冲突，Oracle 软件会跳过前4k字节不用。LVCB的和Oracle跳过4K的特点带来的问题，如果一个VG中包含多个PV，PV做了条带化（stripe），创建的LV跨在不同的PV上，这样会导致下面的问题，例如：如果stripe是 32K，db_block是8K，如果没有offset，则4个db_block就全在一个stripe里了，不会跨PV。而有了4K的offset，则 肯定第四个db_block就跨stripe了，也就成了一个Oracle DB block跨在多个LUN/PV上了。跨多个PV的db_block会对读写性能造成不良影响。做了条块化的LV（mklv –S），这种一个db_block跨在多个PV的情况发生的比例就会更高，也就越影响IO的效率。 最要命的是，这种情形使��一个DB block的读写变成了操作系统的多个读写，产生了一种我们称之为“split write”的情形。当系统崩溃的时候，很有可能造成大量的 IO 不完整（如果OS写了一个PV上的半block之后，来不及写下一个PV上的半个block，如果是在同一个PV则可以保证一个block同时被更新），启动 Oracle 的时候将会看到 ORA-01578：“ORACLE data block corrupted (file # %s, block # %s)” 错误，大量的corrupted block对于数据可能是致命的。
测试结果让人大失所望，居然创建一个32G的数据文件需要3分多钟，而并发创建两个表空间的时候，每个32G的文件的平均创建时间居然超过50分钟，对于日立的高端存储来说，这个性能显然是有问题的。老李说这是日立的高端存储，性能不会比HP OEM的产品XP24000差，而且配备了32G的CACHE，而且整个存储包含64块硬盘，除去4块HOT SPARE盘，也同时又60块盘可以同时读写，按理说性能应该还算不错的。难道是条带化出了问题？于是我问小马底层存储是RAID 1+0还是RAID 5，小马说是RAID 5的，因为这是一个数据仓库系统，所以最终选择了RAID 5。
如果是RAID 5，那就有问题了，RAID 5怎么可能在底层打散存储呢？一般来说考虑到RAID 5的写性能问题，不可能把60块盘做成一个RAID 组，而是会4-6块盘做一个RAID组，如果真是这样的话，底层存储上打散IO的说法就不成立了，因为每个LUN都是从RAID组里划出来的，只会使用RAID组中的几块盘，而我们随便调了几个LUN做VG，在创建LV的时候只是简单的创建了一个LV，并没有做条带处理，那样的话，可能只有同一个RAID组里面的几块硬盘被使用到。
我和小马他们谈了这个想法后，小马说到机房看看盘阵里现在有几块盘在闪烁不就知道底层存储是不是打散的了吗。我想了想也对，过去看看就行了，于是我们三个人一起跑到对面的机房里，打开了磁盘柜的门，我们看到前面板30多块亮灯的磁盘，其中只有几块是在闪烁的，看样子这回又被存储厂家忽悠了一把。
老李听到这个消息后也觉得十分愤怒，马上给厂家的那个工程师打电话确认。果然不出我们所料，从他们发过来的配置图来看
存储底层是按照每四块盘做成一个RAID 5,60块盘一共做了15组RAID 5,每组的容量是900G，剩下的4块盘作为HOT SPARE盘。而厂家工程师所说的打散IO实际上并不是说每个LUN中都包含了所有磁盘的数据，而是在划分LUN的时候，采用了轮流的方式：
也就是说在划LUN的时候，他们是把15个RAID组划分了两个大组，分别用于老李他们的两个应用，其中ETL应用划分了9个RAID 组，ODS应用划分了6个RAID 组。在划LUN的时候，每个LUN位200G，HDISK2从1-1 RAID组中划分，HDISK3从2-1 RAID组中划分，一直到RAID 10，这一组LUN分别来自不同的RAID组，从HDISK11-HDISK19重复这种划分方法。这就是他们所说的IO负载均衡，其实这种划分方法，要便于在创建VG的时候选择磁盘，并没有实现底���的打散或者IO负载均衡。
了解了LUN的划分模式后，再来确定优化方案就十分容易了。我们可以以9个LUN为一组创建VG，每个VG都包含所有的RAID组中划出的LUN，这样ETL系统创建4个VG，其中3个每个VG 1800G，还有一个VG 900G。在创建逻辑卷的时候，可以使用
mklv -y'lv_data01' -T O -w n -r n -t'raw' '-S64K' vg_ora_dg 4 hdisk2 hdisk3 hdisk4 hdisk5 hdisk6 hdisk7 hdisk8 hdisk9
因为这个系统是OLAP系统，因此我们选择了比较大的STRIPE SIZE，这样lv_data01的数据就分散在9个RAID组中了。创建完逻辑卷后，我们再次测试了一下，发现创建一个32G的数据文件的时间由原来的183秒减少到107秒了，性能差不多提升了三分之一。虽然为了这件事差不多折腾了2个多小时，不过能够有这么大的性能提升，也值得了。老李看到这个结果也是连呼庆幸，如果不是今天我们较了一回真，系统上线后，麻烦就大了。
解决了IO性能的问题，大家都比较兴奋，小张建议大家今晚加加班，干脆搞完了算了，周末就没必要加班了。老李一听小张的建议也十分赞同，他看了看表说：“现在已经4点多了，你们把建表空间的脚本分成3个并发跑，等会我们出去吃个饭，吃到9点左右回来，估计也就差不多了。”
我算了算，5个小时差不多可以完成了。于是我们马上写了5个shell脚本，用nohup命令在后台启动了。现在的时间是4点30分，哪怕再慢，晚上10点也应该能搞完了，这样我还能赶上11点30的末班车回深圳，出来一周了，还真挺想家的。
脚本开始跑之后，我们三个就一起在老李的办公室里喝茶，老李特意拿出了上好的冻顶乌龙，给我们泡起茶来。大家喝着茶，也顺便骂了一阵厂商的工程师不负责任。看看时间已经是5点30了。下班时间一到，老李就开着车，领着我们3个人出门了。
老李不愧是老广州，每次找的餐馆都是又便宜又好吃，还特别有特色，这回吃的主菜是烧鹅，说实在的在深圳也经常吃烧鹅，不过并没有感觉这道广东名菜有什么特色，今天品尝了老李推荐的这家馆子，才真正体会到广东烧鹅的真谛。大家吃的很尽兴，小张和小马的酒量都比我强，我们几个喝了一箱啤酒，老李虽然开车，也忍不住喝了2杯。
回到办公室的时候，近9个TB的表空间都已经创建完了，总归耗时不到4个小时，这比我预期的还要快了近2个小时。看看时间已经快10点钟了，我急忙填写了工作报告，让老李签字。老李看了看我的报告上只写了5天半，于是又在上面把周六和周日也填上了，并把5.5天的数字抹掉，重新写了一个9.5人天，然后签上了自己的名字。
我收起工作报告，对老李说：“谢谢了”。
老李说：“应该谢你啊，如果不是你，今天的这个问题没有发现，我们就惨了。”
由于DBA日记第二部正在修订，并且元旦要交给出版社，所以近期DBA日记没有更新了，请大家原谅，元旦后交稿后我会继续写第三部，欢迎大家阅读
3月5日 存储优化
今天终于见到老李的手下了，小张和小马前几天去参加了一个培训，今天才回来上班。我早上到办公室的时候，他们两个人正在看我昨天留下的安装指导书，老李自然是在里间办公室里喝着茶看着南方都市报。
我们四个人在老李的办公室里简单的开了个小会，就开始安装了。我的安装指导书采用了大量贴图的方式，足足有50多页，小张和小马按照安装步骤一个一个的去安装，一个上午的时间，就把CRS和数据库全部安装好了，在吃饭前居然开始建库了。看样子我这三天折腾的确是是走了不少的弯路。
午饭后，老李交给我一个表空间划分的文档，我拿过来一看，好家伙，50多个表空间，将近9TB的存储容量，要想把所有表空间都建起来，估计起码要一天的时间。我问老李，存储底层是怎么划分的，因为我看到的都是虚拟的LUN，并不知道底层存储的设计，所以无法在存储上作优化。老李也说他要求厂家划分LUN的时候直接做成底层打散的方式，我们就不需要再考虑IO的负载均衡了。厂家做完后也告诉老李按照他的要求划好了LUN,我们在做VG的时候就不需要考虑负载均衡的问题了。
既然如此那还不简单，于是我们把36个200G的LUN直接分成6个VG，每个VG 1200G,然后开始创建表空间。为了测试IO的性能，我们首先单独创建了一个32G的数据文件：
mklv -y'lv_data01' -T O -w n -r n -t'raw' vg_ora_dg 128
在这里使用-T O是为了创建一个0位移的裸设备，这个参数只在BIG VG和SCABLE VG中可以使用。一般情况下，AIX的每一个逻辑卷前512字节被称为logical-volume control block (LVCB)，包含了LV的一些信息。在 Oracle 9iR2 之前，为了避免和LVCB的冲突，Oracle 软件会跳过前4k字节不用。LVCB的和Oracle跳过4K的特点带来的问题，如果一个VG中包含多个PV，PV做了条带化（stripe），创建的LV跨在不同的PV上，这样会导致下面的问题，例如：如果stripe是 32K，db_block是8K，如果没有offset，则4个db_block就全在一个stripe里了，不会跨PV。而有了4K的offset，则 肯定第四个db_block就跨stripe了，也就成了一个Oracle DB block跨在多个LUN/PV上了。跨多个PV的db_block会对读写性能造成不良影响。做了条块化的LV（mklv –S），这种一个db_block跨在多个PV的情况发生的比例就会更高，也就越影响IO的效率。 最要命的是，这种情形使��一个DB block的读写变成了操作系统的多个读写，产生了一种我们称之为“split write”的情形。当系统崩溃的时候，很有可能造成大量的 IO 不完整（如果OS写了一个PV上的半block之后，来不及写下一个PV上的半个block，如果是在同一个PV则可以保证一个block同时被更新），启动 Oracle 的时候将会看到 ORA-01578：“ORACLE data block corrupted (file # %s, block # %s)” 错误，大量的corrupted block对于数据可能是致命的。
测试结果让人大失所望，居然创建一个32G的数据文件需要3分多钟，而并发创建两个表空间的时候，每个32G的文件的平均创建时间居然超过50分钟，对于日立的高端存储来说，这个性能显然是有问题的。老李说这是日立的高端存储，性能不会比HP OEM的产品XP24000差，而且配备了32G的CACHE，而且整个存储包含64块硬盘，除去4块HOT SPARE盘，也同时又60块盘可以同时读写，按理说性能应该还算不错的。难道是条带化出了问题？于是我问小马底层存储是RAID 1+0还是RAID 5，小马说是RAID 5的，因为这是一个数据仓库系统，所以最终选择了RAID 5。
如果是RAID 5，那就有问题了，RAID 5怎么可能在底层打散存储呢？一般来说考虑到RAID 5的写性能问题，不可能把60块盘做成一个RAID 组，而是会4-6块盘做一个RAID组，如果真是这样的话，底层存储上打散IO的说法就不成立了，因为每个LUN都是从RAID组里划出来的，只会使用RAID组中的几块盘，而我们随便调了几个LUN做VG，在创建LV的时候只是简单的创建了一个LV，并没有做条带处理，那样的话，可能只有同一个RAID组里面的几块硬盘被使用到。
我和小马他们谈了这个想法后，小马说到机房看看盘阵里现在有几块盘在闪烁不就知道底层存储是不是打散的了吗。我想了想也对，过去看看就行了，于是我们三个人一起跑到对面的机房里，打开了磁盘柜的门，我们看到前面板30多块亮灯的磁盘，其中只有几块是在闪烁的，看样子这回又被存储厂家忽悠了一把。
老李听到这个消息后也觉得十分愤怒，马上给厂家的那个工程师打电话确认。果然不出我们所料，从他们发过来的配置图来看
存储底层是按照每四块盘做成一个RAID 5,60块盘一共做了15组RAID 5,每组的容量是900G，剩下的4块盘作为HOT SPARE盘。而厂家工程师所说的打散IO实际上并不是说每个LUN中都包含了所有磁盘的数据，而是在划分LUN的时候，采用了轮流的方式：
也就是说在划LUN的时候，他们是把15个RAID组划分了两个大组，分别用于老李他们的两个应用，其中ETL应用划分了9个RAID 组，ODS应用划分了6个RAID 组。在划LUN的时候，每个LUN位200G，HDISK2从1-1 RAID组中划分，HDISK3从2-1 RAID组中划分，一直到RAID 10，这一组LUN分别来自不同的RAID组，从HDISK11-HDISK19重复这种划分方法。这就是他们所说的IO负载均衡，其实这种划分方法，要便于在创建VG的时候选择磁盘，并没有实现底���的打散或者IO负载均衡。
了解了LUN的划分模式后，再来确定优化方案就十分容易了。我们可以以9个LUN为一组创建VG，每个VG都包含所有的RAID组中划出的LUN，这样ETL系统创建4个VG，其中3个每个VG 1800G，还有一个VG 900G。在创建逻辑卷的时候，可以使用
mklv -y'lv_data01' -T O -w n -r n -t'raw' '-S64K' vg_ora_dg 4 hdisk2 hdisk3 hdisk4 hdisk5 hdisk6 hdisk7 hdisk8 hdisk9
因为这个系统是OLAP系统，因此我们选择了比较大的STRIPE SIZE，这样lv_data01的数据就分散在9个RAID组中了。创建完逻辑卷后，我们再次测试了一下，发现创建一个32G的数据文件的时间由原来的183秒减少到107秒了，性能差不多提升了三分之一。虽然为了这件事差不多折腾了2个多小时，不过能够有这么大的性能提升，也值得了。老李看到这个结果也是连呼庆幸，如果不是今天我们较了一回真，系统上线后，麻烦就大了。
解决了IO性能的问题，大家都比较兴奋，小张建议大家今晚加加班，干脆搞完了算了，周末就没必要加班了。老李一听小张的建议也十分赞同，他看了看表说：“现在已经4点多了，你们把建表空间的脚本分成3个并发跑，等会我们出去吃个饭，吃到9点左右回来，估计也就差不多了。”
我算了算，5个小时差不多可以完成了。于是我们马上写了5个shell脚本，用nohup命令在后台启动了。现在的时间是4点30分，哪怕再慢，晚上10点也应该能搞完了，这样我还能赶上11点30的末班车回深圳，出来一周了，还真挺想家的。
脚本开始跑之后，我们三个就一起在老李的办公室里喝茶，老李特意拿出了上好的冻顶乌龙，给我们泡起茶来。大家喝着茶，也顺便骂了一阵厂商的工程师不负责任。看看时间已经是5点30了。下班时间一到，老李就开着车，领着我们3个人出门了。
老李不愧是老广州，每次找的餐馆都是又便宜又好吃，还特别有特色，这回吃的主菜是烧鹅，说实在的在深圳也经常吃烧鹅，不过并没有感觉这道广东名菜有什么特色，今天品尝了老李推荐的这家馆子，才真正体会到广东烧鹅的真谛。大家吃的很尽兴，小张和小马的酒量都比我强，我们几个喝了一箱啤酒，老李虽然开车，也忍不住喝了2杯。
回到办公室的时候，近9个TB的表空间都已经创建完了，总归耗时不到4个小时，这比我预期的还要快了近2个小时。看看时间已经快10点钟了，我急忙填写了工作报告，让老李签字。老李看了看我的报告上只写了5天半，于是又在上面把周六和周日也填上了，并把5.5天的数字抹掉，重新写了一个9.5人天，然后签上了自己的名字。
我收起工作报告，对老李说：“谢谢了”。
老李说：“应该谢你啊，如果不是你，今天的这个问题没有发现，我们就惨了。”
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15690854/viewspace-626116/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15690854/viewspace-626116/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
