使用Oracle 11GR2 数据库Flash Cache
有1人发表了评论 | 赶紧发表评论吧 | 作者：jametong
本文翻译自Guy Harrison的blog: Using the Oracle 11GR2 database flash cache, 这是他写的关于Flash Cache系列文章的第一篇, 后面还有两篇, 我也将陆续翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.
使用Oracle 11G R2 数据库Flash Cache
Oracle最近发布了一个补丁程序,使得你可以在Oracle Enterprise Linux中使用数据库Flash Cache,即使你并没有使用Exadata存储.这个补丁的名字有点隐晦:
Oracle最近发布了一个补丁程序,使得你可以在Oracle Enterprise Linux中使用数据库Flash Cache,即使你并没有使用Exadata存储.这个补丁的名字有点隐晦:
・ 8974084:META BUG FOR FLASH CACHE 11.2PL BUGS TO BACKPORT TO 11.2.0 .1 OEL
只要安装好这个补丁,你就可以使用任何已存在的flash 设备作为数据库的Flash Cache.下面是我在一个非常旧的服务器与一个非常便宜的usb flash设备上做的初步尝试.相对于更优质的硬件来讲, 测试结果并不具有代表性,但是我认为,它仍然是很有趣的.
安装与配置
如果你也像我一样想在一个USB flash设备上做试验,那么也必须先挂载这个设备.在我的机器上,我创建了一个目录"/mnt/usbflash",接着在/etc/fstab文件新增了一个如下的条目:
如果你也像我一样想在一个USB flash设备上做试验,那么也必须先挂载这个设备.在我的机器上,我创建了一个目录"/mnt/usbflash",接着在/etc/fstab文件新增了一个如下的条目:
/dev/sda1 /mnt/usbflash vfat noauto,users,rw,umask=0 0 0
在你的系统中,你可能需要将"/dev/sda1″改成其他的设备,这依赖于你如何配置磁盘.然后就可以通过输入"mount /dev/sda1″来挂载这个闪存盘(flash drive).
一旦挂载完毕,就可以通过设置系统书db_flash_cache_files与db_flash_cache_size来配置flash cache了. 如下是我的相关设置:
一旦挂载完毕,就可以通过设置系统书db_flash_cache_files与db_flash_cache_size来配置flash cache了. 如下是我的相关设置:
注意, 参数DB_FLASH_CACHE_FILE的值必须是一个存储在闪存盘上的文件,而不是这个闪存盘的挂载点本身.
一旦这些参数设置完毕,flash cache就会被激活,并且将充当buffer cache的二级缓存. 当从主缓存移出一个block的时候,它将被移到flash cache中,从而在再次读回这个block的时候不需要产生一次访问磁盘的物理读.
监控
一旦这些参数设置完毕,flash cache就会被激活,并且将充当buffer cache的二级缓存. 当从主缓存移出一个block的时候,它将被移到flash cache中,从而在再次读回这个block的时候不需要产生一次访问磁盘的物理读.
监控
有多种方法来检查是否使用到了flash cache. 首先,v$sysstat视图包含多个新的统计项来展示有多少数据块被添加到flash cache中,以及在flash cache中命中的次数(从这儿下载脚本):
还有一些新的等待事件来显示往flash cache中添加条目以及从flash cache中读取条目引起的等待. 从下图可以看到,'db flash'等待的次数超过' db file sequential read'的等待次数,虽然从flash cache读取的速度远远快于从磁盘的读取速度(但是从flash cache读取的次数也远远超过从磁盘读取的次数):
那么,请记住,我不能不为这个测试选择了最糟糕的硬件-一个老旧的俩CPU intel主机以及一个便宜的拇指磁盘.即使这样,还是发现了引人注目的问题-相对于整个处理时间来讲写开销非常严重.虽然相对于db file sequential reads来讲从flash cache中读取的速度可以节约很多时间,维护flash cache的开销也可能会非常高,因为大部分基于闪存的SSD(Solid State Disk)都有相对严重的写瓶颈.
所有基于闪存的固态盘(SSD,Solid State Disk)都有写性能方面的问题.然而,便宜的MLC(Multi Level Cell)闪存的写速度差不多相当于更加昂贵的SLC(Single Level Cell)的1/3.在闪存盘比较新时,空闲空间可以以单页(一般为4k)递增的方式来写.然而,当闪存盘越来越旧时,写操作需要先清除一个完整的128页的块,从而就会慢很多了.我的便宜的USB盘是一个旧盘,并且是MLC的,所以它的写性能是非常差的.但是,即使是最好的基于闪存的SSD,它的写速度也比读速度要慢很多,因此,有些时候使用闪存盘反而会导致数据库运行的更慢. 因此监控就显得非常重要了.
下面是几个与此相关的其他v$systat统计项:
所有基于闪存的固态盘(SSD,Solid State Disk)都有写性能方面的问题.然而,便宜的MLC(Multi Level Cell)闪存的写速度差不多相当于更加昂贵的SLC(Single Level Cell)的1/3.在闪存盘比较新时,空闲空间可以以单页(一般为4k)递增的方式来写.然而,当闪存盘越来越旧时,写操作需要先清除一个完整的128页的块,从而就会慢很多了.我的便宜的USB盘是一个旧盘,并且是MLC的,所以它的写性能是非常差的.但是,即使是最好的基于闪存的SSD,它的写速度也比读速度要慢很多,因此,有些时候使用闪存盘反而会导致数据库运行的更慢. 因此监控就显得非常重要了.
下面是几个与此相关的其他v$systat统计项:
可以通过查看V$BH视图来查看cache中的内容. 保存在flash cache中的buffer有诸如'flashcur'一类的状态,使得我们可以统计每个对象有多少buffer在主缓存中,有多少buffer在flash cache中(脚本来自这里):
在这个例子中,TXN_DATA表有85,833个块在flash cache中,有28,753个块在主buffer cache中.
结论
结论
能让flash cache工作,我非常高兴,特别是在如此蹩脚的硬件上. 很高兴Oracle对Non-Exadata硬件开放这项技术.
我将很快在搭建一套更好的环境,从而我可以理解它在相当好的商业SSD闪存盘上是如何工作的.
我坚信, 市场需要的理想的存储体系应该包含至少两层―一层来解决海量存储,另一层解决快速检索. 但是,我们也应该保持谨慎,因为flash的写弊端可能导致我们在RAID5上遇到的类似的性能问题.
我将很快在搭建一套更好的环境,从而我可以理解它在相当好的商业SSD闪存盘上是如何工作的.
我坚信, 市场需要的理想的存储体系应该包含至少两层―一层来解决海量存储,另一层解决快速检索. 但是,我们也应该保持谨慎,因为flash的写弊端可能导致我们在RAID5上遇到的类似的性能问题.
沒有留言:
張貼留言