查询Oracle RAC Cache Fusion通信的私有网络_数据库技术_Linux公社-Linux系统门户网站
你好，游客
查询Oracle RAC Cache Fusion通信的私有网络
来源：Linux社区&
作者：staricqxyz
[@zhongwc1 ~]$ cat /etc/-release&
Enterprise Linux Server release 5.7 (Tikanga)& [oracle@zhongwc1 ~]$ sqlplus / as sysdba& & SQL*Plus: Release 11.2.0.3.0 Production on Tue Jan 22 15:12:35 2013& & Copyright (c) , Oracle.& All rights reserved.& & & Connected to:& Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production& With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,& Data Mining and Real Application Testing options& & SQL& oradebug setmypid& Statement processed.& SQL& oradebug ipc& Information written to trace file.& SQL& oradebug tracefile_name& /u01/app/oracle/diag/rdbms/zhongwc/zhongwc1/trace/zhongwc1_ora_31553.trc& SQL& exit& Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production& With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,& Data Mining and Real Application Testing options&
Oracle版本是11.2.0.3,从11.2.0.2开始引入了HAIP规则为169.254.xxx.RAC Cache Fusion通信的IP为169.254.218.13
SKGXP:[7f31b]{ctx}:SSKGXPT 0x7f31b772e848 flags 0x0& sockno 13 IP 169.254.218.13 UDP 30898 lerr 0SKGXP:[7f31b]{ctx}:&
SKGXPGPID Internet address 169.254.218.13 UDP port number 30898
[oracle@zhongwc1 ~]$ cat /u01/app/oracle/diag/rdbms/zhongwc/zhongwc1/trace/zhongwc1_ora_31553.trc& Trace file /u01/app/oracle/diag/rdbms/zhongwc/zhongwc1/trace/zhongwc1_ora_31553.trc& Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production& With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,& Data Mining and Real Application Testing options& ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1& System name:& & Linux& Node name:& & Release:& & 2.6.32-200.13.1.el5uek& Version:& & #1 SMP Wed Jul 27 21:02:33 EDT 2011& Machine:& & x86_64& Instance name: zhongwc1& Redo thread mounted by this instance: 1& Oracle process number: 38& Unix process pid: 31553, image:
(TNS V1-V3)& & & ***
15:12:37.782& *** SESSION ID:(56.143)
15:12:37.782& *** CLIENT ID:()
15:12:37.782& *** SERVICE NAME:(SYS$USERS)
15:12:37.782& *** MODULE NAME:( (TNS V1-V3))
15:12:37.782& *** ACTION NAME:()
15:12:37.782& &
Processing Oradebug command 'setmypid'& & ***
15:12:37.782& Oradebug command 'setmypid' console output: &none&& & ***
15:12:39.777& Processing Oradebug command 'ipc'& Dump of unix-generic skgm context& areaflags& & & & & & & realmflags& & & & &
0000001f& mapsize& & & & & & & & protectsize& & & & & & lcmsize& & & & & & & & seglen& & & & & & &
& largestsize& 0000& smallestsize 0000& stacklimit& &
0x7fffafa932a0& stackdir& & & & & & & & &
-1& mode& & & & & & & & & & & 640& magic& & & & & & & & acc01ade& Handle:& & & & 0x7f31b77150f0 `/u01/app/oracle/product/11.2.0/dbhome_1zhongwc1'& Dump of unix-generic realm handle `/u01/app/oracle/product/11.2.0/dbhome_1zhongwc1', flags = & &Area #0 `Fixed Size' containing Subareas 0-0& & Total size ff10 Minimum Subarea size & &
Area& Subarea& & Shmid& & & Stable Addr& & & Actual Addr& & & & 0& & & & 0& x00 0x00& & & & & & & & & & & & & & & & Subarea size& &
Segment size& & & & & & & & & & & & & & & &Area #1 `Variable Size' containing Subareas 4-4& & Total size 0000 Minimum Subarea size & &
Area& Subarea& & Shmid& & & Stable Addr& & & Actual Addr& & & & 1& & & & 4& x00 0x00& & & & & & & & & & & & & & & & Subarea size& &
Segment size& & & & & & & & & & & & & & 04b000000& &Area #2 `Redo Buffers' containing Subareas 1-1& & Total size 0000 Minimum Subarea size & &
Area& Subarea& & Shmid& & & Stable Addr& & & Actual Addr& & & & 2& & & & 1& x00 0x00& & & & & & & & & & & & & & & & Subarea size& &
Segment size& & & & & & & & & & & & & & & &Area #3 `Base Allocator Control' containing Subareas 3-3& & Total size 2000 Minimum Subarea size & &
Area& Subarea& & Shmid& & & Stable Addr& & & Actual Addr& & & & 3& & & & 3& xffe000 0xffe000& & & & & & & & & & & & & & & & Subarea size& &
Segment size& & & & & & & & & & & & & & & &Area #4 `Slab Allocator Control' containing Subareas 2-2& & Total size e000 Minimum Subarea size & &
Area& Subarea& & Shmid& & & Stable Addr& & & Actual Addr& & & & 4& & & & 2& x00 0x00& & & & & & & & & & & & & & & & Subarea size& &
Segment size& & & & & & & & & & & & & & e000 0000& &Area #5 `skgm overhead' containing Subareas 5-5& & Total size 2000 Minimum Subarea size & &
Area& Subarea& & Shmid& & & Stable Addr& & & Actual Addr& & & & 5& & & & 5& x000ac000000& & & & & & & & & & & & & & & & Subarea size& &
Segment size& & & & & & & & & & & & & & & Dump of Linux-specific skgm context& sharedmmu & shareddec& & & & 0& used region& & & & 0: start 0000 length 0000& used region& & & & 1: start 00000 length 0000& used region& & & & 2: start 00000 length 0000& Maximum processes:& & & & & & &
= 800& Number of semaphores per set:& & = 201& Semaphores key overhead per set: = 4& User Semaphores per set:& & & &
= 197& Number of semaphore sets:& & & & = 5& Semaphore identifiers:& & & & &
= 5& Semaphore List=& 2097154& 2129923& 2162692& 2195461& 2228230& -------------- system semaphore information -------------& ------ Shared Memory Segments --------& key& & & & shmid& & & owner& & & perms& & & bytes& & & nattch& &
status& & & & 0x1617& & root& & & 644& & & & 80& & & &
2& & & & & & & & & & & &
0x4386& & root& & & 644& & & & 16384& & & 2& & & & & & & & & & & &
0x7155& & root& & & 644& & & & 280& & & & 2& & & & & & & & & & & &
0x9301& & grid& & & 640& & & & 4096& & &
0& & & & & & & & & & & &
0x2070& & grid& & & 640& & & & 4096& & &
0& & & & & & & & & & & &
0xed304ac0 2424839& & grid& & & 640& & & & 4096& & &
0& & & & & & & & & & & &
0x5560& & oracle& & 640& & & & 4096& & &
0& & & & & & & & & & & &
0x8329& & oracle& & 640& & & & 4096& & &
0& & & & & & & & & & & &
0x1098& & oracle& & 640& & & & 4096& & &
0& & & & & & & & & & & &
------ Semaphore Arrays --------& key& & & & semid& & & owner& & & perms& & & nsems& & &
0x869d3e0c 262145& &
grid& & & 640& & & & 124& & & &
0xb7154& & oracle& & 640& & & & 201& & & &
0xb9923& & oracle& & 640& & & & 201& & & &
0xb2692& & oracle& & 640& & & & 201& & & &
0xb5461& & oracle& & 640& & & & 201& & & &
0xb8230& & oracle& & 640& & & & 201& & & &
------ Message Queues --------& key& & & & msqid& & & owner& & & perms& & & used-bytes&
messages& & & ksxpdmp:& facility 0 (?) (0x0, (nil)) counts 0, 0& Dumping the osd state& & Dumping the osd context (brief)& SKGXP:[7f31b]{ctx}: SKGXPCTX: 0x0x7f31b7724c68 ctx& &
SKGXP:[7f31b]{ctx}: Compatible: 0 0.0 0& SKGXP:[7f31b]{ctx}: SKGXP Versions: 3.3.4.2.2.c0.4(3.2.4.1)& SKGXP:[7f31b]{ctx}: DBG flags1: 0& SKGXP:[7f31b]{ctx}: DBG post_type: 0& SKGXP:[7f31b]{ctx}: DBG post_sig: 0& SKGXP:[7f31b]{ctx}: DBG post_send_thresh: 0& SKGXP:[7f31b]{ctx}: DBG post_timing: 0& SKGXP:[7f31b]{ctx}: DBG post_trace_all: 0& SKGXP:[7f31b]{ctx}: DBG dev_poll: 0& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: WAIT HISTORY& SKGXP:[7f31b]{ctx}: Wait Time& Time since& &
Fast reaps& Wait Type& Return Code& SKGXP:[7f31b]{ctx}:&
prev wait(ms)& before& & & & & & & & & & & & & &
SKGXP:[7f31b]{ctx}: ---------& -------------- ----------- ---------& -----------& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: 0& & & & & 0& & & & & & & 0& & & & &
invalid status code& SKGXP:[7f31b]{ctx}: wait delta 3 sec (3883 msec) ctx ts 0x0 last ts 0x0& SKGXP:[7f31b]{ctx}: user cpu time since last wait 0 sec 032 ticks& SKGXP:[7f31b]{ctx}: system cpu time since last wait 0 sec 032 ticks& SKGXP:[7f31b]{ctx}: locked 2& SKGXP:[7f31b]{ctx}: blocked 0& SKGXP:[7f31b]{ctx}: timed wait receives 0& SKGXP:[7f31b]{ctx}: fast reaps since last wait 0& SKGXP:[7f31b]{ctx}: context timestamp 0& SKGXP:[7f31b]{ctx}: flags=1 flags1=30 zcpyflg=5824 iflags=820 aflags=80 trcflags=0 trclevel=3& SKGXP:[7f31b]{ctx}: rcvbuf=131072 sndbuf=262144& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: admno 0x5c339b5a admport:& SKGXP:[7f31b]{ctx}:&
SSKGXPT 0x7f31b7726390 flags 0x5 { READPENDING } sockno 5 IP 169.254.218.13 UDP 49793 lerr 0& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: post port:&
SKGXP:[7f31b]{ctx}:&
SSKGXPT 0x7f31b77267e8 flags 0x0& sockno 8 IP 127.0.0.1 UDP 26916 lerr 0& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: sconno [, ]=0 aconno [507a7b6d, 507a7b6d]=0& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: memory (native) allocs 5 free 1 lost 0 out 5712 max 32768& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: ctx(10296) sctx(1920) rqh(1040) cid(24)& SKGXP:[7f31b]{ctx}: prt(464) cnh() ach() rpc(2400) pid(64)& SKGXP:[7f31b]{ctx}: rgnst(472) rgnpt(248) rgn(8056) rbd(120) bid(64) mcph() mupdh()& SKGXP:[7f31b]{ctx}: mcb(852008) smap(4184) nsm(2084) me(1040) mcbe(48) mcbi(24) epid(40)& SKGXP:[7f31b]{ctx}: mhdr(76) fhdr(28) madm(272) aggpid(32)& SKGXP:[7f31b]{ctx}: sta msc(448) cnh(344) prt(216) ep(48)& SKGXP:[7f31b]{ctx}: aggpt(192) swin(384) finfo(176) segf(200)& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: done Queue& SKGXP:[7f31b]{ctx}:&
no completed requests& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: connection Queue& SKGXP:[7f31b]{ctx}:&
no pending connect disconnect operations& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: sends waiting to be transmitted& SKGXP:[7f31b]{ctx}:&
no sends waiting to be transmitted& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: pending ack Queue& SKGXP:[7f31b]{ctx}:&
no send requests pending ack& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: Vrpc requests pending reply& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: Port queue& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: Region queue& SKGXP:[7f31b]{ctx}: SKGXPRGN: 0x7f31b6efdd30& SKGXP:[7f31b]{ctx}:& & region id 0xcf2f rgn idx: 0 rgn key: & SKGXP:[7f31b]{ctx}:& & base address 0x size: & SKGXP:[7f31b]{ctx}:& & flags 0x0 state: 0x2 largest buffer: 0& SKGXP:[7f31b]{ctx}:& & num bids prepared: 0& SKGXP:[7f31b]{ctx}: SKGXPRGNSTATE: 0x7f31b77261a0& SKGXP:[7f31b]{ctx}:&
rgns mapped: 1 num shared: 1 max: 1& SKGXP:[7f31b]{ctx}:&
flags: 0 bseqno: 19445 nxtrgnno: 53039& SKGXP:[7f31b]{ctx}:&
shared ports open: 1 limits (1,16)& SKGXP:[7f31b]{ctx}:&
shared bids prepared: 0 hiwat: 0& SKGXP:[7f31b]{ctx}:&
space - used: 0 max possible: 4194304 sock limit: 524288& SKGXP:[7f31b]{ctx}:&
rgnarr[0x7f31b772e718(32)] rgnpts[0]=0x7f31b772e838& SKGXP:[7f31b]{ctx}:&
REGION ARRAY& SKGXP:[7f31b]{ctx}:&
rgn mapped[0] = 0x7f31b6efdd30& SKGXP:[7f31b]{ctx}:&
SHARED PORT ARRAY& SKGXP:[7f31b]{ctx}:& & rgn port[0]=0x7f31b772e838& SKGXP:[7f31b]{ctx}:&
SKGXPRGNPORT: 0x7f31b772e838& SKGXP:[7f31b]{ctx}:&
nbids: 0 space: 0 used: 0& SKGXP:[7f31b]{ctx}:&
SSKGXPT 0x7f31b772e848 flags 0x0& sockno 13 IP 169.254.218.13 UDP 30898 lerr 0& SKGXP:[7f31b]{ctx}:&
SKGXPGPID Internet address 169.254.218.13 UDP port number 30898& SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: Dumping Connection Handle Table& SKGXP:[7f31b]{ctx}:& & & & & & & & hdl& &
aconno& & & admno&
RmtPid& state&
rtrans& & credits& & & rtt&
last ack& & & &
id& & & & & & &
SKGXP:[7f31b]{ctx}:&
SKGXP:[7f31b]{ctx}: Dumping Accept Handle Table& SKGXP:[7f31b]{ctx}:&
Done dumping the osd state& Dumping ksxp state& & ksxppg=0x7f31b71e47a8 ksxpsg=0xa7584ed8 ksxpsg_a=0xa7584ed8ksxpssg=0xa7584c20 rm=0xa7584b98& proc state: (pid: 38) [flg: 1 sg: 1]& &curts
wtctr 0& & Dumping ksxp contexts& & & Context[2] 0x7f31b6f06430 GES state 1& & & & Dumping region queue& & & &
region count: 0& & & & Dumping connection queue& & & &
connection count: 0& & & & Dumping done requests queue& & & &
done requests count: 0& & & & Dumping mupq requests queue& & & &
mupq requests count: 0& & & & Dumping zombie requests queue& & & &
zombie requests count: 0& & & & Dumping delayed callback requests queue& & & &
delayed callback requests count: 0& & & Context[1] 0x7f31b6effcc0 gc ksxp component context state 1& & & & Dumping region queue& & & &
region count: 1& & & & Dumping connection queue& & & &
connection count: 0& & & & Dumping done requests queue& & & &
done requests count: 0& & & & Dumping mupq requests queue& & & &
mupq requests count: 0& & & & Dumping zombie requests queue& & & &
zombie requests count: 0& & & & Dumping delayed callback requests queue& & & &
delayed callback requests count: 0& & Dumping pending request queue& &
pending request count: 0& & ***
15:12:39.785& Oradebug command 'ipc' console output:&
Information written to trace file.& & ***
15:12:43.443& Processing Oradebug command 'tracefile_name'& & ***
15:12:43.443& Oradebug command 'tracefile_name' console output:&
/u01/app/oracle/diag/rdbms/zhongwc/zhongwc1/trace/zhongwc1_ora_31553.trc&
相关资讯 & & &
& (06月04日)
& (04月27日)
& (09月02日)
& (04月29日)
& (04月18日)
图片资讯 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款ORACLE Fusion-io最佳实践
Fusion-io是基于NAND Flash技术的存储设备，底层存储技术与SSD相同，不同的是，Fusion-io采用PCI-E接口，SSD采用SATA接口。相比较SSD，Fusion-io省略了南桥芯片，RAID控制器等访问路径，所以Fusion-io又把他们的产品称为IO Memory，意思就是可以象内存一样访问，性能比SSD要好很多。
我们目前数据库使用SSD，采用的是硬件RAID5的方案，这个方案的优点是：通过RAID卡提供冗余功能，提升了整体的可靠性。缺点是：RAID会损失部分性能，通过RAID卡屏蔽之后，无法检测到SSD的使用寿命。选择硬件RAID5方案，是在大量测试的基础上，结合我们的实际情况做出的选择，并不一定是最优的方案。
ORACLE使用Fusion-io的方案，需要考虑三个方面的内容：1.数据冗余方案；2.数据存放方案；3.高可用方案。
数据冗余方案：
Fusion-io采用PCI-E接口，无法使用硬件RAID，我们可以使用OS LVM或者ORACLE ASM实现软RAID的功能。
1.External Redundancy (Striping/RAID0)
这个方案相当于RAID0，只是将多块ioDrive(Fusion-io的产品名称)的空间整合为一个统一的DG，不提供任何数据冗余。
2.Normal Redundancy (Mirroring/RAID1)
这个方案相当于RAID10，同时提供了数据冗余与条带，是可靠性比较高的方案。需要注意的是：可以通过ASM failgroup的功能，将两块ioDrive之间做镜像，以防止单块卡出现故障。
3.High Redundancy (Mirroring/RAID10 +1)
这个方案相当于RAID10+1，数据被冗余了三份，进一步提高了可靠性，不过代价有些高。
4.ASM Mirroring with a Read-Preferred Device
这个方案稍微复杂，ioDrive与存储的LUN做RAID10，利用ASM的功能，读取时优先读取ioDrive，提高性能的同时，又保证了可靠性。
5.方案分析：
上述四个方案中，方案一没有数据冗余，其他三个方案都有数据冗余，方案三代价过于高昂，方案四必须要有FC存储，方案二是最有可能采用的方案，但是RAID10要损失一半的容量，对于价格昂贵的ioDrive来说，代价依然高昂。回头看看方案一，因为本地数据没有冗余，所以必须采用Data Guard来保证系统高可用，如果要求数据100%不丢失，Data Guard必须采用同步模式，网络延迟必须满足日志同步写入的要求，如果系统压力过大，依然存在丢失数据的可能性。看来没有十全十美的方案，必须有所取舍。
数据存放方案：
1.将所有文件都保存在ioDrive上：
如果存储空间许可，这是最简单可靠，也是性能最好的一种方案。
2.将temp文件保存在ioDrive上：
针对一些DSS系统，temp文件可能是性能的瓶颈，比如大量的sort，Hash join可能耗费大量的temp空间，将temp文件放在ioDrive上可能带来性能上的收益。不过，我很少见到类似的需求，这个方案应该很少使用。
3.将redo保存在ioDrive上：
对于ORACLE数据库，redo log必须同步串行（9i串行，10g以后可以并行），对于write-intensive系统，要求redo必须有很低的写入延迟，否则redo可能成为整个系统的瓶颈。所以，可以考虑将redo log放在ioDrive上，提高响应延迟。但是，我个人并不是特别建议这个方案，因为redo log的写入是一种小IO的顺序写入，顺序写入更适合磁盘，并不适合flash存储（可以参考）。如果磁盘可以满足响应延迟需求，建议将redo log放在磁盘上，而不是ioDrive上。
4.将热点数据保存在ioDrive上：
如果整个系统无法全部放在ioDrive上，而用户可以识别出系统的热点数据，那么可以人工将热点数据放在ioDrive上，将其他数据放在磁盘存储上，从而获得比较好的性能。
5.ioDrive作为flashcache：
将ioDrive作为数据库内存和磁盘之间的cache，Flashcache是用户透明的一种解决方案，系统自动将热点数据加载在flashcache中，提升系统性能。ORACLE
11g R2提供了flashcache功能，当block从SGA中被换出时，会被写入到flashcache中，但是在ORACLE的flashcache方案中，只有clean block才会被写入到flashcache中，Dirty block必须写入到磁盘上（DBWR会优先保证dirty block的写出，只有空闲时才会写flashcache），这就是我们所说的write through模式（Facebook的flashcache方案可以采用write back模式，dirty block首先被写入flashcache，然后定期刷新到磁盘上，flashcache同时承担了读cache和写buffer，这个方案性能更好），ORACLE flashcache是纯粹的读cache，可以大幅度提升读的性能，但是无法提升写的性能。ORACLE的方案很安全，就算flashcache损坏，也不会丢失任何数据，但是性能比WB模式要差一些，而且flashcache预热的过程也比较长。另外一点，ORACLE flashcache必须使用ORACLE LINUX，其他操作系统不提供这个功能。
Flashcache提供了一个高性价比的方案，但是同时增加了系统的复杂度，如果是WB模式，可能存在数据丢失的风险，在做方案时，需要做一些权衡。个人建议：如果空间可以满足需要，可以考虑方案一，性能和可靠性都最好。如果热点数据很明确，可以采用方案四，简单可控，性价比高。另外，Facebook的flashcache方案也是一个很好的选择，淘宝在MySQL数据库上广泛采用了这一技术，百度也在MySQL innodb存储引擎上，自主开发了flashcache的功能。不过，我始终认为flashcache是一个过渡方案，技术上并不是特别成熟，如果技术上无法完全把握这项技术，请谨慎使用flashcache。
数据高可用方案：
ORACLE数据库高可用方案有两个：Data Guard和RAC，Data Gurad相对比较简单，但是可用性并不理想。RAC基于共享存储架构，必须有一套SAN存储，RAC使用FusionIO也有两个方案：
1.共享存储+Fusion-io+Flashcache
这个方案采用传统RAC架构，只是在RAC节点上配置ioDrive，用ioDrive作为数据库的flashcache，提升性能。这里要说明一点，为什么ORACLE flashcache不提供WB模式，原因是ORACLE RAC架构必须基于共享存储，如果dirty block写入RAC节点的flashcache，当发生节点crash的时候，将出现数据不一致的情况。
2.Fusion-io+iSCSI+infiniband
这个方案将配置ioDrive的机器作为存储节点，利用iSCSI和ASM技术，将存储节点整合为共享的存储设备，输出给RAC节点使用。
事实上，很早之前我就做过类似的方案：，大致的原理一致，只是存储节点变成了ioDrive。但是，我们在做这个方案时，发现在千兆以太网上运行iSCSI，延迟时间根本无法满足需求。如果存储节点换成ioDrive，存储节点可以提供强大的IOPS能力，但是网络延迟将会成为整个系统的瓶颈。后来，ORACLE Exadata出现了，内部互连采用infiniband技术，这给了我们一个启发，我们同样可以利用infiniband的低延迟特性，来实现这个方案。
Infiniband与以太网不同，采用SRP(SCSI RDMA protocol)协议，是IB SAN的一种协议 ，其主要作用是把iSCSI协议的命令和数据通过RDMA的方式跑到Infiniband网络上，可以认为是iSCSI协议的一种增强和扩展，iSER代表iSCSI Extensions for Remote DMA。下图清晰的展示了各种协议与底层物理链路之间的关系。
ORACLE Exadata的最大优势在于，将OLTP和DSS融合在一套系统之内，Exadata有一些特性，其中smart scan，storage index，hybrid columnar compressed，这几个特性适合DSS应用。而对于OLTP类型的应用，主要是靠存储节点的flash存储和flashcache技术。对于我们的需求来看，DSS系统更适合采用分布式系统，例如hadoop，greenplum等，而对于OLTP系统，高性能的集中式数据库，可以解决很大的问题。所以，上述的方案如果可行，就为我们提供了一个新的方向。
我不知道ORACLE Exadata内部采用何种协议进行互联，我也很想搭建一套系统，去验证这个方案是否可行。另外，现在的存储厂商都可以提供内置SSD的存储产品，很多产品还提供自动分层的技术，从技术的角度看，这是比较成熟的。如果采用上述方案，性价比和风险还有待于进一步验证。
–EOF–
版权说明：本文中的部分内容来自于Fusion-io官方文档《Oracle Fusion-io Best Practices Guide》，最后的协议与链路关系图，来自于同事林钰的PPT，比我画得好多了。
RSS订阅统计