（已结算）【技术圆桌】第7期：「超融合」适不适合跑ORACLE数据库？>>专家驻场，欢迎畅聊

【技术聊主】资料介绍：本期我们邀请到深信服云数据中心Oracle DBA专家-杨小宇，8年数据库从业经验，OCM认证大师，5年交付DBA工作经验，2年运维DBA工作经验，1年云计算专家工作经验。长期从事Oracle数据库、传统架构、云计算的管理、优化及研究工作，对Oracle的各种集群架构、高可用架构以及分布式架构都有较深的研究和理解，管理过上千套MS SQLServer或Oracle实例，维护过数百TB容量的数据库。曾为多家公司与机构提供数据库相关服务。

大家好！我是SANGFOR社区技术顾问“YxY"，受管理员邀请参与社区话题发起人活动，与大家一起探讨超融合产品相关知识，欢迎对超融合产品&数据库知识感兴趣的朋友关注我，如你有其他关于数据库方面的问题可在本帖留言提问，诚邀大家一起来分享技术经验与传播知识！

---

话题背景概述

在超融合领域里，很多厂商拿自家产品在跑ORACLE数据库上性能有多好作为宣传噱头。厂商表示超融合适合跑数据库，完全没有问题。但很多数据库工程师却认为，数据库适合跑在超融合架构中，其中还有一部分认为，数据库不适合运行在虚拟化的超融合环境中，认为超融合云计算都是穷人的玩法。

不知道大家是如何理解和看待“超融合是否适合跑Oracle数据库”这个问题，基于此，想邀请大家一起来参与圆桌讨论活动，从性能、成本、弹性、可用性、运维难度等技术角度来聊一聊，欢迎各位朋友踊跃参与！

传统的部署模式：

超融合的部署模式：

超融合架构的数据库承载

---

本期圆桌话题

1、超融合到底适不适合运行数据库？请从性能、成本、弹性、可用性、运维难度等角度来进行技术讨论；

2、如您还有其他关于数据库方面的疑问，可以回帖提问，我将知无不言一一回复大家的留言；

---

讨论时间

2020年4月17日---2020年4月24日 23：59

---

奖励设置

1、基础回帖奖：凡有效回帖者可获得20S豆奖励；（回帖内容与话题相关且为个人原创）

2、优秀回复奖：凡回复的内容，被管理员设置为优秀回复即可获得100S豆打赏！

3、参与幸运奖：本帖设置800S豆回帖奖励，每次回复有机会获得20S豆；

4、最佳回复奖：活动结束后，由话题发起人评选出1位最佳回复者，赠送热门学习书籍《Oracle 11g从入门到精通（第2版）》或《Oracle数据库管理从入门到精通》（两者任选一）一本；

---

本期最佳回复用户公布

5、趣味互动奖：技术知识本乏味，互动交流应有味，文理综合为了让大家收获更多知识与欢乐，特设惊喜小互动，猜中答案且踩中6、16、36、46、56、66楼（仅6个名额）者可获得66S豆奖励；(同一ID只能猜测2次哦）

（打一古诗）小提示：一首五言绝句

---

获奖楼层

回复楼层	发帖时间	帖子作者	作者UID
6楼	2020-04-20 12:58	新手520146	306253
36楼	2020-04-21 17:04	哥丶珍藏版	94638
46楼	2020-04-22 09:10	张全蛋	184116
56楼	2020-04-23 09:22	在你的全世界耍过	133338
66楼	2020-04-26 13:28	807710	74446

---

回帖规则

1、回复须为个人原创且与话题相关，如回复无意义内容，管理员将判定为灌水，进行删除。

2、如恶意抄袭，以不良手段获取礼品行为，一经发现取消其获奖资格，并对账号进行1月以上禁言警示。

3、可盖楼回复但每个id回帖仅奖励一次，其他奖励可叠加，活动结束后将进行统一派发。

↓↓↓

欢迎回帖交流

个人粗浅观点：1、从性能性能来讲，业务量庞大的情况下可能传统模式性能要比超融合性能好；
2、性能自然是与成本挂钩的，传统模式的成本自然要比超融合的要高出许多；
3、从弹性讲，超融合的弹性要比传统的好的多，传统的架构要改绝对费劲，超融合扩容啥的要简单的多；
4、从运维难度来讲，超融合设备少，运维不论是难度还是成本超融合都要少很多。
总的来讲，中小型业务量的话超融合要比传统模式性价比高；大型数据量业务量还是用传统的比较好，就算超融合能承载，领导看不见设备会觉得你这业务不重要，啥都没有啊！

我有几个疑问想咨询下专家：
1.超融合针对数据库这块如果发生了服务器宕机话怎么恢复？
2.如果发生服务器硬件故障，超融合能不能恢复数据库及服务器内的坏境，实现系统一键平滑过渡，能不能做到不需要重新搭建业务系统环境。
3.针对勒索病毒，超融合能不能预防勒索病毒，或者发生勒索病毒后，能不能快速恢复到未中毒前状态

我从三块内容回答下把
1.性能，我们属于中等事业单位，其实在Oracle的数据方面使用量尤其是性能这块的要求并不是特别高，部署到哪里都是部署。怎么说这个性能问题呢，我这里觉得还是看业务，如果您的Oracle数据库确实比较重要，可以考虑物理机部署，因为Oracle官方说过一个事情，如果您部署到虚拟机里面，我们不提供服务，所以有条件的情况下还是部署到物理机上，毕竟懂Oracle数据优化已经故障排除的人还是少。（这块应该规划到运维难度这里把）
2.可用性，这里应该包含高可用，或者高性能之类的方案，通常我们单位在Oracle数据库使用的过程中都是要求厂商提供两台Oracle数据库，一主一备，主要我们的业务是一卡通业务，尽量降低业务复杂性的同时，也需要保证业务的连续性。
3.成本，这里我应该怎么说呢。还是跟第一条一样，看业务，我没看到过银行的Oracle数据库，但是我知道他们的重要业务肯定不会直接在虚拟机跑把？那出问题，不管是那一块问题，比如说Oracle厂商说是你们虚拟系统的问题，但是虚拟机厂商说的是你们Oracle数据库的问题，防止扯皮，Oracle直接在物理机上方案更充分。
4.弹性伸缩，我们在物理机上部署的Oracle数据基本上都快跑了5年了。。。从来都没考虑伸缩的问题，但是随着我们业务的不断增加，数据库的压力不断增大，其实也会考虑在虚拟机上部署，毕竟弹性伸缩这个是好的，但是有一块问题，我们的业务上线前就会规划未来5年到六年的使用预估，尤其我会要求厂家对这块做个简单的评估，如果在未来几年的增长超过目前硬件的预期，让他们给一个合适的方案，总是所有业务上线前一定要做一个简单的评估，这不仅是为了自己单位考虑，也是为了甲方工程师考虑。

观点：超融合适合于一般要求不高的Oracle数据库系统；对于高性能要求的Oracle RAC系统，还是选择物理服务器，不适合在超融合系统中部署；对于大数据量、更高性能要求的，可能Oracle ExaData更适合。

1、对于一般要求的Oracle数据库系统，超融合系统提供了物理主机的高可用保障，可以解决物理主机故障而引发的业务中断；
2、超融合的优势是充分利用主机资源，提高资源利用率，但在内存管理这块，没有很好的做到弹性分配和动态回收；
3、对于Oracle RAC的使用，一是因为对系统的可靠性要求高；二是对系统的性能要求高，包括CPU、内存、I/O，一般都是单台主机不能满足要求，在这种情况下，一台超融合主机上跑一台虚拟主机，意义不大；
4、对于超大数据量、超高性能要求的Oracle系统，Oracle ExaData更合适；

登鹳雀楼

超融合不适合跑Oracle数据库。一般Oracle数据库都是作为核心系统的数据库，性能要求比较高，用超融合多少会影响系统的性能，而且Oracle数据库本身就有很多安全方面的功能。

超融合多灵活啊 随时调整 传统的没有这么方便吧

白日依山尽，黄河入海流。欲穷千里目，更上一层楼。

白日依山尽，黄河入海流。欲穷千里目，更上一层楼。

超融合在技术上跑RAC架构没有任何问题。之所以还在使用物理机很多是从性能和稳定性方面上考虑。另外使用超融合技术需要考虑Oracle授权问题，VMware等虚拟化使用都是软分区，如果进行迁移的话授权需要按所有节点的CPU核心数计算。成本方面我感觉一次性投入的话超融合贵点，但长远来看便宜。超融合灵活度高，调整方便，人员运维难度低。

目前我见到的，超融合上有跑数据库的，但多是一些较边缘的业务（挂了影响也不大）
白日依山尽
黄河入海流
欲穷千里目
更上一层楼

超融合在技术上跑RAC架构没有任何问题。之所以还在使用物理机很多是从性能和稳定性方面上考虑