开始新对话

未解决

此帖子已超过 5 年

4265

2013年11月24日 22:00

EMC优化与扩展Oracle性能解决方案

​ EMC优化与扩展Oracle性能解决方案,该解决方案演示了基于EMC VMAX 40K和XtremSF、XtremCache对运行于VMware vSphere虚拟环境中的Oracle实现极致性能优化的解决方案。​

​解决方案中基于服务器层、网络层、存储层三层部署,使用到的产品有:​

    ​ ​
  • ​服务器层 - 16个Cisco UCS C240服务器,两个700GB的EMC XtremSF SLC Flash(共计1400GB),安装EMC XtremSF驱动及固件和ESXi Server。​
  • ​ ​
  • ​网络层 - 两台Cisco Director MDS9506光纤交换机。​
  • ​ ​
  • ​存储层 - EMC Symmtrix VMAX 40K存储阵列。​
  • ​ ​

VCEOracle-1.png

​ 服务器端,700GB的XtremSF Flash卡安装在VMware ESXi,利用XtremCache Virtual Storage Integrator(VSI)实现在vCenter中对XtremCache进行管理。​

VCEOracle-2.png

​ 环境搭建以后,部署16台虚拟虚拟机运行Oracle 11g R2数据库。通过SLOB生成OTLP作业,对整体的环境进行存储性能测试。整个过程通过线性的方式,逐台进行SLOB作业负载。​

​ 测试结果非常令人震惊,介于XtremSF和XtremCache在主机端所起作用,结合VMAX 40K性能。16台虚拟机可以实现最大(16个同步测试Session)超过​​281.8万的只读IOPS​​,而响应时间则只在​​0.8毫秒(ms)​​级别。​

VCEOracle-3.png

​运行数据修改的OLTP模拟作业,的结果也可以达到最大​​35万的IOPS​​,且响应时间在​​1毫秒​​以内。​

VCEOracle-4.png

​更多详细内容详见附件:​

​更多EMC针对Oracle的解决方案详见:​​【汇总】Oracle解决方案​

1个附件

2 Intern

 • 

3.2K 消息

2013年11月24日 23:00

哇,好激动哦。

2 Intern

 • 

2.1K 消息

2013年11月24日 23:00

那多是数据库里面的东西了,其实你感兴趣的话可以比较下平时和”慢“的时候,存储是不是真的有压力。其实这种95%以上都是数据库里面逻辑问题课,哪里索引没加,平时不觉得,流量上来开销就一下子上去了。DBA学问还挺大的说。

2 Intern

 • 

3.2K 消息

2013年11月24日 23:00

其运行的Oracle是单实例的库还是RAC的库呢?

2 Intern

 • 

643 消息

2013年11月24日 23:00

这个方案测试是单实例的,基于RAC的测试进行中。

2 Intern

 • 

3.2K 消息

2013年11月24日 23:00

让您笑话了,偶这边的环境是制造企业,可以说是15%的OLAP和85%的OLTP。到目前为止上面还真没告诉偶,具体指标是多少都是一些定性的东西。至于IOPS和Throughput是多少个预期的值实际上是多少呢?还真的不知道,只要在需要调整数据库里面内容的时候已经数据库慢啦或者丢数据的时候他们才想起偶。

2 Intern

 • 

2.1K 消息

2013年11月24日 23:00

不是RAC。

liulei,挺好奇你管的Oracle TPS有多少,用的DMX处理了多少IOPS和Throughput?什么时候有时间分享下?讲讲性能不牵涉到具体业务。

2 Intern

 • 

2.1K 消息

2013年11月25日 00:00

基准数据收集还是挺重要的,EMC很多解决方案文档里面,都会先定一个Baseline,然后看应用什么配置以后有没有什么改善。

2 Intern

 • 

3.2K 消息

2013年11月25日 03:00

您说的非常对

您说的这些应该是 数据库物理设计上的范畴,通过一系列的参数模型可以估算出其某些部分的性能参数,

偶很好奇的是数据库的逻辑模型 也就是说 整个体系为什么是这样的,举个例子,某张表存储代表业务上那一部分的数据,那么这些字段为啥都要这么设计,这些字段掉个个排列好不好呢? 也许逻辑模型是这些系统的灵魂

2 Intern

 • 

2.1K 消息

2013年11月25日 18:00

是的,系统优化越上层效果越好,了解一些算法的人都知道,一段程序的时间和空间复杂度会指数级影响应用性能。其次是数据结构,目前大多数系统还是使用关系数据库,所以表结构的设计与优化,索引,表锁等,数据一致性需求也直接影响到性能。鉴于许多系统在应用层已经优化到一个阀值,再继续优化并不是没有可能,只是出于业务,成本考虑,用户不会去更改过多,或者花更多的时间在新功能和创新上。

所以,健壮的基础架构可以为现有的系统带来更多附加值,也就是EMC解决方案用武之地。试想一个数据库事务或者存储过程原来完成时间在10ms(假设),其中一半消耗在数据库服务器中完成,剩下5ms用来从存储获取和写入数据。那么,通过闪存和高性能存储,缩短这个过程到1ms以内,那么整个事务完成时间就减少了40%,整体性能也直接提升40%。直接明了!

2 Intern

 • 

3.2K 消息

2013年11月25日 19:00

如同好的摄影师能用差的镜头也能拍出唯美的PP,那么对于一些没有那么多时间的玩家花钱买好装备也能达到大师的效果。哈。

2 Intern

 • 

3.2K 消息

2013年11月26日 17:00

甲方解决了问题乙方有卖出额,皆大欢喜。

2 Intern

 • 

643 消息

2013年11月26日 17:00

同意你的看法,这就需要用户根据自己的实际情况,技术水平,成本承受等综合考虑采用哪种方式最适合。

找不到事件!

Top