Exadata DB Server的軟件構成：
(1) 標準版數據庫
(2) ASM：卷管理和冗余(2元鏡像/3元鏡像)，所以說Exadata的存儲服務器不需要任何存儲保護的功能，僅僅是用內置盤提供容量而已。在傳統主機+存儲的方式下，不需要ASM的冗余功能
(3) RAC：DB服務器節點的橫向擴展
(4) iDB：把SQL訪問請求發送給存儲服務器，返回所要求的數據(跟傳統數據庫相比的重大區別：返回的是經過篩選的數據，而不是裸的data blocks)。當然iDB可以選擇則返回裸數據塊給SGA
Exadata Storage Server的軟件構成：
(1) cell services(cellsrv)：多線程IO服務程序
(2) management server(MS)：基于jave的，在cellsrv和cellcli之間的接口程序
(3) restart server(RS)：用于監控和重啟服務
(4) OSWatch：歷史數據收集vmstat和netstat
Exadata軟件架構：
上半部分是標準數據庫包括SGA、log writer和db writer等。
下半部分是存儲服務器：實際上只有一個cellsrv進程負責處理和DB服務器的連接;cellinit.ora是cellsrv的靜態參數;alert.log存放顯著事件;automatic diagnostic repositpry抓取和保存診斷信息;dsikmon負責監控cell和網絡的“活性”，并且把DBRMS的計劃傳播到所有存儲服務器上;每個 diakmon有一個從屬的進程，負責ASM和DB之間的通訊。
其次，分析一下Exadata的幾大技術亮點：
(1) 最最核心的技術是叫做smart scan，其它重要技術如HCC和Storage Index都必須依賴它才能運行：其核心目的是把部分工作從DB服務器offload到存儲服務器上，利用存儲服務器的CPU參與SQL的處理。 Offload之所以重要是因為在大容量數據庫DW應用中傳統的瓶頸就在于大量數據的傳輸，而且傳統數據庫必須將所有的裸數據塊裝載到數據庫里面。 Smart scan減少DB服務器的CPU占用、減少數據傳輸量(只傳輸符合條件的數據)、減少磁盤訪問的時間。所以比如在執行單純的全表掃描的時候，smart scan對于訪問速度的提升確實有所幫助。相對而言，減少DB服務器CPU占用對于性能提升所起到的幫助最小，主要的“收益”來自于DB服務器和存儲服務器之間數據傳輸量的減少。
a. Column Projection：只返回所需要的“列”，減少數據傳輸
b. Predicate Filtering,：只返回所需要的“行”，減少數據傳輸
c. Storage Indexes：每一列的數據以1MB為分割單位，建立“分區”索引，每個index entry記錄一段數據區間的最大值、最小值和它們的物理位置。它的作用不是為了返回少量的數據給DB服務器，而是為了縮短存儲服務器訪問磁盤的時間?？梢园阉醋瞿撤N形式上的“分區”機制。從這里可以看到Exadata的存儲和訪問形式，其本質是一個典型的列式數據庫。
d. Simple Joins (Bloom Filters)：把bloom filter也offload到存儲服務器上去做，減少DB服務器CPU占用。“事實上， Smart Scan 只能處理Join filtering，而真正Join的工作必須在DB Server上完成，而且Smart Scan 僅適合于處理 DSS 環境的復雜Join，對于 OLTP 類型的簡單Join，Smart Scan 并不能發揮其優勢。~ 馮大輝《深入Oracle數據庫機：Oracle Exadata五大技術亮點淺析》”
e. Function Offloading：部分內建的SQL函數可以offload到存儲服務器上做，減少DB服務器CPU占用。
f. Hybrid Columnar Compression (HCC) ：假如使用smart scan，解壓縮的工作在存儲服務器上完成。但是它的作用與smart scan減少傳輸量的初衷相反。所以需要權衡減少CPU占用和介紹傳輸量之間誰帶來的好處大，比如在cellsrv version 11.2.2.3.1中，在存儲服務器忙的時候，cell server可以返回未解壓的數據給DB服務器。
g. Encryption/Decryption：跟HCC類似，可以在cell server上運行解密的工作，在ORALCE特定版本和相應CPU的配合之下，解密可以得到硬件加速的幫助。
h. Virtual column運算可以offload
i. data model scoring function運算可以offload
j. Non-Smart Scan Offloading：與查詢無關的offload
i. Smart File Creation：數據塊初始化加速，由cell server執行數據塊的格式化
ii. RMAN Incremental Backups：提高tracking的顆粒度~每一個block，而不是一組blocks
iii. RMAN Restores：在cell server上恢復
k. 觸發smart scan的前提(以下三條都滿足)：
i. “全段落”掃描：Full Table Scan 或是 Fast Full Index Scan。TABLE ACCESS FULL= TABLE ACCESS STORAGE FULL，INDEX FAST FULL SCAN= INDEX STORAGE FAST FULL SCAN，MAT_VIEW ACCESS STORAGE FULL
ii. Direct Path Reads：并發讀取數據到program global area(PGA)。即使對于non-parallel scans ，ORACLE也可以根據情況自動的選擇Direct Path Reads。
iii. 數據保存在exadata storage上。假如ASM管理之下的存儲空間全部或者部分的不存放在cell server上，則不可以使用smart scan offloading。
(2) 第二大技術：HCC。只有當數據被用direct path loads的方式訪問的時候，可以做HCC壓縮。傳統的訪問仍然使用OLTP的壓縮方式。
a. HCC有四種壓縮方式
i. QUERY LOW(WAREHOUSE LOW)：LZO compression algorithm，壓縮率最低
ii. QUERY HIGH(WAREHOUSE HIGH)：ZLIB (gzip) compression algorithm，壓縮率中等
iii. ARCHIVE LOW：ZLIB (gzip) compression algorithm，但是壓縮率比QUERY HIGH高得多
iv. ARCHIVE HIGH：Bzip2 compression，壓縮率最高
b. CU=多個blocks(32/64KB)，CU內部數據的組織形式是按“列”而不是按“行”。優點是由于列的數據類型相同，壓縮比率會很高，其作用在于提高壓縮比例，而不是提高訪問性能，“Here’s an example of running a CPU-intensive procedure：The compression slowed down the processing enough to outweigh the gains from the reduced number of data blocks that needed to be read。From 《Expert ORACLE Exadata》”。缺點是讀取任意一行的數據都需要裝載多個block組成的CU，所以特別不適合于需要做很多單行操作的訪問。
c. 當現存記錄被更改時，數據會被轉存到新的block中，而這個block是OLTP壓縮的。所以當HCC表被頻繁update時，所占空間會像“氣球”一樣膨脹。
d. Locking的機制使得單行操作會鎖住整個CU，這對于絕大多數OLTP環境來說是致命的。
(3) 第三大技術：Storage Index，按照列字段值的索引。其設計目的是eliminate disk I/O，凡是不符合條件的區段都被跳過了。
(4) Smart Flash Cache
a. Sun recommends that the ESM modules be replaced every two years as the stored energy degrades over time (like a battery)
b. the Oracle Exadata Storage Software User’s Guide recommends powering down the storage servers before replacing one of these cards
c. 可按照任意比例劃分為ESFC和SSD盤(由ASM管理)使用，如果用于ASM管理的SSD盤，那么必須有足夠的redundancy，就降低了實際可用容量。
d. ESFC的獨特二叉讀取功能：在系統忙的時候，可以有選擇的從flash cache或者盤上讀取數據
e. Smart Scan通常讀盤而非讀取ESFC，但是可以通過開關指定Smart Scan去讀ESFC
f. 也可以用開關把特定的數據對象pin在ESFC里面
(5) Resource Management：DBRM和IORM
a. IORM only manages I/O for physical disks. I/O requests for objects in the flash cache or on flash-based grid disks are not managed by IORM.
