自从Oracle和HP推出Exadata之后,我就很关注这个产品,之前也写了一篇Oracle database machine介绍它。去年,Oracle和SUN合并后,推出了Oracle Exadata V2,相比较上一代产品有几个变化:第一,使用SUN的硬件;第二,宣称支持OLTP应用;第三,Oracle 11g R2提供了更多的新特性。
Exadata Smart Flash Cache
Exadata V2整体架构并没有太多改变,换用了SUN的硬件,除了采用intel最新的nehalem CPU以外,每台storage cell更是配置了384GB的flash,这也是为什么V2可以支持OLTP应用的关键。
Flash cache完全是自动管理,Oracle会根据数据的访问情况,决定哪些数据放在flash cache中。所有的数据都是先被写到普通磁盘上,再根据访问情况读入flash cache的,所以如果flash card发生故障,数据不会丢失。当然,Oracle提供了方式,可以让用户手动将表或者索引pin在flash cache中。
在自动管理的方式之外,Oracle还允许用户人工创建flash disks,和普通磁盘一样,这些flash disks通过ASM输出给数据库使用,用户可以把一些访问非常频繁的数据文件放在上面。这些flash disks不仅仅是cache了,所以ASM会在cell和cell之间做镜像。如果某块卡发生故障,那么整个storage cell上的flash disks会offline,保证数据不会丢失。
Smart scan
Smart scan是Exadata最重要的一个功能,它的作用就是把SQL放在每个cell上去运行,然后每个cell只返回符合条件的数据给数据库,这样就极大的降低了数据库服务器的负载和网络流量,并充分利用了cell的计算资源和IO资源。
传统方式:所有的数据都需要返回给数据库服务器,网络带宽要求高,所有的计算在数据库服务器上完成。
Smart scan:只返回符合条件的数据,减少网络带宽,并充分利用了cell上的计算和IO资源。
这里有一点要注意,在使用smart scan时,每个cell返回给DB server的是结果集,而不再是传统的block,DB server完成结果集的处理,并返回给客户端。
Smart scan如何处理join?是我一直想要搞清楚的问题。事实上,smart scan只能处理join filtering,而真正join的工作必须在DB Server上完成,而且smart scan仅适合于处理DSS环境的复杂join,对于OLTP类型的简单join,smart scan并不能发挥其优势。设想下面的查询:
select e.ename,d.dname from emp e, dept d where and e.ename=’Jacky’ and e.deptno=d.deptno;
假设采用nested loops join,smart scan只能完成e.ename=’Jacky’这个条件的过滤,然后将符合条件的emp表的数据返回到DB server,然后由DB Server完成join的工作,逐条查询dept表(e.deptno=d.deptno)的数据。所以smart scan并不适合nested loop join(我认为smart scan只有在适合的条件下才会启用),只有DSS环境的大数据量复杂join才会发挥出优势。而且smart scan只能完成filtering的工作,而不能真正完成join的工作,这个与Greenplum数据库是不同的(有兴趣可以看我的文章,Greenplum技术浅析)。设想下面的查询(emp和dept都是大表):
select e.ename,d.dname from emp e, dept d where e.deptno=d.deptno;