Oracle Exadata存儲服務器原理是什么

這篇文章主要介紹“Oracle Exadata存儲服務器原理是什么”，在日常操作中，相信很多人在Oracle Exadata存儲服務器原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Oracle Exadata存儲服務器原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Exadata Storage Server的機制

• Exadata的I/O流程

• Exadata的抗故障性

–“Storage”故障時，DB的操作

• Exadata的Patch Version

–Grid Infrastructure / DB Patch : 11.2.0.3.8 等的5行

• 第1-4位 ：PSR的Version

• 第5位 ：Database Patch for Exadata的Version

–Exadata Storage Server Software Patch : 11.2.3.1.1 等的5行

• 第1,2位 ：表示Oracle Database的 “major release number”

例）與Oracle Database 11.2.0.3 的情況的「11.2」相同

• 第3位 ：一般表示Oracle Database的 “component-specific release number”。

例）與Oracle Database 11.2.0.3 情況的「3」相同

※11.2.2.4.2對應11.2.0.3

• 第4位 ：表示Oracle Exadata Storage Server Software的 “major release number”。

• 第5位 ：表示Oracle Exadata Storage Server Software 的PSR的版本。

Exadata 架構（全景)

InfiniBand Network

• OL/Solaris中需要安裝ofed驅動

• 執行DB Server、DB Server 以及Cell Server之間的信息交換

• Cell之間無法互相交換信息?？缭蕉鄠€cell的操作安裝在DB Server中

→實現Cell的完全Scale-out

Exadata Storage Server上有哪些進程？

oracle是如何連接ASM/DB的IO/ASM層到Exadata 存儲服務器的？

• Cell Server(CELLSRV)負責與DB Server的信息交換。于是變成多線程，各個線程對磁盤與網絡執行非同步I/O

• Management Server (MS)管理制成grid disk，變更H/W、SNMPTrap、警報、email通知、缺點

• Restart Server (RS) 監視CELLSRV與MS。進程的存亡、內存使用狀況等。

通過Exadata Storage Server Software檢測HW故障的機制

• MS為Exadata的Hardware故障, 檢測Software故障

–也可以從CellCLI 查看HW故障

• Exadata 可以內部通過MS直接與ILOM通信，獲得信息

–對于ILOM中自節點的eth0 (management eth)的IP， SNMP trap會跳過。

• CellCLI是Exadata中管理各Cell的utility?？梢宰兏麰xadata Storage Server 的設定、展示警報歷史警報歷史、 展示metric、進行維護

• 與Management Server (MS)通信，管理通信Storage cell

■ 從CellCLI 觀察的情況
[root@cell01] # cellcli -e list cell detail | tail -n 3
         cellsrvStatus:          running
         msStatus:               running
         rsStatus:               running
■ 從ps 中觀察的情況
CELLSRV 進程
[root@cell01] # ps -ef | grep "bin/cellsrv " | grep -v grep
root     13085 13084  【略】　   /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/bin/cellsrv 100 5000 9 5042
RS 進程
[root@cell01] # ps -ef | grep cellrssrm | grep -v grep
root 　　11081     1 【略】     /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/bin/cellrssrm

■ 從ps 中觀察的情況 續表

• MS 進程

[root@cell01]# ps -ef | grep oc4j | grep -v grep
root   12093 12092  【略】 /usr/java/jdk1.5.0_15/bin/java -Xms256m -Xmx512m -Djava.library.path=/opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/lib -Ddisable.checkForUpdate=true -jar /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/oc4j/ms/j2ee/home/oc4j.jar -out /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/deploy/log/ms.lst -err /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/deploy/log/ms.err

• Master diskmon (diskmon) 通過CRS，與CSS同時啟動與CELLSRV通信

• Slave diskmon (dskm) 作為各個實例的一部存在與master進行通信

• 執行檢測Cell故障，分配IO fencing 、IO資源管理

Cellinit.ora

• 決定Cellinit.ora到底使用哪個網絡界面，與哪個存儲交換信息（指定InfiniBand的bondib0）

# cat /etc/oracle/cell/network-config/cellinit.ora

ipaddress1=192.168.20.81/22

• Cellip.ora存儲cell的列表 增加新的cell時可以動態加入到cellip.ora

# cat /etc/oracle/cell/network-config/cellip.ora

cell=”192.168.20.91”

cell=”192.168.20.92”

cell=”192.168.20.93”

diskmon 與 dskm

■ 從crsctl 中觀察的情況

[root@db01] # /u01/app/11.2.0.3/grid/bin/crsctl stat res -t -init  | grep -A2 diskmon

ora.diskmon

1        ONLINE  ONLINE       katana01m

■ 從ps 中觀察的情況

• diskmon 進程

[root@db01] # ps -ef | grep diskmon | grep -v grep

oracle   24362     1  0 Aug06 ?        00:01:00 /u01/app/11.2.0.3/grid/bin/diskmon.bin -d –f

• dskm 進程

[root@db01] # ps -ef | grep dskm | grep -v grep

oracle   22500     1  0 Aug09 ?        00:00:00 ora_dskm_dgprmy1

oracle   25083     1  0 Aug06 ?        00:00:00 asm_dskm_+ASM1

Cell Server認識DB Server的機制

• 各Griddisk如果在member中分配的話，被分配的Diskgroup的名字就會作為attribute登錄

• 如果有Cell的磁盤故障的情況的話，就會以這個屬性為基礎，從Diskgroup中，對對應的ASM磁盤進行drop

• DB/ASM通過Libcell（library）與CELLSRV通信

• 通信中，使用iDB 協議

• Exadata存儲通信中使用的Exadata固有的協議

• 基于RDS協議來構筑的InfiniBand上的操作

Exadata Storage Server Software的警報日志

• 追蹤文件以及警報日志在Automatic Diagnostic Repository(ADR)中配置

• alert.log (from RS and CELLSRV), ms-odl.log, ms-odl.trc, rs*trc, svtrc*.trc

• 與Oracle Database相同，可以使用ADRCI進行管理

日志文件、追蹤文件

• Cell的日志

–$ADR_BASE/diag/asm/cell/<hostname>/trace/

–存在CELLSRV、RS、MS的警報日志以及追蹤文件

• alert.log : CELLSRV與RS的警報日志

• ms-old.log / ms-old.trc : MS的警報日志與追蹤文件

• svtrc_<pid>_<tid>.trc (svtrc_13661_0.trc) : CELLSRV的追蹤文件

• rstrc_<pid>_<tid>.trc (rstrc_27528_4.trc) : RS的追蹤文件

• Diskmon的日志文件

–$ORA_CRS_HOME/log/<hostname>/diskmon/

• diskmon.log 與 diskmon.l01 ～ diskmon.l10

進程、設定文件等一覽（數據庫中）

• diskmon、dskm

• master diskmon (diskmon) 與CSS同時啟動，與CELLSRV通信。

• Slave diskmon (dskm)是各個實例的一部分，與master diskmon通信。

• cell故障以及I/Ofencing、I/O資源管理計劃

• cellip.ora

• DB服務器使用的cell的機器IP列表

• cellinit.ora

• DB服務器在與cell的通信中使用的本地IP

• CELLSRV

• CELLSRV中1個cell中1個進程（多線程）。線程對磁盤以及網絡會執行非同步IO。

• MS

• 制成/刪除Grid磁盤、變更H/W、展示、管理SNMP trap、警報、缺點。

• RS

• 監視CELLSRV與MS。RS監視進程存亡、

內存使用率等。Backup RS監視Core RS。

• CellCLI

• 執行用戶操作與構成的命令行工具

各進程的作用

通過RS進程進行的監視①

alter cell startup services all 執行時　(Backup RS的啟動)

• Core RS 進程

[root@cell01] # ps -ef | grep cellrssrm | grep -v grep

root     11081     1  【略】   /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/bin/cellrssrm

• Backup RS 進程

[root@cell01] # ps -ef | grep cellrsbkm | grep -v grep

root     11089 11087  【略】  /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/bin/cellrsbkm -rs_conf /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/deploy/config/cellrsms.state -cellsrv_conf /opt/oracle/cell11.2.3.1.1_LINUX.X64_120607/cellsrv/deploy/config/cellrsos.state -debug 0

通過RS進程進行監視②

alter cell startup services all 執行時　(CELLSRV , MS的啟動)

• 監視對象的進程啟動時就會生成監視這些項目的進程。

• 監視進程:

–cellrssmt – server monitoring process

–cellrsbmt – backup monitoring process

–cellrsomt – oss (outdated name of cellsrv) monitoring process

–cellrsmmt – ms monitoring process

All names prefixed with cellrs

monitoring procs suffixed with mt

制成Heartbeat與incident

• Cellrsmmt檢測MS的http端口是否存在，以及MS的內存使用量是否在規定范圍內

• Cellrsomt檢測CELLSRV是否存在

• Heartbeat失敗時，服務重啟。

–服務重啟之前，監視進程會生ADR incident

通過ps 觀察的監視進程①

通過ps 觀察的監視進程②

通過ps 觀察的監視進程③

通過ps 觀察的監視進程④

主要進程故障時的操作①

• 監視進程可以檢測到進程故障時，并重啟故障進程

• 警報記錄在$ADR_BASE/diag/asm/cell/<hostname>/trace/alert.log中

• 重新啟動花費數秒

• Core RS進程故障時的操作（觀察警報日志就可以明白的操作）

【Thu Aug 23 20:25:40 JST 2012?。?nbsp;kill Core RS進程】
-------------------------------------------------------------------------------
Thu Aug 23 20:25:41 2012 ?。?nbsp;RS-7445 [Serv RS_MAIN is absent] [It will be restarted]
Thu Aug 23 20:25:42 2012　 ： cellrsomt / cellrsbmt / cellrsmmt をshotdown
Thu Aug 23 20:25:43 2012　 ： [RS] Started Service RS_MAIN with pid 26177
Thu Aug 23 20:25:43 2012　 ： cellrsomt / cellrsbmt / cellrsmmt 新pid重新啟動
-------------------------------------------------------------------------------
【另外、CELLSRV / MS /Backup RS 進程之父為”1”】

• Backup RS 進程故障時的操作（觀察警報日志就可以明白的操作）

【 Thu Aug 23 20:47:56?。簁ill Backup RS進程】
-------------------------------------------------------------------------------
Thu Aug 23 20:47:57 2012 ?。?nbsp;RS-7445 [Serv RS_BACKUP is absent] [It will be restarted]
Thu Aug 23 20:47:58 2012　 ： cellrssmt をshotdown
Thu Aug 23 20:47:58 2012　 ： [RS] Started Service RS_BACKUP with pid 28476
Thu Aug 23 20:47:58 2012　 ： cellrssmt を新たしいpidで

• MS 進程故障時的操作（觀察警報日志就可以明白的操作）

【Thu Aug 23 20:55:44 JST 2012?。?nbsp;kill MS進程】
-------------------------------------------------------------------------------
Thu Aug 23 20:55:44 2012 ?。?nbsp;RS-7445 [Serv MS is absent] [It will be restarted]
                ： [RS] Started Service MS with pid 3839

• CELLSRV 進程故障時的操作（觀察警報日志就可以明白的操作）

【Thu Aug 23 20:38:56 JST 2012?。?nbsp;kill CELLSRV 進程】
-------------------------------------------------------------------------------
Thu Aug 23 20:38:56 2012 ?。?nbsp;RS-7445 [Serv CELLSRV is absent] [It will be restarted]
         　 　 ：通過新的pid重啟cellrsomt
Thu Aug 23 20:38:59 2012 ?。?nbsp;FlashLog的有效化
Thu Aug 23 20:38:59 2012　 ： [RS] Started Service CELLSRV with pid 9593
Thu Aug 23 20:39:00 2012　 ： diskmon的Heartbeat開始
Thu Aug 23 20:39:03 2012　 ： FlashCache的有效化

Exadata的I/O的種類

• Block I/O

–一個或者多個的Database Block的I/O

• Smart I/O

–Filtering（行filtering ）以及 Predicate evaluation（列filtering ）通過Storage Server來執行

–Storage Server中的數據處理結果返回到DB Server中，執行剩余處理

Smart I/O的種類

• Smart Scan

–行的filtering  ?。簝H將必需的行返回到DB服務器中

–列的filtering  ?。簝H將必需的列返回到DB服務器中

–Join filtering?。菏褂肂loom filter，結合之前，會執行cell中的filtering

–索引掃描：index fast full scan的話就會執行Smart Scan

• Smart Incremental Backup?。▔埩總浞荩?/p>

–僅僅讀入有變更的塊

• RMAN列表

–在cell中unload數據塊格式

• 創建表空間、數據文件

–在cell中unload數據塊格式

Smart I/O的操作

Smart Scan的選擇

• Smart Scan僅僅在Direct Path Read中執行。

–不通過SGA（緩沖區高速緩存），直接讀入到PGA中

–采用Direct Read的案例（11g）

• 并行執行的情況

• 串行執行的全表掃描中，表尺寸較大的情況

→　花費時間較長的并行查詢以及全表掃描等處理都會成為Smart Scan的對象。

• CBO的判斷步驟

1.與CBO是否使用Exadata無關，直接以Global水平制成執行計劃

• Exadata以外操作相同

2.覺得是否進行Direct lead

• Exadata以外操作相同

3.如果Exadata上已經存在對象文件，就會使用smart scan

※從11.2.0.3.8開始，追加Exadata固有的獲得系統統計的功能，Optimizer可以制成關照到使用了Exadata的情況的計劃了。

Optimizer的演進

• 至此的調優中，都是不考慮Exadata制成制成計劃的

• 缺點的例子之一：”Exadata的Full Table Scan”很快，但選擇了Index Range Scan

11.2.0.3.8以后、系統統計的選項中，通過追加了Exadata 選項得到改善

• 驗證環境

–Exadata V2 Half  11.2.0.3.9 / 11.2.3.1.1

–表　test_tbl

• 約60,000,000行

• 數據量：約 9GB

• Seqid列： 數字的1開始的連續數字（※制成unique index）

• 查詢：Create table <tname> as select * from test_tbl where seqid < 10,000

※元表：60,000,000行?？s小為1/6,000

• Default的plan中包含index range scan

• 查詢：Create table <tname> as select /* +full t */ * from test_tbl t where seqid < 10,000

※元表：60,000,000行?？s小為1/6,000

• Full scan選項時的plan

11.2.0.3.8 中的Cost計算①

• 此前的對策： 刪除index或者invisible化

–對其他查詢有影響

• 11.2.0.2.18 / 11.2.0.3.8中的Optimizer

–Exadata的話，Full Scan的成本估計比起之前降低了

• Scan成本的計算式　　　(Number of blocks to read)/MBRC

• Multi Block Read Count (MBRC)是什么?

一次OS 讀入中，讀入的db block數

–Exadata中，1次OS讀入量為1MB

因此8KB db block的情況下會讀入128 block

＝＞ 但是，Optimizer使用MBRC = 8

• GATHER_SYSTEM_STATS（系統統計）中、制成了用于Exadata的新模式

begin
dbms_stats.gather_system_stats('EXADATA');
end;
/

• Exadata指定時，設定MBRC值。

–DB_FILE_MULTI_BLOCK_READ_COUNT的値（默認値 : 1MB / blocksize）

• 由此我們發現Exadata的Full Scan成本比以前小多了

• 需要Patch for Bug 10248538

（Exadata中，包含11.2.0.2.18 or 11.2.0.3.8 以上）

• 查詢：Create table <tname> as select * from test_tbl where seqid < 10,000

※元表：60,000,000行?？s小1/6,000

• Default的plan在FULL SCAN時在index range scan上被變更了

Smart Scan不適用的案例

詳細內容請參考User’s Guide 「7 Monitoring and Tuning Oracle Exadata Storage Server Software」

• The CELL_OFFLOAD_PROCESSING parameter is set to FALSE.

• The table or partition being scanned is small.

• The optimizer does not use direct path read.

• A scan is performed on a clustered table.

• A scan is performed on an index-organized table.

• A fast full scan is performed on compressed indexes.

• A fast full scan is performed on reverse key indexes.

• The table has row dependencies enabled or the rowscn is being fetched.

• The optimizer wants the scan to return rows in ROWID order.

• The optimizer does not use direct path read.

• The command is CREATE INDEX using nosort.

• A LOB or LONG column is being selected or queried.

• A SELECT … VERSIONS query is done on a table.

• A query that has more than 255 columns referenced and heap table is uncompressed, or Basic or OLTP compressed. However such queries on Exadata Hybrid Columnar Compression-compressed tables are offloaded.

• The tablespace is encrypted, and the CELL_OFFLOAD_DECRYPTION parameter is set to FALSE. In order for Exadata Cell to perform decryption, Oracle Database needs to send the decryption key to Exadata Cell. If there are security concerns about keys being shipped across the network to Exadata Cell, then disable the decryption feature.

• The tablespace is not completely stored on Exadata Cell.

• The predicate evaluation is on a virtual column.

對加密數據進行Smart Scan

• 功能

–TDE表區域加密化、TDE列加密化數據都可以進行SmartScan

–可以靈活使用Xeon 5600 / E7 處理器的AES-NI功能

• AES-NI僅在表區域加密時有效

• Exadata的話，可以與X2-2 / X2-8的DB Server / Storage Server同時使用

• 優點

–通過在存儲中卸載多個處理的過載可以大幅提高DB Server的CPU效率

–通過加密化數據進行filtering，可以減少向DB Server發送的 數據量

HCC壓縮時的操作

• 通過HCC執行壓縮的時機

–在直接路徑加載時執行壓縮

• Parallel DML, INSERT /*+ APPEND */, Direct Path ,SQL*LDR

• 數據壓縮時的操作

–數據在每個列中以列単位執行壓縮

• 因為在壓縮后執行寫入，所以可以減少磁盤I/O

–壓縮處理通過服務器自身來執行進程

對HCC壓縮數據執行查詢時的操作

• 非Smart Scan的情況

–以壓縮狀態讀入到緩沖區高速緩存中，在PGA中展開

–全表掃描的情況

• 讀入所有的Compression Unit，對搜索所需要的列進行展開

• Smart Scan的情況

–在Exadata Storage Server上執行解壓，應用Smart Scan。

※列filtering的情況中，僅將對應的列以壓縮狀態傳送到Database Server中。

–Database Server的解壓處理中減少CPU過載

–壓縮數據通過行filtering，可以減少向DB Server發送的數據量

Smart I/O 【Optimized Smart Scan】

• 11.2.2.3開始的新功能

• Smart Scan時，通過排除Cell的CPU瓶頸，提高性能

• 監視Cell的CPU使用率，CPU使用率超過閥值的話，就會作為通過cell執行的處理的一部分在DB中執行

• 用戶以及管理者的不需要設置就可以自動執行的功能

• 通過Optimized Smart Scan，如果不執行Smart Scan的話，在Cell中使用CPU的下列處理都會被跳過

–Smart Scan

–壓縮數據的解壓處理

–加密數據的解密處理

–判斷是否制成Storage Index等

Optimized Smart Scan的活用例

所有Smart IO都是Optimized Smart Scan的對象。以Cell/DB CPU使用率為基準進行判斷

Optimized Smart Scan的特征

• 通過各Cell進行Optimized Smart Scan判斷時，是以1MB數據単位來執行的，并不是SQL単位以及DB単位

• cellsrv進程每0.2秒都會獲得Cell CPU使用率

• 如果接受Smart I/O 需求的話，以現在的Cell/DB的CPU使用率為基礎，就可以判斷是否需要執行，不執行Smart Scan等直接返回到DB中的處理

DB與Exadata Storage Grid的統合

• Database Server中的cluster membership在Cell的監視中也得到了擴展。

• 認識到Cell 在DB層發生的變化

–Cluster member發生變化后不執行STALE  I/O

–可以不破壞數據高效變更結構

• Cell 的故障會報告給數據庫

數據庫可以查看存儲的操作，存儲也可以查看數據庫的操作

這是僅限Exadata存儲中的合作功能

• Cell 執行監視、報告I/O統計狀況等

處理ASM硬件故障

• ASM的鏡像

–在Allocation Unit水平上執行鏡像。

–使用Exadata時，會自動對每個cell制成故障group（可能同時發生故障的磁盤組合）primary與鏡像的AU會分別儲存在各自的故障group中。

–磁盤以及Cell故障從數據庫中穿透性地執行

Brown out的保護 

＊Brown out＝暫時中止等

• cell以及磁盤無應答時，ASM會暫時將I/O凍結（offline化)

–Read I/O會重放被鏡像化的數據庫。

–追蹤失敗的Write I/O。

• 磁盤可以再次訪問時，offline的Write I/O會被再次執行。

• 快速鏡像化槽（sink）

• 高速修復臨時故障

–例）cell crash以及臨時hang

• 也可以處理計劃中止

–例）更新cell軟件

Cell以及CELLSRV故障時的操作

• CELLSRV 進程故障

–臨時的，時間較短的故障的案例較多。

–CELLSRV 進程的故障時會即時檢測到RS進程，就會重啟CELLSRV。這時，IO客戶端就不會返回IO故障報告，這種案例可以通過自動重新連接繼續進行IO處理來處理（Automatic Reconnect）

• Cell故障

–Cell終止時（OS，設備終止）到重啟為止會花費較多時間。

–DB Server中的Diskmon進程會監視Cell，檢測到cell故障時，就會舍棄對應的cell，對此，ASM就會在對應的cell的磁盤中被舍棄。DB一起ASM的IO會重放其他的cell中的ASM的鏡像。

–觀察IO客戶端的話，CELLSRV性能就會下降，就會變成待機狀態，直到diskmon吧故障cell排除為止，都會使得那個cell上的IO進行hang

• 每個版本從發現故障到解決故障的時間都在縮短。

Cell以及CELLSRV故障時的Brownout時間

• Oracle Exadata Database Machine Unplanned Outage Matrix (Doc ID 1471529.1)

–記載著每個版本各個部件故障時，對應用的影響時間

–最新版的Outage Matrix如下述Note所示

–Oracle Exadata Database Machine Unplanned Outage Matrix 11203 BP7 – 11.2.3.1.1 (Doc ID 1471527.1)

檢測Cell以及CELLSRV故障的檢測 (11.2.0.3 + 11.2.3.1.1)

例１）CELLSRV進程故障等的情況

Brownout時間：數秒(最大8秒)

停止Cell上的軟件stack

–因為CELLSRV, MS, RS全部終止了，進程無法重啟

[root@jigenc01 ~]# date; service celld stop; date;
Mon Aug  6 19:16:53 JST 2012
Stopping the RS, CELLSRV, and MS services...
The SHUTDOWN of services was successful.
Mon Aug  6 19:17:04 JST 2012
[root@jigenc01 ~]#

查看Diskmon的日志

2012-08-06 19:16:52.281: [ DISKMON][16663:1105365312] dskm_process_msg5: received msg type KGZM_PING (0x0011)
2012-08-06 19:16:55.284: [ DISKMON][16663:1105365312] dskm_process_msg5: received msg type KGZM_PING (0x0011)
2012-08-06 19:16:58.285: [ DISKMON][16663:1105365312] dskm_process_msg5: received msg type KGZM_PING (0x0011)
2012-08-06 19:16:58.463: [ DISKMON][16663:1096874304] dskm_tcpmon_thrd_main: Detected a cell death o/192.168.20.51. Posting hbb thread.
2012-08-06 19:16:58.463: [ DISKMON][16663:1111669056] dskm_hb_thrd_main7: posted out of skgxpwait()
2012-08-06 19:16:58.463: [ DISKMON][16663:1111669056] dskm_hb_thrd_main7.1: posted by TCPmon thread
2012-08-06 19:16:58.463: [ DISKMON][16663:1111669056] INFO: Entering Cell Reconnect: rscnam: o/192.168.20.51 rsc: 0x10b81040 state: UNREACHABLE reconn_attempts: 0 last_reconn_ts: 1344248182
2012-08-06 19:16:58.463: [ DISKMON][16663:1111669056] dskm_node_guids_are_offline: query SM done. retcode = 56891(REACHABLE)
2012-08-06 19:16:58.464: [ DISKMON][16663:1111669056] dskm_oss_get_net_info3: oss_get_net_info for device o/192.168.20.51 failed with error 5 (nip = 1)
2012-08-06 19:16:58.464: [ DISKMON][16663:1111669056] dskm_ant_rsc_monitor_start1: dskm_oss_get_net_info failed with error 56841
2012-08-06 19:16:58.464: [ DISKMON][16663:1111669056] dskm_ant_rsc_monitor_start: rscnam: o/192.168.20.51 rsc: 0x10b81040 state: UNREACHABLE reconn_attempts: 1 last_reconn_ts: 1344248218
2012-08-06 19:17:00.466: [ DISKMON][16663:1111669056] dskm_node_guids_are_offline: query SM done. retcode = 56891(REACHABLE)
2012-08-06 19:17:00.467: [ DISKMON][16663:1111669056] dskm_oss_get_net_info3: oss_get_net_info for device o/192.168.20.51 failed with error 5 (nip = 1)
2012-08-06 19:17:00.467: [ DISKMON][16663:1111669056] dskm_ant_rsc_monitor_start1: dskm_oss_get_net_info failed with error 56841
2012-08-06 19:17:00.467: [ DISKMON][16663:1111669056] dskm_ant_rsc_monitor_start: rscnam: o/192.168.20.51 rsc: 0x10b81040 state: UNREACHABLE reconn_attempts: 2 last_reconn_ts: 1344248220
2012-08-06 19:17:10.302: [ DISKMON][16663:1105365312] dskm_process_msg5: received msg type KGZM_PING (0x0011)
2012-08-06 19:17:10.478: [ DISKMON][16663:1111669056] dskm_node_guids_are_offline: query SM done. retcode = 56891(REACHABLE)
2012-08-06 19:17:10.479: [ DISKMON][16663:1111669056] dskm_oss_get_net_info3: oss_get_net_info for device o/192.168.20.51 failed with error 5 (nip = 1)
2012-08-06 19:17:10.479: [ DISKMON][16663:1111669056] dskm_ant_rsc_monitor_start1: dskm_oss_get_net_info failed with error 56841
2012-08-06 19:17:10.479: [ DISKMON][16663:1111669056] dskm_ant_rsc_monitor_start: rscnam: o/192.168.20.51 rsc: 0x10b81040 state: UNREACHABLE reconn_attempts: 7 last_reconn_ts: 1344248230
2012-08-06 19:17:10.479: [ DISKMON][16663:1111669056] dskm_queue_tcpmon_request: posting
2012-08-06 19:17:10.479: [ DISKMON][16663:1111669056] dskm_post_tcpmon_thrd
2012-08-06 19:17:10.480: [ DISKMON][16663:1096874304] dskm_tcpmon_thrd_main: posted, poll returned with retcode = 45
2012-08-06 19:17:10.480: [ DISKMON][16663:1096874304] dskm_tcpmon_thrd_main: Got a request with type 2, cellname = o/192.168.20.51, cellname length 16, cell incarnation = 0
2012-08-06 19:17:10.480: [ DISKMON][16663:1096874304] dskm_tcpmon_thrd_main: Cant find the corresponding monitor request in progress, unmonitor request will be ignored
Reconnect 失敗8次，進入Cell的evict的進程。
之后diskmon通知dskm，cell down。
Mon Aug 06 19:17:10 2012
Exadata cell: o/192.168.20.51 is no longer accessible. I/O errors to disks on this might get suppressed
Mon Aug 06 19:17:10 2012
NOTE: process _user14223_+asm1 (14223) initiating offline of disk 74.3916043773 (DATA_H_CD_05_JIGENC01) with mask 0x7e[0x7f] in group 1
WARNING: Disk 74 (DATA_H_CD_05_JIGENC01) in group 1 in mode 0x7f is now being taken offline on ASM inst 1
WARNING: Disk 72 (DATA_H_CD_04_JIGENC01) in group 1 in mode 0x7f is now being taken offline on ASM inst 1
WARNING: Disk 73 (DATA_H_CD_02_JIGENC01) in group 1 in mode 0x7f is now being taken offline on ASM inst 1
WARNING: Disk 75 (DATA_H_CD_01_JIGENC01) in group 1 in mode 0x7f is now being taken offline on ASM inst 1
＜中略。Cell上的全Griddisk分＞
NOTE: initiating PST update: grp = 1, dsk = 79/0xe96a1602, mask = 0x6a, op = clear
NOTE: initiating PST update: grp = 1, dsk = 80/0xe96a1603, mask = 0x6a, op = clear
NOTE: initiating PST update: grp = 1, dsk = 81/0xe96a1604, mask = 0x6a, op = clear
NOTE: initiating PST update: grp = 1, dsk = 82/0xe96a1605, mask = 0x6a, op = clear
NOTE: initiating PST update: grp = 1, dsk = 83/0xe96a1606, mask = 0x6a, op = clear
Mon Aug 06 19:17:10 2012
NOTE: process _user26170_+asm1 (26170) initiating offline of disk 66.3916043034 (DBFS_DG_CD_11_JIGENC01) with mask 0x7e[0x7f] in group 4
WARNING: Disk 66 (DBFS_DG_CD_11_JIGENC01) in group 4 in mode 0x7f is now being taken offline on ASM inst 1
WARNING: Disk 60 (DBFS_DG_CD_08_JIGENC01) in group 4 in mode 0x7f is now being taken offline on ASM inst 1
WARNING: Disk 61 (DBFS_DG_CD_07_JIGENC01) in group 4 in mode 0x7f is now being taken offline on ASM inst 1
馬上對對應的cell中的disk進行offline

2-1. 切斷TCP connection，即時檢測Cell death

Proactive disk drop　 （11.2.1.3.1～）

• 一般的ASM中，發生一個磁盤故障時，ASM會等待超時，然后自動刪除對應磁盤。刪除完成之前，如果發生其他的磁盤故障的話，就可能變成二重故障，丟失數據。

• 11.2.1.3.1以后的版本，通過Exadata Storage Server預測到物理磁盤的故障以及其他故障時

–在ASM超時之前，就會在pro-active從ASM磁盤group中刪除磁盤

–ASM會將故障磁盤上的數據重新移動到其他磁盤上

可以及時回復ASM磁盤group的冗長性，減少丟失數據的危險

• 即使是檢測到Flash module故障的情況，也會從Smart Flash Cache中刪除對應的Flash module，或者從ASM group中，刪除對應的Flash Grid Disk。

自動修復的進程

• Cell中

–MS進程

• cell的管理進程。

• 檢測到磁盤故障的話就會重新生成警報，如果檢測到插入了新的磁盤的話，就會執行重新制成LUN以及celldisk,griddisk所必需的操作。

• ASM實例內

–XDMG進程(Exadata Automation Manager)

• 監視cell的狀態變更，如果需要更換磁盤的話，就執行對應的task。監視無法訪問的磁盤以及cell?？梢栽L問時，就執行檢測，開始ONLINE處理。

–XDWK進程(Exadata Automation Worker)

• 從XDMG進程中自動執行對應的task。XDWK進程會在執行ONLINE、DROP、ADD等非同步處理時啟動。不是活躍狀態的話持續五分鐘就會終止進程。

操作Proactive Disk Drop的條件

• Proactive Disk Drop 需要通過以下條件進行操作

• 物理故障（Failed） 時

–HDD

–Flash disk

• 預測故障（Predictive Failure） 狀態

–HDD

–Flash disk

• 性能極端緩慢的狀態（Poor Performance）

–Flash disk

注意：僅僅通過物理性地拔出HDD ，是無法查看 Failed 的狀態的

這種情況的對策一如既往，（將ASM 磁盤offline，等待disk_repair_time

超時，刪除。重新插入磁盤的話，就會自動重新制成Griddisk,Celldisk。

自動執行ASM 磁盤的offline或者 Add。

到此，關于“Oracle Exadata存儲服務器原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！