- Full scans——Table, Partition, Materialized View, Index (FAST FULL SCAN Only)
- Direct Path Reads
- Exadata Storage
- vmware这样的虚拟化平台目前没有通过Oracle认证；
- IBM LPAR不属于严格意义上的虚拟化技术；
- Exadata上可以通过像IORM/instance cage/cgroups这样的方式来实现资源隔离；
- 未来应该会考虑使用Oracle自己的OVM。
2013年11月8日
思考EXADATA我之见
M
mac
Author
7 min
Read Time
50
Views
原文地址：http://www.dbaleet.org/a_bit_thought_of_exadata_from_a_technical_point_of_view/
本文是针对IBM系统架构师王文杰先生（valen_won@hotmail.com）在其博客园的置顶博文思考EXADATA（链接原文地址： http://www.cnblogs.com/wenjiewang/archive/2012/10/07/2714406.html）中提到的一些关于Exadata观点，从技术角度给出我个人的一些不同的见解，当然本人水平有限，难免出现疏漏甚至错误，请诸位读者不吝赐教，同时也欢迎王文杰先生和广大读者提出不同的看法。您可以在Maclean Liu的qq群（23549328）中与我一起探讨与Oracle Exadata有关的技术。
以下简要总结一下文杰先生博文中提到关于Exadata的观点：
1. 数据仓库（Data Warehouse）类型的应用无法充分利用smart scan的特性，尤其是对于数据仓库中常见的星型转换（star transformation）， Exadata无法优化；
2. Exadata Bug众多，某些新特性名存实亡，并举例说明其在布隆过滤器的使用过程中遭遇到的bug。
3. Oracle数据库Bug众多，使用Exadata对于业务逻辑复杂，数据正确性非常敏感的金融行业存在很大的风险；
4. 维护成本高，要使用Exadata，DBA需要重新学习大量的主机，存储，网络方面的知识，否则无法胜任一体机管理员的工作；
5. 对于动辄单表上百个字段的数据仓库而言，Exadata 的Storage Index形同鸡肋，因为对于每个表只能自动维护8个列，与杯水车薪无异；
6. Exadata还是RAC， RAC的share everything架构导致存在大量的cache fusion争用，与OLTP应用格格不入。
7. RAC对ERP支持不好，导致很多ERP用户不使用RAC，Exadata只提供RAC的模式。
8. Exadata磁盘容量太大，对于OLTP而言这简直就是浪费；
9. Exadata不提供任何虚拟化技术，不能充分利用其硬件资源，而它的竞争对手确提供非常成熟的虚拟化解决方案；
10. （这年头，要凑不齐十条出门都不好意思跟人打招呼）Exadata的价格十分昂贵，普通的用户根本无法承受。
以下是我个人的回应，不代表Oracle公司的官方立场。Oracle的salary还没到我想做Oracle公司5毛的冲动。 如果您爱看软文，那么您可以请移步Loveunix和AIXchina，因为那里比较多。很多技术细节三言两语很难解释清楚的，限于篇幅，这里力求简介或者一笔带过。
1. 实际上smart scan可谓是Exadata所有技术的核心，离开了smart scan，Exadata就没有了灵魂。而Exadata的smart scan的条件过于苛刻，一直以来备受竞争对手的诟病，这个也是事实。 但是文中提到的 “如果我们的报表如果不是走FULL TABLE SCAN，则无法利用到这一特性。复杂的查询，诸如Joins, sorts, group-bys, aggregation都很可能无法利用到智能扫描。” 这一说法是不准确的。我这里不厌其烦的列举一下目前smart scan的条件：（虽然这是一个错误的“真理”）