文章中另外提到的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ù)過(guò)濾的。

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

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

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

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

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

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

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

· vmware這樣的虛擬化平臺(tái)目前沒(méi)有通過(guò)Oracle認(rèn)證;

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

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

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

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

huanghui