文章中另外提到的bloom filter的bug應(yīng)該是Bug:12637294了，但是這個(gè)bug在11.2.0.3 BP11已經(jīng)修復(fù)。

另外很有意思的是smart scan內(nèi)部也是使用Bloom Filter的算法進(jìn)行數(shù)據(jù)過濾的。

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

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

5. Storage Index每個(gè)表只能自動(dòng)維護(hù)8個(gè)列這是事實(shí)，但是這并非是什么技術(shù)上的限制， Storage Index和Netezza的Zone Maps技術(shù)原理上是不一樣的。Storage Index一個(gè)重要的概念就是只對排序字段起作用，對于無序的字段是無法用到它的， 所以Storage Index每個(gè)表超過8列對性能上沒有多少幫助，因?yàn)橐粋€(gè)表核心并且需要用于排序的字段并不多。

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

7. 目前行在Oracle DB上的SAP ERP遠(yuǎn)比運(yùn)行在DB2上的ERP要多，有興趣可以查看gartner的統(tǒng)計(jì)數(shù)據(jù)。

8. 現(xiàn)在硬盤白菜價(jià)了，單塊盤就2-3T了，誰還在意這么一點(diǎn)空間? 況且OLTP應(yīng)用數(shù)據(jù)量在1T以上的也不在少數(shù)。

9. 這一條說的是事實(shí)，但是

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

· IBM LPAR不屬于嚴(yán)格意義上的虛擬化技術(shù);

· Exadata上可以通過像IORM/instance cage/cgroups這樣的方式來實(shí)現(xiàn)資源隔離;

· 未來應(yīng)該會考慮使用Oracle自己的OVM。

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

huanghui