噜噜噜综合,又色又爽又高潮免费观看,综合无码一区二区三区四区五区,中文字幕无码人妻aaa片,四虎成人精品永久网站

本文是針對IBM系統(tǒng)架構(gòu)師王文杰先生(valen_won@hotmail.com)在其博客園的置頂博文思考EXADATA(鏈接原文地址： https://www.cnblogs.com/wenjiewang/archive/2012/10/07/2714406.html)中提到的一些關(guān)于Exadata觀點(diǎn)，從技術(shù)角度給出我個(gè)人的一些不同的見解，當(dāng)然本人水平有限，難免出現(xiàn)疏漏甚至錯(cuò)誤。

以下簡要總結(jié)一下文杰先生博文中提到關(guān)于Exadata的觀點(diǎn)：

1. 數(shù)據(jù)倉庫(Data Warehouse)類型的應(yīng)用無法充分利用smart scan的特性，尤其是對于數(shù)據(jù)倉庫中常見的星型轉(zhuǎn)換(star transformation)， Exadata無法優(yōu)化;

2. Exadata Bug眾多，某些新特性名存實(shí)亡，并舉例說明其在布隆過濾器的使用過程中遭遇到的bug。

3. Oracle數(shù)據(jù)庫Bug眾多，使用Exadata對于業(yè)務(wù)邏輯復(fù)雜，數(shù)據(jù)正確性非常敏感的金融行業(yè)存在很大的風(fēng)險(xiǎn);

4. 維護(hù)成本高，要使用Exadata，DBA需要重新學(xué)習(xí)大量的主機(jī)，存儲(chǔ)，網(wǎng)絡(luò)方面的知識(shí)，否則無法勝任一體機(jī)管理員的工作;

5. 對于動(dòng)輒單表上百個(gè)字段的數(shù)據(jù)倉庫而言，Exadata 的Storage Index形同雞肋，因?yàn)閷τ诿總�(gè)表只能自動(dòng)維護(hù)8個(gè)列，與杯水車薪無異;

6. Exadata還是RAC， RAC的share everything架構(gòu)導(dǎo)致存在大量的cache fusion爭用，與OLTP應(yīng)用格格不入。

7. RAC對ERP支持不好，導(dǎo)致很多ERP用戶不使用RAC，Exadata只提供RAC的模式。

8. Exadata磁盤容量太大，對于OLTP而言這簡直就是浪費(fèi);

9. Exadata不提供任何虛擬化技術(shù)，不能充分利用其硬件資源，而它的競爭對手確提供非常成熟的虛擬化解決方案;

10. (這年頭，要湊不齊十條出門都不好意思跟人打招呼)Exadata的價(jià)格十分昂貴，普通的用戶根本無法承受。

以下是我個(gè)人的回應(yīng)，不代表Oracle公司的官方立場。Oracle的salary還沒到我想做Oracle公司5毛的沖動(dòng)。 如果您愛看軟文，那么您可以請移步Loveunix和AIXchina，因?yàn)槟抢锉容^多。很多技術(shù)細(xì)節(jié)三言兩語很難解釋清楚的，限于篇幅，這里力求簡介或者一筆帶過。

1. 實(shí)際上smart scan可謂是Exadata所有技術(shù)的核心，離開了smart scan，Exadata就沒有了靈魂。而Exadata的smart scan的條件過于苛刻，一直以來備受競爭對手的詬病，這個(gè)也是事實(shí)。 但是文中提到的 “如果我們的報(bào)表如果不是走FULL TABLE SCAN，則無法利用到這一特性。復(fù)雜的查詢，諸如Joins, sorts, group-bys, aggregation都很可能無法利用到智能掃描。” 這一說法是不準(zhǔn)確的。我這里不厭其煩的列舉一下目前smart scan的條件：(雖然這是一個(gè)錯(cuò)誤的“真理”)

· Full scans——Table, Partition, Materialized View, Index (FAST FULL SCAN Only)

· Direct Path Reads

· Exadata Storage

對于較復(fù)雜的排序，聚合類的操作，storage index就有它的用武之地了。至于星形轉(zhuǎn)換，作者說的恐怕也不是事實(shí)， 這篇文章和這篇文章詳細(xì)介紹了在data warehouse中, Oracle內(nèi)部是如何對星型轉(zhuǎn)換進(jìn)行優(yōu)化的一些細(xì)節(jié)。

2. 布隆過濾器是一種處理大量數(shù)據(jù)的哈希算法， 具體算法可以參考wikipedia條目 Bloom Filter， 或者參考google的吳軍先生的《數(shù)學(xué)之美》一書。當(dāng)然這里提到的bug也是不準(zhǔn)確的， 這里提到的兩個(gè)bug：9124206和bug: 8361126， 實(shí)際上是同一個(gè)bug即base bug為8361126。

文章中另外提到的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í)，但是這并非是無緣無故會(huì)出現(xiàn)的，這些bug大都是在一些極端的情況下觸發(fā)。如果應(yīng)用經(jīng)過了充分的測試，那么則很少會(huì)遇到 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ù)也并不需要額外的知識(shí)，只需要了解一些常用的infiniband/cisco交換機(jī)的操作。 Exadata上的數(shù)據(jù)庫維護(hù)與普通的RAC數(shù)據(jù)庫并沒有兩樣。唯一需要重新學(xué)習(xí)的是存儲(chǔ)端的知識(shí)， 而這一部分內(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這樣的虛擬化平臺(tái)目前沒有通過Oracle認(rèn)證;

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

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

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

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