原创力文档- 1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
- 2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
ORACLEFusion-io最佳实践
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的 HYPERLINK /2009/11/oracle_11g_asm_new_features.html Preferred mirror read功能，读取时优先读取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存储（可以参考 HYPERLINK /2010/10/ssd-database-2.html 《基于SSD的数据库性能优化》）。如果磁盘可以满足响应延迟需求，建议将redo log放在磁盘上，而不是ioDrive上。
4.将热点数据保存在ioDrive上：
如果整个系统无法全部放在ioDrive上，而用户可以识别出系统的热点数据，那么可以人工将热点数据放在ioDrive上，将其他数据放在磁盘存储上，从而获得比较好的性能。
5.ioDrive作为flashcache：
将ioDrive作为数据库内存和磁盘之间的cache，Flashcache是用户透明的一种解决方案，系统自动将热点数据加载在flashcache中，提升系统性能。ORACLE ?11g R2提供了flashc
文档评论（0）