文章中另外提到的bloom filter的bug應該是Bug:12637294了，但是這個bug在11.2.0.3 BP11已經修復。

另外很有意思的是smart scan內部也是使用Bloom Filter的算法進行數據過濾的。

3. Oracle Bug多是眾所周知的事實， 從每次的Patchset Release/PSU的bug list可以看出，很多bug的危害也非常大。 甚至作者說的wrong result也完全是事實，但是這并非是無緣無故會出現的，這些bug大都是在一些極端的情況下觸發。如果應用經過了充分的測試，那么則很少會遇到 wrong results。 觸發wrong results bug比較常見的一些情況是并行， 復雜的表連接等操作。MOS有一篇文檔詳細的介紹了如何診斷和分析此類問題： Wrong Results Issues – Recommended Actions [ID 150895.1]。順便說一句： 越來越多金融行業客戶把Oracle數據庫當作核心了。

4. 維護成本的問題。維護沒有作者說的那么嚴重。主機是PC server，硬件沒有什么特殊之處。操作系統是Linux X86_64，很多SA/DBA都已經非常熟悉了。 網絡維護也并不需要額外的知識，只需要了解一些常用的infiniband/cisco交換機的操作。 Exadata上的數據庫維護與普通的RAC數據庫并沒有兩樣。唯一需要重新學習的是存儲端的知識， 而這一部分內容很多都能從互聯網上獲取到。(萬一實在無法勝任，Oracle公司推出了一站式白金服務，用戶可以將管理“外包”給Oracle公司，笑，請進入自動忽略廣告模式)

5. Storage Index每個表只能自動維護8個列這是事實，但是這并非是什么技術上的限制， Storage Index和Netezza的Zone Maps技術原理上是不一樣的。Storage Index一個重要的概念就是只對排序字段起作用，對于無序的字段是無法用到它的， 所以Storage Index每個表超過8列對性能上沒有多少幫助，因為一個表核心并且需要用于排序的字段并不多。

6. 這個問題實際上還是share disk和share nothing的架構之爭，老掉牙的話題了，沒有太多實際意義。

7. 目前行在Oracle DB上的SAP ERP遠比運行在DB2上的ERP要多，有興趣可以查看gartner的統計數據。

8. 現在硬盤白菜價了，單塊盤就2-3T了，誰還在意這么一點空間? 況且OLTP應用數據量在1T以上的也不在少數。

9. 這一條說的是事實，但是

· vmware這樣的虛擬化平臺目前沒有通過Oracle認證;

· IBM LPAR不屬于嚴格意義上的虛擬化技術;

· Exadata上可以通過像IORM/instance cage/cgroups這樣的方式來實現資源隔離;

· 未來應該會考慮使用Oracle自己的OVM。

10. 相比高端主機+高端存儲動輒幾百上千萬， Exadata性價比不算差吧?現在Exadata X3推出了1/8配，開始搶自家小兄弟ODA的飯碗了。。。