這篇文章主要介紹“Oracle Exadata存儲(chǔ)服務(wù)器原理是什么”，在日常操作中，相信很多人在Oracle Exadata存儲(chǔ)服務(wù)器原理是什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”O(jiān)racle Exadata存儲(chǔ)服務(wù)器原理是什么”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

桐柏網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,桐柏網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為桐柏上千多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的桐柏做網(wǎng)站的公司定做！

Exadata Storage Server的機(jī)制

• Exadata的I/O流程

• Exadata的抗故障性

–“Storage”故障時(shí)，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對(duì)應(yīng)11.2.0.3

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

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

Exadata 架構(gòu)（全景)

InfiniBand Network

• OL/Solaris中需要安裝ofed驅(qū)動(dòng)

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

• Cell之間無(wú)法互相交換信息。跨越多個(gè)cell的操作安裝在DB Server中

→實(shí)現(xiàn)Cell的完全Scale-out

Exadata Storage Server上有哪些進(jìn)程？

oracle是如何連接ASM/DB的IO/ASM層到Exadata 存儲(chǔ)服務(wù)器的？

• Cell Server(CELLSRV)負(fù)責(zé)與DB Server的信息交換。于是變成多線程，各個(gè)線程對(duì)磁盤(pán)與網(wǎng)絡(luò)執(zhí)行非同步I/O

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

• Restart Server (RS) 監(jiān)視CELLSRV與MS。進(jìn)程的存亡、內(nèi)存使用狀況等。

通過(guò)Exadata Storage Server Software檢測(cè)HW故障的機(jī)制

• MS為Exadata的Hardware故障, 檢測(cè)Software故障

–也可以從CellCLI 查看HW故障

• Exadata 可以內(nèi)部通過(guò)MS直接與ILOM通信，獲得信息

–對(duì)于ILOM中自節(jié)點(diǎn)的eth0 (management eth)的IP， SNMP trap會(huì)跳過(guò)。

• CellCLI是Exadata中管理各Cell的utility?？梢宰兏麰xadata Storage Server 的設(shè)定、展示警報(bào)歷史警報(bào)歷史、 展示metric、進(jìn)行維護(hù)

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

■ 從CellCLI 觀察的情況
[root@cell01] # cellcli -e list cell detail | tail -n 3
         cellsrvStatus:          running
         msStatus:               running
         rsStatus:               running
■ 從ps 中觀察的情況
CELLSRV 進(jìn)程
[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 進(jìn)程
[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 中觀察的情況 續(xù)表

• MS 進(jìn)程

[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) 通過(guò)CRS，與CSS同時(shí)啟動(dòng)與CELLSRV通信

• Slave diskmon (dskm) 作為各個(gè)實(shí)例的一部存在與master進(jìn)行通信

• 執(zhí)行檢測(cè)Cell故障，分配IO fencing 、IO資源管理

Cellinit.ora

• 決定Cellinit.ora到底使用哪個(gè)網(wǎng)絡(luò)界面，與哪個(gè)存儲(chǔ)交換信息（指定InfiniBand的bondib0）

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

ipaddress1=192.168.20.81/22

• Cellip.ora存儲(chǔ)cell的列表 增加新的cell時(shí)可以動(dòng)態(tài)加入到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 進(jìn)程

[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 進(jìn)程

[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認(rèn)識(shí)DB Server的機(jī)制

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

• 如果有Cell的磁盤(pán)故障的情況的話，就會(huì)以這個(gè)屬性為基礎(chǔ)，從Diskgroup中，對(duì)對(duì)應(yīng)的ASM磁盤(pán)進(jìn)行drop

• DB/ASM通過(guò)Libcell（library）與CELLSRV通信

• 通信中，使用iDB 協(xié)議

• Exadata存儲(chǔ)通信中使用的Exadata固有的協(xié)議

• 基于RDS協(xié)議來(lái)構(gòu)筑的InfiniBand上的操作

Exadata Storage Server Software的警報(bào)日志

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

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

• 與Oracle Database相同，可以使用ADRCI進(jìn)行管理

日志文件、追蹤文件

• Cell的日志

–$ADR_BASE/diag/asm/cell//trace/

–存在CELLSRV、RS、MS的警報(bào)日志以及追蹤文件

• alert.log : CELLSRV與RS的警報(bào)日志

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

• svtrc__.trc (svtrc_13661_0.trc) : CELLSRV的追蹤文件

• rstrc__.trc (rstrc_27528_4.trc) : RS的追蹤文件

• Diskmon的日志文件

–$ORA_CRS_HOME/log//diskmon/

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

進(jìn)程、設(shè)定文件等一覽（數(shù)據(jù)庫(kù)中）

• diskmon、dskm

• master diskmon (diskmon) 與CSS同時(shí)啟動(dòng)，與CELLSRV通信。

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

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

• cellip.ora

• DB服務(wù)器使用的cell的機(jī)器IP列表

• cellinit.ora

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

• CELLSRV

• CELLSRV中1個(gè)cell中1個(gè)進(jìn)程（多線程）。線程對(duì)磁盤(pán)以及網(wǎng)絡(luò)會(huì)執(zhí)行非同步IO。

• MS

• 制成/刪除Grid磁盤(pán)、變更H/W、展示、管理SNMP trap、警報(bào)、缺點(diǎn)。

• RS

• 監(jiān)視CELLSRV與MS。RS監(jiān)視進(jìn)程存亡、

內(nèi)存使用率等。Backup RS監(jiān)視Core RS。

• CellCLI

• 執(zhí)行用戶操作與構(gòu)成的命令行工具

各進(jìn)程的作用

通過(guò)RS進(jìn)程進(jìn)行的監(jiān)視①

alter cell startup services all 執(zhí)行時(shí)　(Backup RS的啟動(dòng))

• Core RS 進(jìn)程

[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 進(jìn)程

[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

通過(guò)RS進(jìn)程進(jìn)行監(jiān)視②

alter cell startup services all 執(zhí)行時(shí)　(CELLSRV , MS的啟動(dòng))

• 監(jiān)視對(duì)象的進(jìn)程啟動(dòng)時(shí)就會(huì)生成監(jiān)視這些項(xiàng)目的進(jìn)程。

• 監(jiān)視進(jìn)程:

–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檢測(cè)MS的http端口是否存在，以及MS的內(nèi)存使用量是否在規(guī)定范圍內(nèi)

• Cellrsomt檢測(cè)CELLSRV是否存在

• Heartbeat失敗時(shí)，服務(wù)重啟。

–服務(wù)重啟之前，監(jiān)視進(jìn)程會(huì)生ADR incident

通過(guò)ps 觀察的監(jiān)視進(jìn)程①

通過(guò)ps 觀察的監(jiān)視進(jìn)程②

通過(guò)ps 觀察的監(jiān)視進(jìn)程③

通過(guò)ps 觀察的監(jiān)視進(jìn)程④

主要進(jìn)程故障時(shí)的操作①

• 監(jiān)視進(jìn)程可以檢測(cè)到進(jìn)程故障時(shí)，并重啟故障進(jìn)程

• 警報(bào)記錄在$ADR_BASE/diag/asm/cell//trace/alert.log中

• 重新啟動(dòng)花費(fèi)數(shù)秒

• Core RS進(jìn)程故障時(shí)的操作（觀察警報(bào)日志就可以明白的操作）

【Thu Aug 23 20:25:40 JST 2012　： kill Core RS進(jìn)程】
-------------------------------------------------------------------------------
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重新啟動(dòng)
-------------------------------------------------------------------------------
【另外、CELLSRV / MS /Backup RS 進(jìn)程之父為”1”】

• Backup RS 進(jìn)程故障時(shí)的操作（觀察警報(bào)日志就可以明白的操作）

【 Thu Aug 23 20:47:56　：kill Backup RS進(jìn)程】
-------------------------------------------------------------------------------
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 進(jìn)程故障時(shí)的操作（觀察警報(bào)日志就可以明白的操作）

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

• CELLSRV 進(jìn)程故障時(shí)的操作（觀察警報(bào)日志就可以明白的操作）

【Thu Aug 23 20:38:56 JST 2012?。?nbsp;kill CELLSRV 進(jìn)程】
-------------------------------------------------------------------------------
Thu Aug 23 20:38:56 2012 ?。?nbsp;RS-7445 [Serv CELLSRV is absent] [It will be restarted]
         　 　 ：通過(guò)新的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開(kāi)始
Thu Aug 23 20:39:03 2012　 ： FlashCache的有效化

Exadata的I/O的種類(lèi)

• Block I/O

–一個(gè)或者多個(gè)的Database Block的I/O

• Smart I/O

–Filtering（行filtering ）以及 Predicate evaluation（列filtering ）通過(guò)Storage Server來(lái)執(zhí)行

–Storage Server中的數(shù)據(jù)處理結(jié)果返回到DB Server中，執(zhí)行剩余處理

Smart I/O的種類(lèi)

• Smart Scan

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

–列的filtering  　：僅將必需的列返回到DB服務(wù)器中

–Join filtering?。菏褂肂loom filter，結(jié)合之前，會(huì)執(zhí)行cell中的filtering

–索引掃描：index fast full scan的話就會(huì)執(zhí)行Smart Scan

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

–僅僅讀入有變更的塊

• RMAN列表

–在cell中unload數(shù)據(jù)塊格式

• 創(chuàng)建表空間、數(shù)據(jù)文件

–在cell中unload數(shù)據(jù)塊格式

Smart I/O的操作

Smart Scan的選擇

• Smart Scan僅僅在Direct Path Read中執(zhí)行。

–不通過(guò)SGA（緩沖區(qū)高速緩存），直接讀入到PGA中

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

• 并行執(zhí)行的情況

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

→　花費(fèi)時(shí)間較長(zhǎng)的并行查詢以及全表掃描等處理都會(huì)成為Smart Scan的對(duì)象。

• CBO的判斷步驟

1.與CBO是否使用Exadata無(wú)關(guān)，直接以Global水平制成執(zhí)行計(jì)劃

• Exadata以外操作相同

2.覺(jué)得是否進(jìn)行Direct lead

• Exadata以外操作相同

3.如果Exadata上已經(jīng)存在對(duì)象文件，就會(huì)使用smart scan

※從11.2.0.3.8開(kāi)始，追加Exadata固有的獲得系統(tǒng)統(tǒng)計(jì)的功能，Optimizer可以制成關(guān)照到使用了Exadata的情況的計(jì)劃了。

Optimizer的演進(jìn)

• 至此的調(diào)優(yōu)中，都是不考慮Exadata制成制成計(jì)劃的

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

11.2.0.3.8以后、系統(tǒng)統(tǒng)計(jì)的選項(xiàng)中，通過(guò)追加了Exadata 選項(xiàng)得到改善

• 驗(yàn)證環(huán)境

–Exadata V2 Half  11.2.0.3.9 / 11.2.3.1.1

–表　test_tbl

• 約60,000,000行

• 數(shù)據(jù)量：約 9GB

• Seqid列： 數(shù)字的1開(kāi)始的連續(xù)數(shù)字（※制成unique index）

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

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

• Default的plan中包含index range scan

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

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

• Full scan選項(xiàng)時(shí)的plan

11.2.0.3.8 中的Cost計(jì)算①

• 此前的對(duì)策： 刪除index或者invisible化

–對(duì)其他查詢有影響

• 11.2.0.2.18 / 11.2.0.3.8中的Optimizer

–Exadata的話，F(xiàn)ull Scan的成本估計(jì)比起之前降低了

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

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

一次OS 讀入中，讀入的db block數(shù)

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

因此8KB db block的情況下會(huì)讀入128 block

＝＞ 但是，Optimizer使用MBRC = 8

• GATHER_SYSTEM_STATS（系統(tǒng)統(tǒng)計(jì)）中、制成了用于Exadata的新模式

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

• Exadata指定時(shí)，設(shè)定MBRC值。

–DB_FILE_MULTI_BLOCK_READ_COUNT的値（默認(rèn)値 : 1MB / blocksize）

• 由此我們發(fā)現(xiàn)Exadata的Full Scan成本比以前小多了

• 需要Patch for Bug 10248538

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

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

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

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

Smart Scan不適用的案例

詳細(xì)內(nèi)容請(qǐng)參考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.

對(duì)加密數(shù)據(jù)進(jìn)行Smart Scan

• 功能

–TDE表區(qū)域加密化、TDE列加密化數(shù)據(jù)都可以進(jìn)行SmartScan

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

• AES-NI僅在表區(qū)域加密時(shí)有效

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

• 優(yōu)點(diǎn)

–通過(guò)在存儲(chǔ)中卸載多個(gè)處理的過(guò)載可以大幅提高DB Server的CPU效率

–通過(guò)加密化數(shù)據(jù)進(jìn)行filtering，可以減少向DB Server發(fā)送的 數(shù)據(jù)量

HCC壓縮時(shí)的操作

• 通過(guò)HCC執(zhí)行壓縮的時(shí)機(jī)

–在直接路徑加載時(shí)執(zhí)行壓縮

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

• 數(shù)據(jù)壓縮時(shí)的操作

–數(shù)據(jù)在每個(gè)列中以列単位執(zhí)行壓縮

• 因?yàn)樵趬嚎s后執(zhí)行寫(xiě)入，所以可以減少磁盤(pán)I/O

–壓縮處理通過(guò)服務(wù)器自身來(lái)執(zhí)行進(jìn)程

對(duì)HCC壓縮數(shù)據(jù)執(zhí)行查詢時(shí)的操作

• 非Smart Scan的情況

–以壓縮狀態(tài)讀入到緩沖區(qū)高速緩存中，在PGA中展開(kāi)

–全表掃描的情況

• 讀入所有的Compression Unit，對(duì)搜索所需要的列進(jìn)行展開(kāi)

• Smart Scan的情況

–在Exadata Storage Server上執(zhí)行解壓，應(yīng)用Smart Scan。

※列filtering的情況中，僅將對(duì)應(yīng)的列以壓縮狀態(tài)傳送到Database Server中。

–Database Server的解壓處理中減少CPU過(guò)載

–壓縮數(shù)據(jù)通過(guò)行filtering，可以減少向DB Server發(fā)送的數(shù)據(jù)量

Smart I/O 【Optimized Smart Scan】

• 11.2.2.3開(kāi)始的新功能

• Smart Scan時(shí)，通過(guò)排除Cell的CPU瓶頸，提高性能

• 監(jiān)視Cell的CPU使用率，CPU使用率超過(guò)閥值的話，就會(huì)作為通過(guò)cell執(zhí)行的處理的一部分在DB中執(zhí)行

• 用戶以及管理者的不需要設(shè)置就可以自動(dòng)執(zhí)行的功能

• 通過(guò)Optimized Smart Scan，如果不執(zhí)行Smart Scan的話，在Cell中使用CPU的下列處理都會(huì)被跳過(guò)

–Smart Scan

–壓縮數(shù)據(jù)的解壓處理

–加密數(shù)據(jù)的解密處理

–判斷是否制成Storage Index等

Optimized Smart Scan的活用例

所有Smart IO都是Optimized Smart Scan的對(duì)象。以Cell/DB CPU使用率為基準(zhǔn)進(jìn)行判斷

Optimized Smart Scan的特征

• 通過(guò)各Cell進(jìn)行Optimized Smart Scan判斷時(shí)，是以1MB數(shù)據(jù)単位來(lái)執(zhí)行的，并不是SQL単位以及DB単位

• cellsrv進(jìn)程每0.2秒都會(huì)獲得Cell CPU使用率

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

DB與Exadata Storage Grid的統(tǒng)合

• Database Server中的cluster membership在Cell的監(jiān)視中也得到了擴(kuò)展。

• 認(rèn)識(shí)到Cell 在DB層發(fā)生的變化

–Cluster member發(fā)生變化后不執(zhí)行STALE  I/O

–可以不破壞數(shù)據(jù)高效變更結(jié)構(gòu)

• Cell 的故障會(huì)報(bào)告給數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)可以查看存儲(chǔ)的操作，存儲(chǔ)也可以查看數(shù)據(jù)庫(kù)的操作

這是僅限Exadata存儲(chǔ)中的合作功能

• Cell 執(zhí)行監(jiān)視、報(bào)告I/O統(tǒng)計(jì)狀況等

處理ASM硬件故障

• ASM的鏡像

–在Allocation Unit水平上執(zhí)行鏡像。

–使用Exadata時(shí)，會(huì)自動(dòng)對(duì)每個(gè)cell制成故障group（可能同時(shí)發(fā)生故障的磁盤(pán)組合）primary與鏡像的AU會(huì)分別儲(chǔ)存在各自的故障group中。

–磁盤(pán)以及Cell故障從數(shù)據(jù)庫(kù)中穿透性地執(zhí)行

Brown out的保護(hù) 

＊Brown out＝暫時(shí)中止等

• cell以及磁盤(pán)無(wú)應(yīng)答時(shí)，ASM會(huì)暫時(shí)將I/O凍結(jié)（offline化)

–Read I/O會(huì)重放被鏡像化的數(shù)據(jù)庫(kù)。

–追蹤失敗的Write I/O。

• 磁盤(pán)可以再次訪問(wèn)時(shí)，offline的Write I/O會(huì)被再次執(zhí)行。

• 快速鏡像化槽（sink）

• 高速修復(fù)臨時(shí)故障

–例）cell crash以及臨時(shí)hang

• 也可以處理計(jì)劃中止

–例）更新cell軟件

Cell以及CELLSRV故障時(shí)的操作

• CELLSRV 進(jìn)程故障

–臨時(shí)的，時(shí)間較短的故障的案例較多。

–CELLSRV 進(jìn)程的故障時(shí)會(huì)即時(shí)檢測(cè)到RS進(jìn)程，就會(huì)重啟CELLSRV。這時(shí)，IO客戶端就不會(huì)返回IO故障報(bào)告，這種案例可以通過(guò)自動(dòng)重新連接繼續(xù)進(jìn)行IO處理來(lái)處理（Automatic Reconnect）

• Cell故障

–Cell終止時(shí)（OS，設(shè)備終止）到重啟為止會(huì)花費(fèi)較多時(shí)間。

–DB Server中的Diskmon進(jìn)程會(huì)監(jiān)視Cell，檢測(cè)到cell故障時(shí)，就會(huì)舍棄對(duì)應(yīng)的cell，對(duì)此，ASM就會(huì)在對(duì)應(yīng)的cell的磁盤(pán)中被舍棄。DB一起ASM的IO會(huì)重放其他的cell中的ASM的鏡像。

–觀察IO客戶端的話，CELLSRV性能就會(huì)下降，就會(huì)變成待機(jī)狀態(tài)，直到diskmon吧故障cell排除為止，都會(huì)使得那個(gè)cell上的IO進(jìn)行hang

• 每個(gè)版本從發(fā)現(xiàn)故障到解決故障的時(shí)間都在縮短。

Cell以及CELLSRV故障時(shí)的Brownout時(shí)間

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

–記載著每個(gè)版本各個(gè)部件故障時(shí)，對(duì)應(yīng)用的影響時(shí)間

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

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

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

例１）CELLSRV進(jìn)程故障等的情況

Brownout時(shí)間：數(shù)秒(最大8秒)

停止Cell上的軟件stack

–因?yàn)镃ELLSRV, MS, RS全部終止了，進(jìn)程無(wú)法重啟

[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次，進(jìn)入Cell的evict的進(jìn)程。
之后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
馬上對(duì)對(duì)應(yīng)的cell中的disk進(jìn)行offline

2-1. 切斷TCP connection，即時(shí)檢測(cè)Cell death

Proactive disk drop　 （11.2.1.3.1～）

• 一般的ASM中，發(fā)生一個(gè)磁盤(pán)故障時(shí)，ASM會(huì)等待超時(shí)，然后自動(dòng)刪除對(duì)應(yīng)磁盤(pán)。刪除完成之前，如果發(fā)生其他的磁盤(pán)故障的話，就可能變成二重故障，丟失數(shù)據(jù)。

• 11.2.1.3.1以后的版本，通過(guò)Exadata Storage Server預(yù)測(cè)到物理磁盤(pán)的故障以及其他故障時(shí)

–在ASM超時(shí)之前，就會(huì)在pro-active從ASM磁盤(pán)group中刪除磁盤(pán)

–ASM會(huì)將故障磁盤(pán)上的數(shù)據(jù)重新移動(dòng)到其他磁盤(pán)上

可以及時(shí)回復(fù)ASM磁盤(pán)group的冗長(zhǎng)性，減少丟失數(shù)據(jù)的危險(xiǎn)

• 即使是檢測(cè)到Flash module故障的情況，也會(huì)從Smart Flash Cache中刪除對(duì)應(yīng)的Flash module，或者從ASM group中，刪除對(duì)應(yīng)的Flash Grid Disk。

自動(dòng)修復(fù)的進(jìn)程

• Cell中

–MS進(jìn)程

• cell的管理進(jìn)程。

• 檢測(cè)到磁盤(pán)故障的話就會(huì)重新生成警報(bào)，如果檢測(cè)到插入了新的磁盤(pán)的話，就會(huì)執(zhí)行重新制成LUN以及celldisk,griddisk所必需的操作。

• ASM實(shí)例內(nèi)

–XDMG進(jìn)程(Exadata Automation Manager)

• 監(jiān)視cell的狀態(tài)變更，如果需要更換磁盤(pán)的話，就執(zhí)行對(duì)應(yīng)的task。監(jiān)視無(wú)法訪問(wèn)的磁盤(pán)以及cell?？梢栽L問(wèn)時(shí)，就執(zhí)行檢測(cè)，開(kāi)始ONLINE處理。

–XDWK進(jìn)程(Exadata Automation Worker)

• 從XDMG進(jìn)程中自動(dòng)執(zhí)行對(duì)應(yīng)的task。XDWK進(jìn)程會(huì)在執(zhí)行ONLINE、DROP、ADD等非同步處理時(shí)啟動(dòng)。不是活躍狀態(tài)的話持續(xù)五分鐘就會(huì)終止進(jìn)程。

操作Proactive Disk Drop的條件

• Proactive Disk Drop 需要通過(guò)以下條件進(jìn)行操作

• 物理故障（Failed） 時(shí)

–HDD

–Flash disk

• 預(yù)測(cè)故障（Predictive Failure） 狀態(tài)

–HDD

–Flash disk

• 性能極端緩慢的狀態(tài)（Poor Performance）

–Flash disk

注意：僅僅通過(guò)物理性地拔出HDD ，是無(wú)法查看 Failed 的狀態(tài)的

這種情況的對(duì)策一如既往，（將ASM 磁盤(pán)offline，等待disk_repair_time

超時(shí)，刪除。重新插入磁盤(pán)的話，就會(huì)自動(dòng)重新制成Griddisk,Celldisk。

自動(dòng)執(zhí)行ASM 磁盤(pán)的offline或者 Add。

到此，關(guān)于“Oracle Exadata存儲(chǔ)服務(wù)器原理是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！