查看: 3716|回复: 4

选择oracle数据库的时候,你有想过这些吗?

[复制链接]
论坛徽章:
0
发表于 2015-1-16 13:55 | 显示全部楼层 |阅读模式

  请允许我以这样一个疑问句作为文章的标题。面对这样一个在全球关系型数据库市场份额中占据超过半壁江山的数据库产品,CIO在进行数据库产品选型的时候,是否真正问过自己这样的问题?Oracle并不是最便宜的产品,事实上自产品推出之后,Oracle数据库就从来没有降过价;它也不是技术最激进的产品,很多像内存计算、列式存储等功能都是在近一年才推出来的。那么,依然有那么多企业选择Oracle作为“标配”,其背后的原因究竟是什么?

  答案其实很简单,买一个安心。作为长期占据关系型数据库老大位置的甲骨文,说Oracle数据库是他们“安身立命”的资本其实一点也不为过。满足客户在数据平台层的各种需求,把三十多年的数据管理经验和较佳实践融入到产品当中,你所有可能遇到的问题,它都能提供相应的解决方案。CIO在进行数据库选型的时候,就是看中了它的这一点,甚至Oracle数据库已经成为了高可靠、高性能和高安全的代名词。

  然而对于很多中国的企业来说,在选购Oracle数据库时他们并不知道,真正实现高可靠、高性能以及高安全的并不只是一个Oracle企业版数据库这么简单,而是围绕它的一系列Oracle数据库选件(Database Options)。如Oracle真正应用集群(RAC),数据库分区,高级压缩,Active Data Guard(ADG)等,才是让Oracle数据库脱颖而出的关键所在,其中有一些甚至已经成为了数据库领域的杀手级应用。

  然而在采用数据库选件方面,中国地区的用户跟发达国家还存在一定的差距。为此吴承杨给出了一组Oracle数据库配售率(AR)的数据,其中中国用户的数据库选件AR比例为47%,也就是说中国的用户每在数据库上投入1美金,在选件上的投入只有0.47美金。相比于澳大利亚,其选件AR比例为137%,即投入在选件上的成本甚至超过Oracle数据库本身。对于这一现象,吴承杨认为选件的成本和部署复杂度都不是主要原因,最根本的是很多中国地区的客户对Oracle选件的认知程度还不高。

  “就拿Oracle RAC来说,这是做数据库集群的选件,是15年前的技术,但目前中国还有很多用户根本没有用到。现在很多中国企业的CIO是根据应用来做项目招标的,他们根本不知道还有Oracle选件的说法。但对于一些业务连续性要求较高的企业,如果没有认识到这一点的话,是要让业务冒很大的风险的。这也是甲骨文为何要强调数据库选件重要性的原因。”吴承杨说。

  另外,吴承杨认为高可用、高性能和高安全是现代数据中心成功运行的三大基石,也是Oracle数据库选件发挥作用的三个主要方面。但中国企业往往更关注于性能和可用性,而忽视了安全性。与其他发达国家相比,中国企业很少投入保障安全性的数据库选件,也是造成上述比例差距的原因之一。一方面是国家法律法规有所不同,但更关键的是CIO缺少对安全性的重视,特别是在数据库层面。对此吴承杨介绍,包括Oracle Database Vault、Oracle数据库防火墙以及Oracle Advanced Security等选件,能够帮助企业实现事前防范、事中告警、事中拦截和事后审计的目标,保障数据库安全万无一失。 而至于如何保障数据安全想必大家都知道要备份了。不妨试试多备份,专门做数据备份的SaaS提供备份服务。

  当然,数据库选件就是在数据库基础之上增加的针对特定领域应用的解决方案,用户需要购买额外的许可证,而有一些选件还需要客户进行部署和安装。针对这一问题,吴承杨表示甲骨文和合作伙伴的团队都已经整装待发,随时能够帮助客户完成一些复杂选件的部署,比如Oracle RAC等。而Oracle之所以一直选择选件的形式而不是将所有功能都打包销售,也是为了满足不同规模企业的需求,给客户更多的选择空间。

  “并不是所有用户对SLA的要求都一样,不同需求之间可能会造成很大的成本差异,比如有些客户不使用Oracle RAC也能满足需求。我们相信甲骨文以选件的方式能够为客户提供较佳的总体拥有成本(TCO)。”吴承杨说。


回复

使用道具 举报

论坛徽章:
0
发表于 2015-8-12 20:47 | 显示全部楼层
谢谢分享,楼主辛苦了
回复 支持 反对

使用道具 举报

论坛徽章:
0
发表于 2015-8-12 20:47 | 显示全部楼层
谢谢分享,楼主辛苦了
回复 支持 反对

使用道具 举报

论坛徽章:
0
发表于 2016-6-5 16:29 | 显示全部楼层
回帖是必须的,这个可以有!
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册 新浪微博登陆

本版积分规则

 

GMT+8, 2018-7-19 13:36 , Processed in 0.119965 second(s), 39 queries .